建设实时数仓以前的思考与方案

 

 

导读：本文由做者LittleMagic总结分享受权发布，主要阐述建设实时数仓以前的思考与方案记录。详细分为如下几个方面：

1. 动机背景

2. 指导思想

3. 技术选型

4. 架构分层

5. 元数据管理

6. SQL做业管理

7. 数据质量

 

。

做者：LittleMagic

 

 

正文

前言

随着此次新冠疫情带来的机遇，业务数据规模飞速增加，实时数仓的建设已经提上了日程。虽然尚未正式开始实施，可是汲取前人的经验，作好万全的准备老是必要的。

本文简单地记录一下建设实时数仓以前的一些思考和方案想法，不涉及维度建模方法论的事情。若是有兴趣请移步：系列 | 漫谈数仓第二篇NO.2 数据模型（维度建模）

1、动机背景

 

随着业务快速增加，时效性越显重要，传统离线数仓的不足暴露出来：

 

• 运维层面——全部调度任务只能在业务闲时（凌晨）集中启动，集群压力大，耗时愈来愈长；

• 业务层面——数据按T+1更新，延迟高，数据时效价值打折扣，没法精细化运营与及时感知异常。

 

实时数仓即离线数仓的时效性改进方案，从本来的小时/天级别作到秒/分钟级别。底层设计变更的同时，须要尽力保证平滑迁移，不影响用户（分析人员）以前的使用习惯。

 

实时数仓的建设应早日提上日程，将来企业对数据时效性的要求会愈来愈高（如实时大屏、实时监控、实时风控等），实时数仓会很好的解决该问题。

 

2、指导思想：Kappa架构

一图流，可品

参考大数据数据仓库架构演进：

关于数仓架构，可回顾咱们以前分享的文章，更多请移步：系列 | 漫谈数仓第一篇NO.1『基础架构』

 

3、计算/存储技术选型

 

3.1 计算引擎  

 

硬性要求：

1. 批流一体化——能同时进行实时和离线的操做；

2. 提供统一易用的SQL interface——方便开发人员和分析人员。

可选项：Spark、Flink

较优解：Flink

• 优势：

1. 严格按照Google Dataflow模型实现；

2. 在事件时间、窗口、状态、exactly-once等方面更有优点；

3. 非微批次处理，真正的实时流处理；

4. 多层API，对table/SQL支持良好，支持UDF、流式join等高级用法。

• 缺点：

1. 生态系统没有Spark强大（不过重要）；

2. 1.10版本相比1.9版本的改动较多，须要仔细研究。

 

3.2 底层（事实数据）| 存储引擎  

 

• 硬性要求：

        1. 数据in-flight——不能中途落地，处理完以后直接给到下游，最小化延迟；

        2. 可靠存储——有必定持久化能力，高可用，支持数据重放。

• 可选项：各类消息队列组件（Kafka、RabbitMQ、RocketMQ、Pulsar、...）

• 较优解：Kafka

  1. 吞吐量很大；

  2. 与Flink、Canal等外部系统的对接方案很是成熟，容易操做；

  3. 团队使用经验丰富。

 

3.3 中间层（维度数据）| 存储引擎  

 

• 硬性要求：

1. 支持较大规模的查询（主要是与事实数据join的查询）；

2. 可以快速实时更新。

• 可选项：RDBMS（MySQL等）、NoSQL（HBase、Redis、Cassandra等）

• 较优解：HBase

• 优势：

1. 实时写入性能高，且支持基于时间戳的多版本机制；

2. 接入业务库MySQL binlog简单；

3. 能够经过集成Phoenix得到SQL能力。

 

3.4 高层（明细/汇总数据）| 存储/查询引擎  

 

根据不一样的需求，按照业务特色选择不一样的方案。

当前已大规模应用，可随时利用的组件：

• Greenplum——业务历史明细、BI支持、大宽表MOLAP

• Redis——大列表业务结果（PV/UV、标签、推荐结果、Top-N等）

• HBase——高并发汇总指标（用户画像）

• MySQL——普通汇总指标、汇总模型等

当前未有或未大规模应用的组件：

• ElasticSearch（ELK）——日志明细，也能够用做OLAP

• Druid——OLAP

• InfluxDB/OpenTSDB——时序数据

 

4、实时数仓分层架构

 

参照离线数仓分层，尽可能扁平，减小数据中途的lag。

 

image1

image2

5、元数据管理

 

5.1 必要性  

 

Kafka自己没有Hive/GP等传统数仓组件的metastore，必须本身维护数据schema。
（Flink 1.10开始正式在Table API中支持Catalog，用于外部元数据对接。）

 

 

5.2 可行方案  

 

1. 外部存储（e.g. MySQL） + Flink ExternalCatalog

2. Hive metastore + Flink HiveCatalog（与上一种方案本质相同，可是借用Hive的表描述与元数据体系）

3. Confluent Schema Registry (CSR) + Kafka Avro Serializer/Deserializer

CSR是开源的元数据注册中心，能与Kafka无缝集成，支持RESTful风格管理。producer和consumer经过Avro序列化/反序列化来利用元数据。

 

6、SQL做业管理

 

6.1 必要性  

 

实时数仓平台展示给分析人员的开发界面应该是相似Hue的交互式查询UI，即用户写标准SQL，在平台上提交做业并返回结果，底层是透明的。
但仅靠Flink SQL没法实现，须要咱们自行填补这个gap。

 

6.2 可行方案

 

AthenaX（由Uber开源）

该项目比较老旧，是基于Flink 1.5构建的，预计须要花比较多的时间精力来搞二次开发。

 

6.3 流程  

 

用户提交SQL → 经过Catalog获取元数据 → 解释、校验、优化SQL → 编译为Flink Table/SQL job → 部署到YARN集群并运行 → 输出结果

 

重点仍然是元数据问题：如何将AthenaX的Catalog与Flink的Catalog打通？

 

须要将外部元数据的对应到Flink的TableDescriptor（包含connector、format、schema三类参数），进而映射到相应的TableFactory并注册表。

另外还须要控制SQL做业对YARN资源的占用，考虑用YARN队列实现，视状况调整调度策略。

7、数据质量

 

7.1 性能监控  

 

使用Flink Metrics，主要考虑两点：

• 算子数据吞吐量（numRecordsInPerSecond/numRecordsOutPerSecond）

• Kafka链路延迟（records-lag-max）→ 若是搞全链路延迟，须要作数据血缘分析

其余方面待定（术业有专攻，可专业搞监控系统的同窗支持）

 

7.2 数据质量  

 

• 手动对数——旁路写明细表，按期与数据源交叉验证

• 自动监控——数据指标波动告警，基线告警，表级告警 etc.

 

 

历史好文推荐

1. 从0到1搭建大数据平台之计算存储系统

2. 从0到1搭建大数据平台之调度系统

3. 从0到1搭建大数据平台之数据采集系统

4. 如何从0到1搭建大数据平台

5. 从0到1搭建自助分析平台

 

 

福利时刻

01. 后台回复「数据」,便可领取大数据经典资料。

02. 后台回复「转型」,便可传统数据仓库转型大数据必学资料。

03. 后台回复「加群」,或添加一哥微信ID：dataclub_bigdata  拉您入群（大数据|数仓|分析）或领取资料。

Q: 关于大数据，你还想了解什么？

 

欢迎你们扫描下方二维码订阅「数据社」内容并推荐给更多数据方向的朋友，但愿有更多机会和你们交流。