实时数据体系研究

01-背景

传统意义上的数据仓库主要处理T+1数据（即：今天产生的数据分析结果明天才能看到）
随着互联网的发展，越来越多的业务指标需要实时查看，以便于更好的进行业务分析，尤其在举行活动的时候，能够更好的把握活动的各项指标趋势，从而更好的调整策略，达到活动的目标。
目前面临两方面的问题：
1.随着数据时效性在企业运营中的重要性日益凸现，例如，实时推荐、精准营销、广告投放效果、实时物流等。数据的实时处理能力成为企业提升竞争力的一大因素，最初阶段企业主要采用来一个需求，编写一个实时计算任务的方式来处理实时数据，随着需求的增多，计算任务也相应增多，并且不同任务的开发人员不同，导致开发风格差异化，该阶段的实时数据处理缺乏统一的规划，代码风格差异化严重，在维护成本和开发效率上有很大障碍。
2.对于常规经营分析类报表的时效性要求主键提升，传统的T-1模式已经不能满足需求。

为避免上述问题，人们参照数据仓库的概念和模型来重新规划和设计实时数据处理，在此基础上产生了实时数据仓库（实时数仓）。

02-需要满足的实时场景

举例：
统计分析类【实时数仓】
通过采集信令，关联B域用户资料、用户画像，O域基站信息，形成小时/日/周/月等游客信息，统计行政区域和景区的游客数、来源地、游客画像。
通过实时采集资料、产品、资费等信息，每半小时统计发展量情况
通过镜像库实时采集TF_USER_4G、台账表和产品受理表，加工出每日实时新发展及受理的重点业务数量（如移网、冰激凌、宽带、千兆宽带、鹏博士等）

实时业务稽核【实时数仓】
在稽核账期内违规为用户办理两条及以上0元流量包优惠资费。
场景触发类【实时场景中心】
对新用户二次插卡及流动高危地区的用户进行二次人脸鉴权识别，通过（流量、信令）识别用户行为轨迹

03-目前主流互联网公司的实时数仓架构对比

1）阿里巴巴菜鸟的实时数仓结构

技术选型
计算引擎：Flink
数据存储：KAFKA+ADB
实时OLAP库：ADB（原名ADS）
数据架构：
DWD实时数据明细层
DWS轻度汇总层
DWS高度汇总层
2）知乎的实时数仓结构

技术选型：
计算引擎：Flink
数据存储：KAFKA+Durid
服务应用：
实时OLAP库：Durid
Druid 负责即席查询，多维分析
并发查询：HBase+Redis
数据架构：
原始数据层
明细层
Binlog 日志的处理主要是完成库或者实例日志到表日志的拆分，对流量日志主要是做一些通用 ETL 处理，
汇总层
明细汇总层是由明细层通过 ETL 得到，主要以宽表形式存在。业务明细汇总是由业务事实明细表和维度表 Join 得到，流量明细汇总是由流量日志按业务线拆分和流量维度 Join 得到。

3）美团的实时数仓结构

技术选型：
计算引擎：Flink
数据存储：KAFKA+Tair
应用服务：
实时OLAP库：Tair+MySQL+druid
并发查询：ES
数据架构：
ODS层
Binlog 和流量日志以及各业务实时队列
数据明细层
业务领域整合提取事实数据，离线全量和实时变化数据构建实时维度数据；
数据汇总层
使用宽表模型对明细数据补充维度数据，对共性指标进行汇总

3）网易严选的实时数仓结构

技术选型：
计算引擎：Flink
数据存储：KAFKA+HBase
应用服务：
实时OLAP库：GP+MySQL
并发查询：HBase+Redis
数据架构：
ODS层
Binlog 和流量日志以及各业务实时队列
数据明细层
业务领域整合提取事实数据，离线全量和实时变化数据构建实时维度数据；
数据汇总层
使用宽表模型对明细数据补充维度数据，对共性指标进行汇总

4）OPPO的实时数仓结构

