面向数据智能时代的大数据架构实践

诸葛io 在上线的不到 20 个月里，经历了客户量从 0 到 10,000 的突破，月有效行为数据处理量超过了 100 亿。这期间，其研发团队面临过许多难题与挑战，同时，对于大数据平台的发展与架构也有许多的思考与沉淀。这些思考与实践，正是本文中要与大家分享的内容。

第一部分：大数据平台的三次浪潮

在正文开始之前，我们回顾一下 1990 年到 2016 年间，大数据平台经历的三次浪潮。

第一波浪潮

第一波浪潮起源于 90 年代，当时从计算机到软件大多还是企业级的，而数据分析就已经开始。

这个时代还是集中式软件时代，存储数据的成本非常昂贵，所以大部分企业以 KPI 角度，抽取少量结构化数据进行数据分析。代表企业如 MicroStrategy、Microsoft、Oracle，代表产品也诸如 Sybase、Congos，这个时代能产生的数据有限，能处理数据的能力有限。

第二波浪潮

发展到 2000 年左右，互联网的兴起带动计算机和软件走向消费级，并且互联网成为基础设施，从以下三点带来数据的爆发式增长。

数据的存储成本越来越低，数据的产生速度越来越快，数据量越来越大，第一波浪潮时的技术体系已经满足不了需求，并且由于摩尔定律基础硬件设备和条件也在优化，处理数据的能力越来越强，这个时候带来了大数据平台第二波浪潮的发展。

面临这样的环境趋势，第二波浪潮的需要解决的核心技术问题包括三方面：

1. 越来越分散的数据需要集中采集处理

数据采集集中大多是“Pull”和“Push”两种方式，但是收集方式、可扩展性、收集效率、消息队列等等都需要一些突破。

2. 计算的可扩展性

机器资源已经不是瓶颈了，所以如何能分布式计算，把计算的复杂度分散拆解是要解决的核心问题，比如算法上的“多项式拆分”到计算框架上的“批处理”

3. 存储的可扩展性

越来越大量的数据，导致效率越来越底下，所以为了保障访问和利用效率，可灵活扩展存储数据也是要解决的问题。

这个阶段的大数据技术，陆续诞生了从 Facebook 早期开源的 Scribe、Cloudera 的 Flume、Linkedin 的 Kafka，还有后来的 Flink 等数据流处理框架，熟知的还有 Spark/Storm/Samza 等实时处理技术。

在这个阶段似乎无人不提大数据，人人都喊 Hadoop，但是我们做到的是数据流处理和实时处理以及存储方式的突破和革新，而分析主体还是老的分析中心化方式，由 BI 团队或者数据团队驱动，集中式的制定 KPI，数据采集集中之后会按照 KPI 进行处理展现，如果遇到多样化或者探索性的业务分析需求，还需要 On-Demand（按需）去编写程序或者 SQL 来基于这些大数据平台获取结果。

第三波浪潮

发展到 2010 左右，互联网发展也从信息化走向服务化，创业方向也从之前的“门户时代”、“社交时代”、“垂直化门户时代”、“内容视频时代”走向了电商、出行、外卖、O2O 等本地服务升级。

如果说面向信息化的时代更多的是基于流量广告的商业模式，面向服务化的时代更多的是直接面对客户价值变现的商业模式，或者说消费者服务，所以从行业发展来看，服务类对分析的需求也要旺盛更多，自古以来，电商游戏行业分析都做得比较好，不是吗？

我们用破木桶蓄水过程来类比，到处都是水源的时候，并且外部水源流入率大于自身流失率的时候，更多思考的是抓紧圈水源而不是找短板，从 2000 年到 2014 年，流量势头猛进，到处都是用户，对于企业而言更多的思考是如何圈用户，而不是如何留住用户，分析流失原因。

当外部没有更多水源进入，并且四处的水源有限时，企业需要的是尽可能修复木桶，并且找到木桶的短板。在 2014 到 2015 年左右，互联网流量红利也初现消尽之势，国内的经济下行压力也逐渐增大，就好比水源有限一样，企业需要更多的分析自身原因，提高各种转化率，增加用户的忠诚度和黏性，减少用户流失。所以分析需求开始逐步提升，各个业务部门都需要自我分析优化成本，提高利润和产出。

