大数据平台变革浪潮中，这家初创公司积累的值得借鉴的业务架构实践经验

前言：想要写一篇关于大数据平台的发展变革，以及诸葛 io 自身架构演变的文章，是因为在诸葛 io 上线的 20 个月里，我们经历了客户量从 0 到 10,000 的突破。今天，诸葛 io 作为新一代数据分析平台，累计了过万的企业用户，每月活跃客户数 2000+ 家，月有效行为数据处理量超过了 100 亿。期间，我们的研发团队面临过许多难题与挑战，同时，对于大数据平台的发展与架构也有更多的思考与沉淀。这些思考与实践，正是本文中将要和大家分享的内容。

大数据平台的三次浪潮

在讨论诸葛 io 这样的新一代数据分析平台之前，我们可以回顾一下 1990 年到 2016 年间，大数据平台经历的三次浪潮。

1 第一波浪潮

第一波浪潮起源于 90 年代，当时从计算机到软件大多还是企业级的，而数据分析就已经开始，这个时代也还是集中式软件时代，存储数据的成本也非常昂贵，所以大部分企业以 KPI 角度，抽取少量结构化数据，采取特定数据。代表企业如 MicroStrategy、Microsoft、Oracle，代表产品诸如 Sybase、Congos。这个时代能产生的数据有限，能处理数据的能力有限。

图 1

2 第二波浪潮

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

1. 网络带宽的升级优化，从 2g 到 4g，从拨号上网到光纤入户。
2. 围绕 **** 互联网信息化带来大量的数据产生，如门户网站，社交平台，内容和视频平台等。
3. 科技发展，从 PC 到移动设备到各种智能设备，都可以采集传输数据。

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

图 2

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

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

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

2）计算的可扩展性

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

3）存储的可扩展性

越来越大量的数据，如果只是本地文件存储或者数据库存储，效率越来越低下，所以保障访问和提高效率，可以灵活扩展存储数据也是要解决的问题。

大数据技术在这个阶段陆续诞生了从 Facebook 早期开源的 Scribe 到 Cloudera 的 Flume，到 Linkedin 的 Kafka，以及后来的 Flink 等数据流处理框架，熟知的还有 Spark/Storm/Samza 等实时处理技术。这个阶段，很多人都在提大数据和 Hadoop，但是我们做到的是数据流处理和实时处理以及存储方式的突破和革新，分析主体是分析中心化方式。由 BI 团队或者数据团队驱动，集中式的制定 KPI，数据采集集中之后会按照 KPI 进行处理展现。如果遇到多样化或者探索性的业务分析需求，还需要 on-demand（按需）去编写程序或者 SQL 来基于这些大数据平台获取结果。

3 第三波浪潮

发展到 2010 左右，互联网发展从信息化走向了服务化，创业方向也从之前的“门户时代”、“社交时代”，“垂直化门户时代”，“内容视频时代”走向了电商、出行、外卖、O2O 等本地服务。如果说面向信息化的时代更多的是基于流量广告等商业模式，面向服务化时代更多的是直接面对客户价值的变现商业模式，或者说消费者服务，所以从行业发展来看，服务类对分析的需求也要旺盛很多。

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

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

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

数据分析从行业、角色、部门和场景而言，都是差异化的。比如行业上，电商关注的是购买相关指标，内容关注的是阅读相关指标，社交关注的是参与度相关指标，工具关注的是功能使用情况。角色上，CEO 关注的是整体、财务各部门的 KPI；市场 VP 关注的是营销相关的子项目 KPI；销售 VP 关注的是销售阶段状态和结果相关的指标；如部门上，市场关注的是投放转化率等指标；产品关注的是功能留存率等指标。如果要更充分的满足分析需求，需要从 KPI 中心化分析转向分析去中心化，也就面临着又一次大数据平台的技术革新，也因此推动了大数据平台第三波浪潮的变革。

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

1. 分析由于行业经验的积累和行业经验的信息不对称而诞生
2. 大多数公司缺少专业分析经验的人和能构建数据分析平台的团队
3. 依赖数据分析团队集中分析的方式效率低下，需求排队。

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

图 3

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

第三波浪潮下的大数据平台，会从分析看板开始，有各个行业下各个业务部门所关注的指标，并且业务人员可以灵活的配置，同时对于复杂的分析下钻和数据探索的过程而言，业务人员也无需 SQL 或者代码，可以直接通过交互式的查询组件进行自助式分析和配置。大数据分析的基础技术已经逐渐成熟，而挑战就是基于行业理解下构建合理的数据模型，以及多维下复杂查询的效率。

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

诸葛 io 的业务架构实践

1 诸葛 io 当前业务架构

图 4 自下而上是诸葛 io 当前的主要业务架构：

1）数据采集端

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

2）数据接收服务

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

3）消息队列

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

4）多业务处理

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

a. 实时统计

为了减少对数据仓库的压力以及提高数据处理的效率，对于一些基础指标，比如新增、活跃、触发各种行为的人数等我们会进行实时统计，写入到内存数据库中。

b. 数据仓库

数据仓库是诸葛提供的深入用户行为、多维交叉分析以及行业分析模型的核心，所以底层的数据模型和加工的中间数据层主要是在这一步完成，完成后会写入到数据仓库底层的数据库中。

c. 数据索引