技术选型：
计算引擎：Flink
数据存储：KAFKA
应用服务：
实时OLAP库：Druid+MySQL
并发查询：HBase+Redis+ES
数据架构：
原始层
明细层
汇总层

5）总结
根据对多个互联网公司目前的实时数仓架构，对比分析。
实时架构：
实时数仓统一采用目前比较流行的kappa实时架构。
维表数据实时还原，区别于lambda架构的离线维表数据，实时、离线数据很难保持一致结果，导致实时关联离线维表计算结果有一定的失准。
支撑应用：
多维数据分析
实时报表
实时交互式分析
实时大屏
实时明细数据查询
数据架构
原始数据层
实时接入两类数据：事实原始数据+业务库Binlog
业务库Binlog等同于目前CBSS的OGG消息，用来实时还原业务库维度数据。
明细数据层
对原始事实明细数据做清洗，并关联实时还原的维度数据，形成明细宽表，通过实时OLAP库，提供强大的数据分析能力
汇总数据层
基于实时明细数据以及实时维度数据，汇总计算实时汇总指标，形成多维汇总表，通过实时OLAP库，提供实时多维分析、实时报表、实时大屏等能力

04-实时数仓的目标架构及演进

1）实时架构：Lambda与kappa简介
lambda架构：

分别由批处理层、实时处理层、以及服务层组成，其中批处理层与流处理层并行。
缺点：实时、离线数据很难保持一致结果

kappa架构：

区别于lambda架构，只有实时处理层以及服务层
实时接入的事实数据，与实时还原的维度数据共同计算，避免结果的计算失准。

2）总部目前实时能力现状
目前总部实时数据能力，属于传统的lambda架构，维表由离线系统提供静态数据，相对于统计分析类的应用需求，不能提供准确的数据计算能力。适合场景触发类的应用

3）总部目标架构以及与各项目间关系
为了能够支撑目前总部日益增加的实时统计分析需求，需要新增构建联通实时数仓，同时，不与实时场景中心的能力产生冲突。
数据接入上，对于事实明细数据沿用原有模式，由实时场景中心统一做数据接入，对于业务系统OGG消息，由实时数仓承担维度数据实时还原的工作。
支撑的应用场景上，实时场景类能力需求，继续由实时场景中心来支撑，对于多维统计分析、实时报表、实时交互式分析等能力需求，由实时数仓来支持。
其实实时数仓所支撑的需求，与离线数仓比较类似，只是数据更新时间上不同而已。未来的终极目标，与离线数仓一起，构建统一的批流一体数据仓库。实现离线数据分析实时化

实时明细宽表：
计费详单冗余用户属性。【长周期存储】
实时汇总指标表：
省份需求：
实时采集TF_USER_4G、台账表和产品受理表，加工出每日实时新发展及受理的重点业务数量（如移网、冰激凌、宽带、千兆宽带、鹏博士等）
实时5G用户发展量、实时用户发展量、实时充值量、实时产品订购量、实时出账收入、实时融合业务发展量，允许多维度统计分析

05-组件技术选型

组件选型上，目前几乎没有争议的两类组件如下：
计算引擎：Flink
数据存储：KAFKA
但对于OLAP能力选型上目前有两个大方向：
选择纯开源技术，面临不同的场景需要选用不同的数据库组件
高并发单表数据查询：HBase、ES
单表多维分析：Durid、CliclHouse、Kylin
交互式复杂分析：GP、Impala
选择上用组件，像Oracle一样但组件能够应对不同的场景
首选：阿里ADB
在ADB的官方文档中给出了ADB的能力：
快：ADB采用MPP+DAG融合引擎，采用行列混存技术、自动索引等技术，可以快速扩容至数千节点；
灵活：随意调整节点数量和动态升降配实例规格；
易用：全面兼容MySQL协议和SQL；
超大规模：全分布式结构，无任何单点设计，方便横向扩展增加SQL处理并发；
高并发写入：小规模的10万TPS写入能力，通过横向扩容节点提升至200万+TPS的写入能力。实时写入数据后，约1秒左右即可查询分析。单个表最大支持2PB数据，十万亿记录。