本文来自诸葛io创始人孔淼的《诸葛io，面向数据智能时代的大数据实践》之下篇—诸葛io的业务架构实践。
在上篇「诸葛io，面向数据智能时代的大数据实践（上）」，我们讲到大数据的三次浪潮下诸葛io是如何诞生的，本文为诸葛io的业务架构实践篇。
1．图1自下而上是诸葛io当前的主要业务架构：
图1
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有算法组和分析组两支队伍对数据进行一些复杂的挖掘和分析，包括：
i) 用户行为路径挖掘
ii) 行业模型和看板
iii) 流失和预测分析
iv) 自动化的分析报告
d. 开放API。我们提供给客户的不仅仅是汇总统计的数据，还允许用户直接访问和导出自己的原始数据和加工后的数据，因此我们把一些查询封装成了API的逻辑，允许客户进行二次开发或者调用，所以我们有一个开放的API平台。
诸葛io的架构经历了两次迭代，目前正在进行第三次的重构。我们重构的目的包含两方面：第一次重构主要是技术方案的瓶颈突破，第二次重构主要是业务领域问题的延伸和拓展。
架构永远是贴合业务的。诸葛io是新一代分析平台里面最早上线的。我们从2014年10月开始研发，上线于 15年3月份。当时，我们需要让产品快速上线，验证想法，所以架构搭建的比较简单，包括我在内的6个工程师，完成了整套从数据采集到数据处理到网站到前端 可视化的大数据架构。由于我们的研发团队在大数据领域经验比较丰富，能解决各种技术难题。当时我们搭建的简单架构如图2：
图2
图2：诸葛io第一次上线的架构实践
初次上线的架构在刚开始的一段时间内一切正常。随着业务发展，诸葛io的客户量逐步增加，如暴走漫画、小影、墨迹天气等大体量的客户陆续接入平台，这个时候也面临着诸多考验。
2.图3是我们第一次上线架构数据处理流的架构图，标出了三个问题点：
图3
图3：诸葛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的产品找到我们，我 们还是要解决查询性能和数据扩展的问题 。
图4
从数据存储可扩展性和计算资源的分布式调用来综合考虑，我们选择了Greenplum平台。
3.我们在数据处理上也做了一些技巧，包含两部分：
图5
1）预计算。对于互联网用户分析，大多数是分析特定行为，特定类型（新增/活跃），特定平台（Android/iOS/JS），特定渠道的用户，所以这里其实有一些集合计算法则和技巧可以利用，我们基于这个写了一个数据预处理的服务诸葛PreAg
2） 模型优化——业务维度分层。很多人在设计模型是过于去找逻辑对等以及对象关系，但是其实从应用场景来看，比如同是环境的维度或者同是业务的维度，其实在查询场景上并不是同频率的，有的时候为了一些极少数出现的复杂查询我们做了过度的抽象设计，这一点我们做了很多的优化。
结合上面的问题，我们并进行了第一次架构调整。
图6
架构V2比第一次架构更合理。除了上面提到的，我们把中间不易扩展的部分都替换成了一些支持分布式的技术组件和框架，比如Redis和SSDB我们都换成了Codis，比如文件我们换成了S3/HDFS
以上是我们前两次架构的经验分享，我们现在在进行第三次架构优化的过程中。这一次更多是业务领域的突破和延伸，在过去一年中，我们感受到了一个SaaS 公司面临的各种挑战—不同于私有部署的资源分散。SaaS公司满足业务的同时也需要保障服务质量，任何一个小的更新和优化都需要多方面的检查。上面提到的 只是一些我觉得能结合业务有共性的优化问题，我们团队其实遇到的问题远远不止于此。底层技术上，从一开始底层硬盘的存储优化，到系统参数调优，包括上传服 务器、数据仓库等底层涉及到的系统参数，如连接优化，UDP/TCP 连接优化等，再到开源平台的参数和配置测试和调优，例如Kafka的分区调整/参数配置，Greenplum的资源队列，内存资源参数，查询参数的测试优 化等，这些也希望大家在自己的架构设计和实践中不要忽视，要多去结合自有的机器类型（IDC或者云机器），机器配置，业务需要进行调整。
网友评论