过去企业更多面临的是由上而下的 KPI 中心化式分析，所以形成的是分析中心化的体系，基本上整个公司有统一关注的指标和数据看板，但是各业务部门的分析就需要单独处理了。

数据分析其实从行业、角色、部门以及从场景而言，都是差异化的。

行业上：

角色上：

部门上：

所以要更充分的满足分析需求，就需要从 KPI 中心化分析转向分析去中心化，也就面临着又一次大数据平台的技术革新，这也推动了大数据平台第三波浪潮的变革。

第一、第二波浪潮更多解决的还是技术问题，第三波浪潮最重要的是要解决分析问题，但是分析的问题主要有三点：

这也就意味着第三波浪潮可能带来的更多不是通用的技术平台，而是更多深入的行业分析应用，所以在数据模型和数据仓库这一层的变革会更大，当然少不了的还是 Google 这样大鳄的弄潮，开源了 BigTable 带来的是以 Hadoop 为核心的第二波浪潮兴起，而 Google 的 BigQuery 其实也是代表了第三波浪潮的趋势。

第三波分析浪潮带来了一个 DI 的概念，就是数据智能，不同于 BI 的是，BI 更关注基于业务收集数据、处理数据的过程，而 DI 更多关注的是数据对各个业务部门的决策驱动和应用。

第三波浪潮下的大数据平台，会从分析看板开始，有各个行业下各个业务部门所关注的指标，并且业务人员可以灵活的配置，同时对于复杂分析下钻和数据探索过程而言，业务人员也无需 SQL 或者代码就可以直接通过交互式的查询组件进行自助式分析和配置。

大数据分析的基础技术已经逐渐成熟，而挑战就是基于行业理解下构建合理的数据模型，以及多维下复杂查询的效率。

PS：诸葛io 就是在第三波浪潮下诞生的一款数据分析产品，最大的特点就是快速直接给各个业务部门的人呈现他们需要的目标，无需借助专业人士，指标的可视化，一目了然。

第二部分：诸葛io 的业务架构实践

先自下而上再来看一下我们当前诸葛主要的业务架构：

1. 数据采集端

诸葛io 现在提供了 Android、iOS、JS 等 SDK 和 REST 的 HTTP 接口来采集数据，SDK 和接口都提供一些面向用户的方法或者数据规范，其分析的数据主要来于此。

2. 数据接收服务

SDK 和接口采集到的数据会发给网关服务， 通过 API 对数据进行简单加工，添加一些环境信息的字段之后，发给消息队列。

3. 消息队列

消息队列会成为数据的集中处理中心大数据架构，同时会对消息进行统一的加工转换和清洗，比如过滤垃圾数据，关联用户的 ID，加工用户的状态和标签，加工行为数据等等。

4. 多业务处理

数据进行统一的加工和处理完成后，会有多个服务器同时消耗和处理基础数据。主要包括以下部分：

5. 数据访问层

由统一的数据访问层来输出数据，给应用层进行调用，这一层会封装一些分析模型和业务逻辑。数据访问层会分为内部接口和外部接口进行分发。

6. 数据应用系统

数据应用主要包括以下：

开放 API

把一些查询封装成 API ，允许客户进行二次开发或者调用。

诸葛io 的架构经历了两次迭代，目前正在进行第三次的重构，重构的目的包含两方面，第一次重构主要是技术方案的瓶颈突破，第二次重构主要是业务领域问题的延伸和拓展。

架构永远是贴合业务的，从 2014 年 10 月开始研发，15 年 3 月份上线。当时需要让产品快速上线，验证想法，所以架构搭的比较简单粗暴。6 个工程师，完成了整套从数据采集到数据处理到网站到前端可视化的大数据架构。所以当时画的比较简单的架构如下：

诸葛io 第一次上线的架构实践

