实时数据中心建设思路与企业实践|青训营笔记
这是我参与「第四届青训营」笔记创作活动的的第15天。
一、课程概述
- 企业数据架构:包括计算/存储引擎、数据集成、数据治理、数据开发
- 数据中心案例
- 实时数据生产:Lambda架构、流计算核心业务问题、实时数仓
- 数据服务:OLAP引擎、稳定性
二、详细内容
1. 企业数据架构
- 企业整体数据架构:基础引擎、数据集成/生产/服务、开发和治理工具
- 关键模块及数据流向
- 数据集成:业务数据收集、大数据系统内传输
- 数据服务:统一数据服务架构
1.1 企业数据架构
- 行业数据
- 开发工具套件
- 数据开发
- 数据集成
- 发布运维
- 数据资产
- 数据出口
- 数据服务
- BI分析
- 数据生产
- 离线生产
- 实时生产
- 数据集成
- 业务数据收集
- 实时数据分析
- 计算/存储引擎
- 数据治理
1.2 数据集成
- 业务数据收集
- CDC
- 数据流向:业务数据库->数据系统
- LOG
- 数据流向:client/server LOG->数据系统
- CDC
- 系统间同步传输
- Flink:传入/传出 Kafka,MySQL,Redis,Hive,HBase...
1.3 数据生产
- 离线生产(flink+Kafka)/实时生产(Spark+Hive)
- 数据流向:原始数据->数据处理pipeline
- 存储引擎:redis/HBase/ClickHouse/Doris
1.4 数据服务
-
数据流向:数据系统->业务系统
-
元信息:流程管理/数据管理/元数据管理
-
数据总线
- API编排/鉴权/限流/熔断/降级
-
查询解析/逻辑query/物理query/查询优化/查询编排/SQL执行/结果合并
2. 数据中心案例
- 房产业务模型
- 客户(需求方)买/租房子
- 业主(供应方)卖/租房子
- 经纪人(服务方)->客户:新增/通话/带看/成交
- 经纪人(服务方)->业主:拜访/跟进/通话
- 经纪人(服务方)->房子:新增/实勘
- 核心数据指标
- 供需:房源/客源;房增/客增
- 过程:通话次数/带看次数
- 结果:成交量
- 数据查询要求
- 数据中心看板查询条件
- 时间范围:今天前任意日期范围
- 业务类型:租赁/买卖/全部
- 数据展示
- 查询条件下每个经济人的汇总数据
- 支持下钻明细数据
- 技术要求
- 300ms内返回结果
- 数据实时秒级
- 数据中心看板查询条件
3. 实时数据生产
3.1 数据产出目标
- 用户根据日期/业务类型查询经纪人汇总数据
- 目标数据产出粒度:经纪人+业务日期+业务类型
- 生产可行性
//生产逻辑
SELECT dk.date, dk.staff_id, house.house_type, Count(id) as dk_cnt
FROM dk
LEFT JOIN house on dk.house_id = house.houseId
WHERE audit_status = 1
GROUP BY dk.date, dk.staff_id, house.house)type
3.2 计算分析目标
- 开发效率:较快满足用户需要
- 资源成本:计算效率高
- 数据质量:准确无误、数据实时
3.3 计算架构-Lambda
-
架构模型
- batch layer
- immutable master data
- precompute views
- serving layer
- precompute views -> batch views
- increment views -> query
- batch layer
-
数据产出
- 离线数据产出和实时数据产出汇入同一张表
- 对表进行查询即可返回数据
- 问题:若有离线计算数据变更如何更新?
- 额外记录过去数据的修正
- 离线和实时存在相关性:离线数据可能在实时变更
3.5 计算架构-全量计算
- 用实时引擎来计算所有数据
- 全量原始数据->Flink->数据仓库
- 发生离线数据变更时
- 取最新的快照->计算->产生回撤retract处理
- 数据自然更新
- 如何获取全量原始数据?
- 数据湖:能达到;实时性相对差
- CDC:取原始数据库+增量;其他数据形态 LOG等数据如何解决?
3.6 计算架构选择
| 目标 | Lambda | 全量计算(较优) |
|---|---|---|
| 开发运维效率 | 效率低;存在实时离线两套开发任务和merge逻辑 | 效率高;只存在一套实时任务 |
| 资源效率 | 计算资源占用高:离线全量(例行任务)+实时增量 | 状态存储成本相对高:全量(首次冷启动)+增量 |
| 数据质量:实时、准确性 | 符合要求 | 符合要求 |
3.7 全量数据获取
- Hybrid Source
- Hybrid base(Hive)+ Kafka
- 组装历史数据+实时数据
- 准确性:处理去重/更新 retract
- 使用row number+retract机制
SELECT *
FROM (SELECT *, row_number()
OVER (PARTITION BY id ORDER BY time DESC)
AS rn FROM dk)
WHERE rn = 1
- join乱序问题
- 当T1 join T2时 若T2没有T1的key,会发送null;当T2收到后会回撤null,再发送一条JOIN后结果;但T2下游收到这两条的顺序不定,可能回撤了JOIN后结果;
- 增加reorder算子
3.8 计算效率
- join算子逻辑
- 关联触发:左右流互相关联触发
- minibatch join
- 中间数据可以抵消
- 抵消批次内变更导致的中间数据
- 时效性换取效率
3.9 数据质量
- 任务稳定性
- 直接结果:消费堆积 MQ-LAG
- JVM:GC耗时、次数
- 资源:CPU、内存
- 算子:倾斜、反压
- 持续正确:监控比对
- 异构比对:实时/离线比对
- 时间趋势:同环比变化
- 异常值占比
3.10 数仓建设
- 数据复用,减少重复开发
- ODS层:原始数据
- DWD层:数据明细宽表
- DWM/DWS指标层:对数据进行聚合加工;KV存储方案
- APP层:构建应用大宽表服务应用
- 数仓元数据管理
- 数据资产:管理查询
- 生产:免DDL
4. 数据服务
4.1 查询速度
- 引擎选择
- 指定key查询value:redis
- 分析join/agg:ClickHouse/Doris
- 查询逻辑模型简化
- 查询优化分析
- 关注目标:不需要的信息不关注
- select带看量/通话量:行存大量IO每行寻找需要的列/列存直接取出对应列文件
- 计算处理:能不能足够快(例如count/sum/avg等聚合函数)
- 计算向量化:CPU支持向量化指令,单指令多数据处理
- 原始信息:单表筛选够不够快/信息关联够不够快
- 根据日期筛选:数据存储时时间当作分区目录
- primary key构建:索引数据按行组织
- primary key查找-数据分片指针:压缩文件块偏移/解压文件内偏移
- IO优化
- broadcast join广播小表
- shuffle join左右表shuffle by key
- bucket join左表按join key分布
- colocate join左右表已按join key分布
- 关注目标:不需要的信息不关注
- 应用优化
- 原始信息关联
- local join
- 预关联,直接生产大宽表
- 目标为减少查询现场join,生产侧把相同粒度指标及相关维度数据关联成数据宽表
- flink聚合函数:map数据结构
- 计算复杂度
- 预计算:提前聚合到特定粒度
- 提升信息密度:bit化
- 将多类信息转化为多列0/1代表是否有 one-hot-encoding
- bitmap:roaringBitMap稀疏优化;分桶高16位,低16位数据稀疏用数组,否则bit;高效的交并等运算数据结构
- 原始信息关联
4.2 稳定性
- 熔断触发策略
- 错误率每秒超过10%
- 响应时间>5s
- 直接返回失败
- 限流:根据查询客户端、接口配置查询限额
- 降级:主备存储/服务集群,降级预案
4.3 查询元数据管理
- 指标口径管理
- 查询生成
三、个人总结
本节课学习了实时数据中心建设的相关方法,从案例触发了解了企业的数据架构以及实时数据生产的相关实现方式,为今后深入了解各企业实际的数据中心服务打下基础。