- 作者简介:本文来自诸葛io创始人孔淼的技术分享。诸葛io是业内领先的智能数据决策平台,也是国内早期的数据分析践行者。本文将从诸葛io平台设计实例,分享大数据平台的技术演化之路。
如今,数据分析能力正逐渐成为企业发展的标配,企业通过数据分析的过程将数据中的信息提取出来,进行处理、识别、加工、呈现,最后成为指导企业业务发展的知识和智慧。而处理、识别、加工、呈现的过程从本质上来讲,就是实现对数据的采集、清洗、加工、加载、建模分析,再到可视化的过程。
采集是指集中企业待分析的原始数据的过程,例如可能是包含但不限于以下:
- 企业服务器的日志;
- 企业各种信息系统的数据(CRM/ERP / 数据库);
- 企业的网站 / App / 小程序等客户端的用户行为记录;
- 使用的第三方系统(客服、IM、HR)提供的 API;
采集的方式基本上分为两种:
PUSH 模式:企业的数据一般来讲都是散落在很多地方,各种系统或者各种服务器,所以有一个数据采集中心,然后在各个数据产生的位置都有一个 agent(可以认为是采集程序)然后朝数据采集中心发送数据的过程就是 PUSH,比如在 App 或者网站植入了 SDK,定期发送采集到的用户行为数据到服务端的过程就是 PUSH 模式;
PULL 模式:企业有数据采集中心,从采集中心去访问获取各个数据产生点的数据,这个过程就是 PULL,比如从企业的数据中心去调用第三方系统的 API 获取数据,就是 PULL 模式。
数据清洗的过程是指对数据进行一些处理,过滤无用的信息,规范得到能用到的数据。包括但不限于以下情况:
- 过滤 SPAM 垃圾数据,例如被攻击 / 造假 / BUG 产生的大量数据
- 抽取有用字段,例如上传的数据包含的信息很多,只用到一小部分
- 原始数据有很多格式不规范,要统一格式
数据加工是指清洗后的数据,还需要补充一些信息,可能是通过数据库查询出来的,也可能是通过计算规则计算出来的,或者算法技术加工出来的新字段。
例如,数据里面有个 ip 地址,需要计算出用户的地理位置,那么地理位置就是加工出来的字段。一般来讲,对于大多数大数据分析平台而言,加工是很重要的过程,基本上最后可用来进行分析的数据,要通过这一步充分完成加工计算。
数据加载是指把加工后的数据加载到合适的存储,可能是 Hadoop 集群的 HDFS 上,也可能是某个数据库,有可能是文件等等其他存储类型。
建模分析是指在查询前需要把数据进行处理,以优化查询,例如以下:
- 数据仓库建好了仓库模型,要把数据加载到数据仓库中
- 需要做数据索引,把数据进行索引优化
数据模型很重要,是整个数据处理分析的核心之一。每个企业都有自己的核心业务,以及核心目标,并且也有各自的数据源以及数据类型,所以也就意味着每一家企业的数据模型多少都会有些差异,也就是最个性化的一个地方,数据仓库就是这个数据模型的载体,一般来讲数据就是数据库技术,常见数据库之外,还有 Infobright,Greenplum,Vertica,也有基于 Hadoop 技术的,用 HDFS 作为基础的存储,然后使用的查询引擎,包括 Imapla,Presto,SparkSQL 等等。
通常而言,数据团队要进行复杂的查询和分析,都是在此基础之上,通过 SQL 语言或者代码查询来实现的。
可视化是最终分析结果要展示的过程,例如 "双十一" 酷炫的图表,一般企业都有自己的数据看板等等。
可视化背后主要是执行 SQL 或者运行代码得到的数据结果,可能是一维,也可能是二维,还有可能是多维,然后选择合适的图表类型进行展示,例如 "线状图"、"柱状图"、"饼状图"、"雷达图"、"中国地图" 等等。
以上是通用的大数据平台整个数据处理的方式,接下来就从诸葛 io 与通用的数据平台的差异入手,然后带入诸葛 io 的技术设计。诸葛 io 的整套技术能够做到的是,对企业分析流程的效率提升。
自建或者第三方统计平台(百度统计 / 友盟 / Talkingdata)+ 数据 BI 团队(早期团队人数很少,甚至是一两个工程师兼任);
自建或者第三方统计平台:大多都是汇总统计指标平台。对通用指标(例如 PV、UV、DAU、留存)的计算,对企业设定好的业务行为(打车、订单、参与、金额)等汇总统计人数或者次数,数据平台存储的都是指标的汇总结果。指标的选择和下钻分析都需要数据团队的支撑。
数据 BI 团队:完成基础数据平台的搭建,并且梳理核心业务分析目标,对基础数据进行采集建模,并完成各个部门的分析需求。
所以最上面那张图就是大多数企业现在的分析现状:
基本上先统一由大数据部门整理输出各部门日常固定的数据指标,然后做个可视化,比如一个简单的页面
如果有新的分析需求,已经建模好的,那么数据团队就需要根据业务去写 SQL 然后得到结果,如果没有建模好的,就需要开始采集原始数据,然后重新开始清洗,这样一个过程,往往都比较反复耗时,分析效率很低
主要原因是,这样一种分析流程,是由固定的业务指标驱动数据的采集和处理,然后数据处理的过程基本上都是多维汇总的统计和计算
所以也就造成了问题:各个业务部门的分析需求需要依赖数据团队专业的数据分析能力进行问题建模,并且依赖他们 SQL 语言或者代码能力完成分析目标。但数据部门往往也有核心的分析需求和任务,所以公司变大过程中很多问题变得很低效。
诸葛 io 的整个数据处理也是符合上面的整个流程,和其他数据分析平台,尤其是传统数据平台,按照处理过程抽象的差异主要如下:
诸葛 io 的分析能力远远大于目前大多数的统计平台,诸葛 io 把很多深入的分析场景,依赖数据团队进行建模以及 SQL / 代码等专业能力,变成了可视化的分析组件。这样极大的提高了企业的数据分析效率,并且还有专业的数据分析看板,辅助企业梳理了解分析需求和目标。
诸葛 io 的亮点如下:
除此之外,细致入微的产品设计,贯穿分析过程,例如:
点击数字到用户画像的洞察;
漏斗的无序和有序;
用户群 "新增后 X 天";
还有更多的场景,可以去感受和体验;
这样一来,回到刚刚的图片:
在建模时非常抽象,并且基于独立用户跟踪了整个业务的流程,所以不只是指标任意的配置可视化,很多以前依赖于 SQL 和清洗代码的逻辑,也变成了交互式的查询组件,所以能提高效率,那诸葛 io 是怎么做到的呢?先来看看整体的架构:
首先看看数据采集端,提供丰富的接口和 SDK,能够采集到企业各个有用户行为数据的地方,目前来讲,主要分为以下:
Android 客户端 : Android SDK
iOS 客户端 : iOS SDK
网站或微站 H5 :Javascript SDK
小程序:小程序 SDK
日志: 服务端 Restful 接口
CRM 数据库 :导入工具
也就是采用了 "PUSH" 模式,各个端采集用户的行为,然后再按照规则发送给数据收集中心,各个端也就写了一些 SDK,让开发者调用采集,然后就是数据收集端:
上图是据收集架构: 核心就是 LVS+Nginx+Lua,诸葛 io 没有用比较重的后端语言来采集,而是选择了比较轻的 Lua 脚本语言,在 nginx 中集成就能完成高并发的复杂,LVS 做解析服务器的负载均衡,后面是多个 Nginx,然后 Nginx 本身就是高性能高并发服务器,所以并发的承载能力非常强。
诸葛 io 采用的是 HTTPS 加密传输,以及支持 HTTP2 协议:
采用 HTTPS 的原因是,防止数据在传输过程中被抓包截获;
采用 HTTP2 协议,服务端的处理性能能够极大的提升,连接也有优化。
使用 LVS 的原因是,虽然 Nginx 的性能很高,但是在高并发压力情况下,能够快速添加 Nginx 节点,再加上数据采集是异步,所以大流量情况下,LVS+Nginx 基本上都能保证不会出现连接等待的情况了。
Lua 是一种轻型的脚本语言,直接在 nginx 配置中嵌入,在很多游戏的服务端架构以及电商秒杀的架构中使用。服务端接收到上传数据之后,Lua 会进行解析,并且添加上传时一些信息(ip,服务端时间,User-Agent)等等,然后 push 到 Kafka 的集群。
这套架构也是在诸葛 io 的日上传数据量逐步上涨过程中,逐步演化出来的。
简单来讲,数据采集具有高并发、高伸缩性性、HTTPS 安全传输的特点。
然后就是数据清洗。诸葛 io 采集到的数据会有以下几个问题需要处理:
- 垃圾数据:乱码或者埋点错误产生的数据
- 作弊数据:恶意进行注入伪造的数据
- 淘汰数据 : 已经弃用的 SDK 版本数据
所以会完成对于上述数据的清洗。清洗完的数据,诸葛 io 还会进行一些信息加工,包括但不限于以下:
- 识别用户和设备的身份关系
- 加工字段:地理位置、UTM 推广信息、设备、系统版本(网站或者微站根据 UA)
- 事件行为匹配系统 id
加工信息之后,还会对数据按照数据模型进行格式转化和预计算处理,得到所需要的最优于查询的数据。
关于数据清洗加工部分,和其他大数据技术还有一些差异:
- 独立的用户行为跟踪;
- 基于用户身份的数据整合;
- 精准的用户和设备关系识别;
- 事件的标签化;
接下来是数据加载。数据加载的过程,就是把数据处理后的结果写入存储,这里,诸葛 io 主要加载的目标位置有以下:
因为诸葛 io 同时支持 SaaS 和私有部署,私有部署采用的方案会有差异,S3 和 HDFS 都是文件访问,所以业务层基本是一致,S3 是因为存储成本低,HDFS 是大多数企业的 Hadoop 平台。加工后的数据同上。
模型仓库,Redshift 和 Greenplum 都是基于 PostgreSQL 的。加上自定义函数,在数据访问层保持一致。
然后在建模分析的过程,建模分析的核心是诸葛 io 的数据模型,也就是数据仓库设计,诸葛 io 现在的核心数据模型,分为以下主题:
用户:用户的属性信息;事件 / 行为(包含属性信息和触发环境);行为发生平台:平台(设备)的基础信息;
诸葛 io 的数据模型底层都已经对用户和行为进行建模,从上层指标的计算,可以直接下钻用户群体,并且对于用户的行为历史也有完整的还原和实时的洞察。
传统的数据分析平台都以设备进行统计,诸葛 io 是基于用户的,所以用户和设备的关系精准还原。
诸葛 io 的数据查询和访问:
数据访问层,是诸葛 io 把基于数据仓库的 SQL 查询访问抽象了一层服务,分为对内和对外两部分,用以控制对数据访问的统一管理。主要分为两部分:
对内是通过统一的 API 服务来进行访问
对外是有 Open API 的开放平台
可视化查询主要是通过诸葛 io 的网站进行完成,并且在技术上也是基于数据访问层实现。可视化在诸葛主要分为两部分:
1. 数据指标展现的可视化
2. 查询操作的可视化
指标展现可视化,包括不限于表格、柱状图、线图、漏斗。回到整个架构上:
可以看到有消息中心,诸葛 io 的消息中心是以 Kafka 为中心进行设计的。
消息中心主要处理包含以下业务消息的汇集和分发:
- 各种 SDK 或者工具上传的数;
- 数据清洗产生的中间的数据;
- 模型结果数据;
- 备份数据;
- 其他流式处理数据;
Kafka 具有多消费组的特点,也就意味着,可以在不同应用场景下对统一数据进行多种处理,并产生多种应用,例如下面场景:
收集到各种数据,并会添加到 Kafka 消息中心,然后会有以下不同消费应用。
实时计算中心,诸葛 io 用的是 Spark Streaming 进行处理,也有其他套件辅助进行一些数据挖掘,实时数据和关系缓存,诸葛 io 用的是 Codis 以及 SSDB,Codis 是分布式的 Redis 实现框架(由前豌豆荚团队开源)诸葛 io 会用来做分布式的消息以及状态存储,而 SSDB 是基于 Redis 协议的硬盘实现(作者是懒投资的 CTO 吴总)诸葛 io 会存储一些键值比较大或者多的数据,例如实时数据以及数据缓存。
基础存储刚刚讲过了主要是 S3,索引用的是 Elasticsearch,比如查询时的提示等等,在线多维实时数据处理查询就是 Redshift 和 Greenplum 了,然后统一了整个数据访问层以及 API,并且分为内部和外部 API,对外就是网站和开放平台了。
来源: http://www.tuicool.com/articles/N7JJFnI