初次上线的架构在刚开始的一段时间内没有碰到什么问题。但是随着业务发展，诸葛io 的客户量逐步增加，甚至像暴走漫画、小影、墨迹天气等大体量的客户也陆续接入平台，这个时候考验就来了。

下图是我们当时数据处理流的架构图，标出了三个问题点：

诸葛io 第一次上线的数据处理流

1. 数据上传延时很高。

上传延时很高主要在两方面：

其实这个过程是没必要客户端等待处理过程的，所以优化后的逻辑就是客户端上传成功后即返回。诸葛io之前的服务端是 C++编写，优化后直接参考一些秒杀的高并发架构，选择了 Nginx+Lua，在无数据丢失情况下，单节点每秒并发处理完成数提高了 5 倍多。

2. 数据处理流使用的是多JAVA进程方式

诸葛io在第一次架构过程中，对于各个子业务处理的都是独立的 JAVA 程序进行数据消费和处理，显然这种方式不利于后续的业务扩展和运维管理，有很大的隐患，所以改成了通过 Samza 平台的处理过程，选择 Samza 的主要原因是，处理的输入输出都是 Kafka，并且 Samza 的实时性也有保证。

3. 数据仓库不具有可伸缩性

诸葛io的数据库选型一开始用的是 Infobright 的社区版，国内之前使用 Infobright 作为数据仓库的比较有名的公司是豆瓣，虽然 Infobright 不是分布式的，考虑到大多数 App 或者网站的 DAU 不会超过百万，并且 Infobright 的压缩和性能都不错，对于 SaaS 的早期创业公司而言，成本也会有保障。当数据越来越大的时候，加了控制路由，会分发不同应用到不同的 Infobright 中。

但是随着业务发展的逐步突破越来越多的百万甚至千万 DAU 的产品开始使用时，自身还是要解决查询性能和数据扩展的问题 。

从数据存储可扩展性和计算资源的分布式调用来综合考虑，诸葛io选择了 Greenplum 平台。

同时诸葛io在数据处理上也做了一些技巧，包含两部分：

1. 预计算

对于互联网用户分析，大多数是分析特定行为，特定类型（新增/活跃），特定平台（Android/iOS/JS），特定渠道的用户，所以这里其实有一些集合计算法则和技巧可以利用，诸葛io基于这个写了一个数据预处理的服务诸葛 PreAg。

2. 模型优化——业务维度分层

很多人在设计模型是过于去找逻辑对等以及对象关系，但是其实从应用场景来看，比如同是环境的维度或者同是业务的维度，其实在查询场景上并不是同频率的，有的时候为了一些极少数出现的复杂查询做了过度的抽象设计，这一点做了很多的优化。

结合上面的问题进行了第一次架构调整。

架构 V2 比第一次架构更合理。除了上面提到的，把中间不易扩展的部分都替换成了一些支持分布式的技术组件和框架，比如 Redis 和 SSDB 都换成了 Codis，比如文件换成了 S3/HDFS 。

写在最后

上面是前两次架构的经验分享，诸葛io现在也在第三次架构优化的过程中，这一次更多是业务领域的突破和延伸。

在过去一年中，作为一个 SaaS 公司，诸葛io面临着各种挑战，不同于私有部署的资源分散，SaaS 公司满足业务的同时也需要保障服务质量，任何一个小的更新和优化都需要多方面的检查和合适。上面提到的只是一些能结合业务有共性的优化的问题，团队其实遇到的问题要远远不止于此。

底层技术上，从一开始底层硬盘的存储优化，到系统参数调优，包括上传服务器、数据仓库等底层涉及到的系统参数，如连接优化，UDP/TCP 连接优化等等，再到开源平台的参数和配置测试和调优，例如 Kafka 的分区调整/参数配置，Greenplum 的资源队列，内存资源参数，查询参数的测试优化等等。这些也希望大家在自己的架构设计和实践中不要忽视，要多去结合自有的机器类型（IDC 或者云机器），机器配置，业务需要进行调整。

-FIN-

（编辑：开发网_商丘站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!