实时数据体系研究

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数据,十万亿记录。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值