为了提高数据查询和检索的效率，我们会对一些维度数据生成索引，会写入到索引数据库中。

d. 数据备份

我们对原始上传数据以及中间清洗后的数据会做多重备份，达到一定程度的灾难恢复保障，会写入到文件中。

5）数据访问层

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

6）数据应用系统

我们的数据应用主要包括以下部分：

a. 诸葛 io 网站

网站是 zhugeio.com 提供给企业客户交互式自助分析的平台，包括了丰富的功能

b. 内部服务

主要是 DevOps 和业务监控平台需要调用一些接口进行状态监控和跟踪，保障服务质量以及稳定性。

c. 数据挖掘

诸葛 io 有算法组和分析组两支队伍对数据进行一些复杂的挖掘和分析，包括：

1. 用户行为路径挖掘
2. 行业模型和看板
3. 流失和预测分析
4. 自动化的分析报告

d. 开放 API

我们提供给客户的不仅仅是汇总统计的数据，还允许用户直接访问和导出自己的原始数据和加工后的数据，因此我们把一些查询封装成了 API 的逻辑，允许客户进行二次开发或者调用，所以我们有一个开放的 API 平台。

图 4

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

架构永远是贴合业务的。诸葛 io 是新一代分析平台里面最早上线的。我们从 2014 年 10 月开始研发，上线于 15 年 3 月份。当时，我们需要让产品快速上线，验证想法，所以架构搭建的比较简单。包括我在内的 6 个工程师，完成了整套从数据采集到数据处理到网站到前端可视化的大数据架构。由于我们的研发团队在大数据领域经验比较丰富，能解决各种技术难题。当时我们搭建的简单架构如图 5：

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

初次上线的架构在刚开始的一段时间内一切正常。随着业务发展，诸葛 io 的客户量逐步增加，如暴走漫画、小影、墨迹天气等大体量的客户陆续接入平台，这个时候也面临着诸多考验。

2 第一次上线架构得到的经验

下图是我们第一次上线架构数据处理流的架构图，标出了三个问题点：

图 6：诸葛 io 第一次上线的数据处理流:

1）数据上传延时高。

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

a.HTTPS 建立连接和加密验证过于耗时

HTTPS 比普通的 Http 的三次握手多一个 SSL 验证过程，我们第一次上线使用的是比较老的 Nginx，并且只有单 Nginx 的支撑，握手压力过大。虽然我们在系统参数调优上做了很多尝试，但是本质还是需要一次架构优化，因此选择了在 Nginx 前加了一个 LVS，把 Nginx 升级到最新版，并且支持了 HTTP2 的协议，扩展了 Nginx 的服务器数量。

b.数据上传模块的设计缺陷

诸葛 io 之前的数据上传模块逻辑是：客户端上传数据到服务端，服务端接收后会解压并且加入一些上传的 IP、上传时间等字段，然继而写入到 Kafka 消息队列中，然后返回给客户处理结果。这个过程不需要客户端等待处理过程，需要我们团队进行优化，优化后的逻辑是客户端上传成功后即返回。我们之前的服务端是用 C++ 编写的，我们直接参考一些秒杀的高并发架构进行了优化，在选择了 Nginx+Lua 后，在没有数据丢失的情况下，单节点每秒并发处理完成数提高了 5 倍多。

2）数据处理流使用的是多 java 进程方式

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

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

我们的数据库选型一开始用的是 Infobright 的社区版，国内之前使用 Infobright 作为数据仓库的比较有名的公司是豆瓣，虽然 Infobright 不是分布式的，我们考虑到大多数 App 或者网站的 DAU 不会超过百万，并且 Infobright 的压缩和性能都不错，对于我们这种 SaaS 的早期创业公司而言，成本也会有保障。当我们的数据越来越大的时候，加了控制路由，会分发不同应用到不同的 Infobright 中。但是随着我们业务发展的逐步突破越来越多的百万甚至千万 DAU 的产品找到我们，我们还是要解决查询性能和数据扩展的问题 。

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

图 7

3 数据处理上的技巧：

我们在数据处理上也做了一些技巧：

包含两部分：

图 8

1）预计算

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

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

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

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

图 9

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

以上是我们前两次架构的经验分享，我们现在在进行第三次架构优化的过程中。这一次更多是业务领域的突破和延伸，在过去一年中，我们感受到了一个 SaaS 公司面临的各种挑战—不同于私有部署的资源分散。SaaS 公司满足业务的同时也需要保障服务质量，任何一个小的更新和优化都需要多方面的检查。

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

作者介绍

孔淼，前 37degree CTO，毕业于华中科技大学软件工程专业。曾受邀担任李开复博士的技术助理，负责处理工场各部门以及李开复的技术需求。后加入 37degree 团队开始创业。在 37degree 期间，曾带领团队服务过 CCTV、海尔、宝马等知名企业。2014 年底，孔淼开始打造诸葛 io，目前正在为 Intel、联想、光明乳业、墨迹天气、罗辑思维、在行、暴走漫画等 9000+ 企业提供数据智能分析服务。孔淼被李开复博士钦点为「最具潜力的技术人才」，并获评 2015 年创业邦「30 岁以下创业新贵」。-- 我们需要更多的各种热爱技术的小伙伴加入我们，与我们一同成长，我的邮箱是 km@zhugeio.com。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。