共计 5568 个字符，预计需要花费 14 分钟才能阅读完成。
随着互联网飞速发展，企业业务品种会越来越多，业务数据量会越来越大，当倒退到肯定规模时，传统的数据存储构造逐步无奈满足企业需要，实时数据仓库就变成了一个必要的根底服务。以维表 Join 为例，数据在业务数据源中以范式表的模式存储，在剖析时须要做大量的 Join 操作，升高性能。如果在数据荡涤导入过程中就能流式的实现 Join，那么剖析时就无需再次 Join，从而晋升查问性能。
利用实时数仓，企业能够实现实时 OLAP 剖析、实时数据看板、实时业务监控、实时数据接口服务等用处。但想到实时数仓，很多人的第一印象就是架构简单，难以操作与保护。而得益于新版 Flink 对 SQL 的反对，以及 TiDB HTAP 的个性，咱们摸索了一个高效、易用的 Flink+TiDB 实时数仓解决方案。
本文将首先介绍实时数仓的概念，而后介绍 Flink+TiDB 实时数仓的架构与劣势，接着给出一些曾经在应用中的用户场景，最初给出在 docker-compose 环境下的 Demo，用于读者进行尝试。
实时数仓的概念
数据仓库的概念在 90 年代由 Bill Inmon 提出，是指一个面向主题的、集成的、绝对稳固的、反映历史变动的汇合，用于反对管理决策。过后的数据仓库通过音讯队列收集来自数据源的数据，通过每天或每周进行一次计算以供报表应用，也称为离线数仓。
进入 21 世纪，随着计算技术的倒退、以及整体算力的晋升，决策的主体逐步从人工控制转变为计算机算法，呈现了实时举荐、实时监控剖析等需要，对应的决策周期时间由天级逐渐变为秒级，在这些场景下，实时数仓应运而生。
以后的实时数仓次要有三种架构：Lambda 架构、Kappa 架构以及实时 OLAP 变体架构：
- Lambda 架构是指在离线数仓的根底上叠加了实时数仓局部，应用流式引擎解决实时性较高的数据，最初将离线和在线的后果对立供给用应用。
- Kappa 架构则移除了离线数仓局部，全副应用实时数据生产。这种架构对立了计算引擎，升高了开发成本。
- 随着实时 OLAP 技术的晋升，一个新的实时架构被提出，临时被称为“实时 OLAP 变体”。简略来说，就是将一部分计算压力从流式计算引擎转嫁到实时 OLAP 剖析引擎上，以此进行更加灵便的实时数仓计算。
总结一下，对于实时数仓，Lambda 架构须要保护流批两套引擎，开发成本相较其它两者更高。相比于 Kappa 架构，实时 OLAP 变体架构能够执行更加灵便的计算，但须要依赖额定的实时 OLAP 算力资源。接下来咱们将介绍的 Flink + TiDB 实时数仓计划，就属于实时 OLAP 变体架构。
对于实时数仓及这些架构更加具体的比照阐明，有趣味的读者能够参考 Flink 中文社区的这篇文章：基于 Flink 的典型 ETL 场景实现计划。
Flink+ TiDB 实时数仓
Flink 是一个低提早、高吞吐、流批对立的大数据计算引擎，被广泛用于高实时性场景下的实时计算，具备反对 exactly-once 等重要个性。
在集成了 TiFlash 之后，TiDB 曾经成为了真正的 HTAP（在线事务处理 OLTP + 在线剖析解决 OLAP）数据库。换句话说，在实时数仓架构中，TiDB 既能够作为数据源的业务数据库，进行业务查问的解决；又能够作为实时 OLAP 引擎，进行剖析型场景的计算。
联合了 Flink 与 TiDB 两者的个性，Flink+ TiDB 的计划的劣势也体现了进去：首先是速度有保障，两者都能够通过程度扩大节点来减少算力；其次，学习和配置老本绝对较低，因为 TiDB 兼容 MySQL 5.7 协定，而最新版本的 Flink 也能够齐全通过 Flink SQL 和弱小的连接器（connector）来编写提交工作，节俭了用户的学习老本。
对于 Flink + TiDB 实时数仓，上面是几种罕用的搭建原型，能够用来满足不同的需要，也能够在理论应用中自行扩大。
以 MySQL 作为数据源
通过应用 Ververica 官网提供的 flink-connector-mysql-cdc[1]，Flink 能够既作为采集层采集 MySQL 的 binlog 生成动静表，也作为流计算层实现流式计算，如流式 Join、预聚合等。最初，Flink 通过 JDBC 连接器将计算实现的数据写入 TiDB 中。
这个架构的长处是十分简洁不便，在 MySQL 和 TiDB 都筹备好对应数据库和表的状况下，能够通过只编写 Flink SQL 来实现工作的注册与提交。读者能够在本文开端的【在 docker-compose 中进行尝试】一节中尝试此架构。
以 Kafka 对接 Flink
如果数据曾经从其它路径寄存到了 Kafka 中，能够不便地通过 Flink Kafka Connector[2] 使 Flink 从 Kafka 中取得数据。
在这里须要提一下的是，如果想要将 MySQL 或其它数据源的变更日志寄存在 Kafka 中后续供 Flink 解决，那么举荐应用 Canal 或 Debezium 采集数据源变更日志，因为 Flink 1.11 原生反对解析这两种工具格局的 changelog，无需再额定实现解析器。
以 TiDB 作为数据源
TiCDC[3] 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，能够利用其将 TiDB 的变更数据输入到音讯队列中，再由 Flink 提取。
在 4.0.7 版本，能够通过 TiCDC Open Protocol[4] 来实现与 Flink 的对接。在之后的版本，TiCDC 将反对间接输入为 canal-json 模式，以供 Flink 应用。
案例与实际
上个局部介绍了一些根底的架构，实际中的摸索往往更加简单和乏味，这一部分将介绍一些具备代表性和启发性的用户案例。
小红书
小红书是年轻人的生存形式平台，用户能够通过短视频、图文等模式记录生存点滴，分享生存形式，并基于趣味造成互动。截至到 2019 年 10 月，小红书月沉闷用户数曾经过亿，并继续快速增长。
在小红书的业务架构中，Flink 的数据起源和数据汇总处都是 TiDB，以达到相似于“物化视图”的成果：
- 左上角的线上业务表执行失常的 OLTP 工作。
- 下方的 TiCDC 集群抽取 TiDB 的实时变更数据，以 changelog 模式传递到 Kafka 中。
- Flink 读取 Kafka 中的 changelog，进行计算，如拼好宽表或聚合表。
- Flink 将后果写回到 TiDB 的宽表中，用于后续剖析应用。
整个过程造成了 TiDB 的闭环，将后续剖析工作的 Join 工作转移到了 Flink 上，并通过流式计算来缓解压力。目前这套计划曾经反对起了小红书的内容审核、笔记标签举荐、增长审计等业务，经验了大吞吐量的线上业务考验且继续运行稳固。
贝壳金服
贝壳金服继续多年深耕寓居场景，积攒了丰盛的中国房产大数据。贝壳金服以金融科技为驱动，利用 AI 算法高效利用多维海量数据以晋升产品体验，为用户提供丰盛、定制化的金融服务。
在贝壳数据组的数据服务中，Flink 实时计算用于典型的维表 Join：
- 首先，应用 Syncer（MySQL 到 TiDB 的一个轻量级同步工具）采集业务数据源上的维表数据同步到 TiDB 中。
- 而后，业务数据源上的流表数据则通过 Canal 采集 binlog 存入 kafka 音讯队列中。
- Flink 读取 Kafka 中流表的变更日志，尝试进行流式 Join，每当须要维表中的数据时，就去 TiDB 中查找。
- 最初，Flink 将拼合而成的宽表写入到 TiDB 中，用于数据分析服务。
利用以上的构造，能够将数据服务中的主表进行实时 Join 落地，而后服务方只须要查问单表。这套零碎在贝壳金服曾经深刻各个外围业务零碎，跨零碎的数据获取对立走数据组的数据服务，省去了业务零碎开发 API 和内存聚合数据代码的开发工作。
智慧芽
PatSnap（智慧芽）是一款寰球专利检索数据库，整合了 1790 年至今的寰球 116 个国家地区 1.3 亿专利数据和 1.7 亿化学构造数据。可检索、浏览、翻译专利，生成 Insights 专利剖析报告，用于专利价值剖析、援用剖析、法律搜寻，查看 3D 专利地图。
智慧芽应用 Flink + TiDB 替换了原有的 Segment + Redshift 架构。
原有的 Segment + Redshift 架构，仅构建出了 ODS 层，数据写入的规定和 schema 不受管制。且须要针对 ODS 编写简单的 ETL 来依照业务需要进行各类指标的计算来实现下层需要。Redshift 中落库数据量大，计算慢（T+1 时效），并影响对外服务性能。
替换为基于 Kinesis +Flink + TiDB 构建的实时数仓架构后，不再须要构建 ODS 层。Flink 作为前置计算单元，间接从业务登程构建出 Flink Job ETL，齐全管制了落库规定并自定义 schema；即仅把业务关注的指标进行荡涤并写入 TiDB 来进行后续的剖析查问，写入数据量大大减少。按用户 / 租户、地区、业务动作等关注的指标，联合分钟、小时、天等不同粒度的工夫窗口等，在 TiDB 上构建出 DWD/DWS/ADS 层，间接服务业务上的统计、清单等需要，下层利用可间接应用构建好的数据，且取得了秒级的实时能力。
用户体验：在应用了新架构后，入库数据量、入库规定和计算复杂度都大大降落，数据在 Flink Job 中曾经依照业务需要解决实现并写入 TiDB，不再须要基于 Redshift 的 全量 ODS 层进行 T+1 ETL。基于 TiDB 构建的实时数仓，通过正当的数据分层，架构上取得了极大的精简，开发保护也变得更加简略；在数据查问、更新、写入性能上都取得大幅度晋升；在满足不同的 adhoc 剖析需要时，不再须要期待相似 Redshift 预编译的过程；扩容不便简略易于开发。
目前这套架构正在上线，在智慧芽外部用来进行用户行为剖析和追踪，并汇总出公司经营大盘、用户行为剖析、租户行为剖析等性能。
网易互娱
网易 2001 年正式成立在线游戏事业部，通过近 20 年的倒退，已跻身寰球七大游戏公司之一。在 App Annie 公布的“2020 年度寰球发行商 52 强”榜单中，网易位列第二。
在网易互娱计费组的利用架构中，一方面应用 Flink 实现业务数据源到 TiDB 的实时写入；另一方面，以 TiDB 作为剖析数据源，在后续的 Flink 集群中进行实时流计算，生成剖析报表。此外，网易互娱当初外部开发了 Flink 作业管理平台，用于治理作业的整个生命周期。
知乎
知乎是中文互联网综合性内容平台，以“让每个人高效取得可信赖的解答”为品牌使命和北极星。截至 2019 年 1 月，知乎已领有超过 2.2 亿用户，共产出 1.3 亿个答复。
知乎作为 PingCAP 的合作伙伴，同时也是 Flink 的深度用户，在本人的实际过程中开发了一套 TiDB 与 Flink 交互工具并奉献给了开源社区：pingcap-incubator/TiBigData[5]，次要包含了如下性能：
- TiDB 作为 Flink Source Connector，用于批式同步数据。
- TiDB 作为 Flink Sink Connector，基于 JDBC 实现。
- Flink TiDB Catalog，能够在 Flink SQL 中间接应用 TiDB 的表，无需再次创立。
在 docker-compose 中进行尝试
为了不便读者更好的了解，咱们在 https://github.com/LittleFall… 中提供了一个基于 docker-compose 的 MySQL-Flink-TiDB 测试环境，供大家测试应用。
Flink TiDB 实时数仓 Slides[6] 中提供了该场景下一个简略的教程，包含概念解释、代码示例、简略原理以及一些注意事项，其中示例包含：
- Flink SQL 简略尝试
- 利用 Flink 进行从 MySQL 到 TiDB 的数据导入
- 双流 Join
- 维表 Join
在启动 docker-compose 后，能够通过 Flink SQL Client 来编写并提交 Flink 工作，并通过 localhost:8081 来察看工作执行状况。
如果大家对 Flink+TiDB 实时数仓计划有趣味、纳闷，或者在摸索实际过程中积攒了想要分享的教训，欢送到 TiDB 社区（如 AskTUG[7]）、Flink 社区（如 Flink 中文邮件 [8]）或通过我的邮件（qizhi@pingcap.com）进行探讨。
参考浏览
Flink 中文社区对于实时数仓概念及流上 Join 的探讨：
基于 Flink 的典型 ETL 场景实现计划 https://mp.weixin.qq.com/s/l-…
小红书应用 TiDB 的实际分享文章：
How We Use a Scale-Out HTAP Database for Real-TimeAnalytics and Complex Querieshttps://en.pingcap.com/case-s…
TiDB 的 HTAP 架构以及在数据平台上的利用：
How We Build an HTAP Database That Simplifies Your DataPlatformhttps://dzone.com/articles/ho…
TiDB 原理论文：
TiDB:A Raft-based HTAP Databasehttp://www.vldb.org/pvldb/vol…
Flink 中文社区，对于 Flink SQL CDC 的运维生产教训：
FlinkSQL CDC 上线！咱们总结了 13 条生产实践经验 https://zhuanlan.zhihu.com/p/…
参考链接：
[1]https://github.com/ververica/…
[2]https://ci.apache.org/project…
[3]https://docs.pingcap.com/zh/t…
[4]https://docs.pingcap.com/zh/t…
[5]https://github.com/pingcap-in…
[6]https://docs.google.com/prese…
[7]https://asktug.com
[8]http://apache-flink.147419.n8…