实时数仓1

实时数仓

离线→实时

介绍

• 从某种角度而言，实时数仓是针对基础实时应用的优化版，避免实时处理的烟囱式发展，分层管理，数仓思想，逻辑、性能优化，提高了代码的复用率和整体生产效率。
• 从离线到实时的角度而言，实时性更强了，能够满足即时性的需求，数据本身的价值有所增加。

抛出问题

有离线数仓了，做实时数仓，是否能兼顾到以前的指标体系，是不是可以直接替代？
类似于画像体系是否可以在此基础上进行构建？
实时数仓是否可以是实时平台的基础？
架构有没有明确的定义？

框架变化

• 计算：Hive→Flink/Spark Streaming

• 存储：HDFS→Kafka/Hbase/Redis/MySQL

存储框架

框架	优势	劣势
Mysql	事务	查询、存储的性能瓶颈
Elasticsearch	吞吐量大，快速横向扩展，查询速度快	使用成本相对略高，复杂操作性能较低
Druid	超大数据量、通过Kafka获得实时数据；数据导入预计算	预聚合导致的明细查询差；无多表操作；不支持单数据的修改
Cellar	超大数据量，内存+分布式存储；吞吐性能好	仅支持KV、Map、List；KV的值大小限制

计算框架

项目	Flink	Spark Streaming
API	Table API和Flink SQL	流API和Spark SQL
容错机制	State快照保存，检查点	RDD保存点
状态管理	键控状态，operator状态	有UpdateStateByKey等API
处理模式	单条流式处理	批处理
延迟	毫秒级	秒级
语义保障	Exactly Once，At Least Once	At Least Once

基本层级处理

• 数据源 → 数仓 → 数据应用

数据抽取→ODS（Kafka）→Flink → DWD（Kafka） → Flink → DWS（多维明细宽表）（Kafka）→ ADS（Kafka）→ Druid/ES

DIM（Mysql/Hive/Tair）

层级	数据&框架
ODS	实时数据：Kafka
DWD	事实明细数据：Kafka
DWS	明细多维汇总：Kafka
ADS	应用数据：ES、Druid、Mysql、Tair

数仓基石

• 主题划分，实时数仓与离线数仓主题划分逻辑不变，处理逻辑按照ADS需要，按照Kafka主题划分，线性缩减处理。

应用

• BI报表（ES）

• 用户标签（Mysql / Kylin），实时特征服务

• 服务接口（Redis / HBase）

• 实时推荐服务

• 实时OLAP

• 实时数据队列

优势

1. 标签体系实时化管理
2. 调度任务压力摊平
3. 数据质量分散保证
4. 实时应用

架构分析

• 介绍
  • 实时数仓以Kappa为主，离线数仓就是传统大数据框架，Lambda就是二者的一个中间形态。

Lambda

Kappa

优化

处理框架

冗余消费优化

1. 场景优化，根据具体业务逻辑以及计算逻辑做好数仓主题划分以及topic划分。
2. 排除重复消费，同一批数据做到消费一次，重复利用。

数据安全保证

1. 数据一致性问题，就是实时EOS。
2. 上下游对接不同层级Kafka，具体操作
   • 内部checkpoint，状态容错保证错误重启并且恢复
   • 上游offset，避免黑匣子，重设数据读取。自定义：查询，检验，覆盖（新增）
   • 下游幂等&acks，多事务幂等性以及根据需求场景的acks参数调整。

数据积压问题

• 从存储和处理两个方面解决，考虑峰值情况。

链路监控

• 包含数据抽取，数据层级落地，层级处理，数据导入以及展现。
• 两个核心层面。
  1. Kafka：多个Kafka处理过程log集中整合。
  2. Flink：内部监控应用开发。

框架本身处理的优化

问题

实时热点问题

介绍

• 实时与离线在于环境中的不同点

  实时保证7*24h，任务不能停止，那么需要在上线前做好测试优化工作以及应对实时变动的方案。

• 实时倾斜与离线倾斜在于环境中的不同点

  倾斜的数据级别不同，离线必然更加严重，但是实时时效性要求更高，所以更影响结果。

实施

聚合操作

• 提高并行度，聚合分组散列
• 不用window，使用外部存储做处理
• 使用不同分区方式
• 具体代码逻辑与离线可接近