建设实时数仓之前的思考与方案
导读：本文由作者LittleMagic总结分享授权发布，主要阐述建设实时数仓之前的思考与方案记录。详细分为以下几个方面：
动机背景
指导思想
技术选型
架构分层
元数据管理
SQL作业管理
数据质量
作者：LittleMagic
编辑： 紫霞仙子
前言
随着这次新冠疫情带来的机遇，业务数据规模飞速增长，实时数仓的建设已经提上了日程。虽然还没有正式开始实施，但是汲取前人的经验，做好万全的准备总是必要的。
本文简单地记录一下建设实时数仓之前的一些思考和方案想法，不涉及维度建模方法论的事情。如果有兴趣请移步：系列 | 漫谈数仓第二篇NO.2 数据模型（维度建模）
一、动机背景
随着业务快速增长，时效性越显重要，传统离线数仓的不足暴露出来：
运维层面——所有调度任务只能在业务闲时（凌晨）集中启动，集群压力大，耗时越来越长；
业务层面——数据按T+1更新，延迟高，数据时效价值打折扣，无法精细化运营与及时感知异常。
实时数仓即离线数仓的时效性改进方案，从原本的小时/天级别做到秒/分钟级别。底层设计变动的同时，需要尽力保证平滑迁移，不影响用户（分析人员）之前的使用习惯。
实时数仓的建设应早日提上日程，未来企业对数据时效性的要求会越来越高（如实时大屏、实时监控、实时风控等），实时数仓会很好的解决该问题。
二、指导思想：Kappa架构
一图流，可品
参考大数据数据仓库架构演进：
关于数仓架构，可回顾我们之前分享的文章，更多请移步：系列 | 漫谈数仓第一篇NO.1『基础架构』
三、计算/存储技术选型
硬性要求：
批流一体化——能同时进行实时和离线的操作；
提供统一易用的SQL interface——方便开发人员和分析人员。
可选项：Spark、Flink
较优解：Flink
优点：
严格按照Google Dataflow模型实现；
在事件时间、窗口、状态、exactly-once等方面更有优势；
非微批次处理，真正的实时流处理；
多层API，对table/SQL支持良好，支持UDF、流式join等高级用法。
缺点：
生态系统没有Spark强大（不太重要）；
1.10版本相比1.9版本的改动较多，需要仔细研究。
硬性要求：
1. 数据in-flight——不能中途落地，处理完之后直接给到下游，最小化延迟；
2. 可靠存储——有一定持久化能力，高可用，支持数据重放。
可选项：各种消息队列组件（Kafka、RabbitMQ、RocketMQ、Pulsar、...）
较优解：Kafka
1. 吞吐量很大；
2. 与Flink、Canal等外部系统的对接方案非常成熟，容易操作；
3. 团队使用经验丰富。
硬性要求：
支持较大规模的查询（主要是与事实数据join的查询）；
能够快速实时更新。
可选项：RDBMS（MySQL等）、NoSQL（HBase、Redis、Cassandra等）
较优解：HBase
优点：
实时写入性能高，且支持基于时间戳的多版本机制；
接入业务库MySQL binlog简单；
可以通过集成Phoenix获得SQL能力。
根据不同的需求，按照业务特点选择不同的方案。
当前已大规模应用，可随时利用的组件：
Greenplum——业务历史明细、BI支持、大宽表MOLAP
Redis——大列表业务结果（PV/UV、标签、推荐结果、Top-N等）
HBase——高并发汇总指标（用户画像）
MySQL——普通汇总指标、汇总模型等
当前未有或未大规模应用的组件：
ElasticSearch（ELK）——日志明细，也可以用作OLAP
Druid——OLAP
InfluxDB/OpenTSDB——时序数据
四、实时数仓分层架构
参照离线数仓分层，尽量扁平，减少数据中途的lag。
五、元数据管理
Kafka本身没有Hive/GP等传统数仓组件的metastore，必须自己维护数据schema。
（Flink 1.10开始正式在Table API中支持Catalog，用于外部元数据对接。）
外部存储（e.g. MySQL） + Flink ExternalCatalog
Hive metastore + Flink HiveCatalog（与上一种方案本质相同，但是借用Hive的表描述与元数据体系）
Confluent Schema Registry (CSR) + Kafka Avro Serializer/Deserializer
CSR是开源的元数据注册中心，能与Kafka无缝集成，支持RESTful风格管理。producer和consumer通过Avro序列化/反序列化来利用元数据。
六、SQL作业管理
实时数仓平台展现给分析人员的开发界面应该是类似Hue的交互式查询UI，即用户写标准SQL，在平台上提交作业并返回结果，底层是透明的。
但仅靠Flink SQL无法实现，需要我们自行填补这个gap。
AthenaX（由Uber开源）
该项目比较老旧，是基于Flink 1.5构建的，预计需要花比较多的时间精力来搞二次开发。
用户提交SQL → 通过Catalog获取元数据 → 解释、校验、优化SQL → 编译为Flink Table/SQL job → 部署到YARN集群并运行 → 输出结果
重点仍然是元数据问题：如何将AthenaX的Catalog与Flink的Catalog打通？
需要将外部元数据的对应到Flink的TableDescriptor（包含connector、format、schema三类参数），进而映射到相应的TableFactory并注册表。
另外还需要控制SQL作业对YARN资源的占用，考虑用YARN队列实现，视情况调整调度策略。
七、数据质量
使用Flink Metrics，主要考虑两点：
算子数据吞吐量（numRecordsInPerSecond/numRecordsOutPerSecond）
Kafka链路延迟（records-lag-max）→ 如果搞全链路延迟，需要做数据血缘分析
其他方面待定（术业有专攻，可专业搞监控系统的同学支持）
手动对数——旁路写明细表，定期与数据源交叉验证
自动监控——数据指标波动告警，基线告警，表级告警 etc.
进群方式：请加微信（微信号：dataclub_bigdata），回复：数据，通过审核会拉你进群。
(备注：行业-职位-城市)
01. 后台回复「数据」,即可领取大数据经典资料。
02. 后台回复「转型」,即可传统数据仓库转型大数据必学资料。
03. 后台回复「加群」,或添加一哥微信ID：dataclub_bigdata 拉您入群（大数据|数仓|分析）或领取资料。
Q: 关于大数据，你还想了解什么？
欢迎大家扫描下方二维码订阅「数据社」内容并推荐给更多数据方向的朋友，希望有更多机会和大家交流。
！关注不迷路~ 各种福利、资源定期分享！
本文分享自微信公众号 - 数据社（DataClub）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
