当 TiDB 与 Flink 相结合：高效、易用的实时数仓

时间  2020-11-19 标签 mysql 算法 sql docker 数据库 json 架构 app ide 工具

随着互联网飞速发展，企业业务种类会愈来愈多，业务数据量会愈来愈大，当发展到必定规模时，传统的数据存储结构逐渐没法知足企业需求，实时数据仓库就变成了一个必要的基础服务。以维表 Join 为例，数据在业务数据源中以范式表的形式存储，在分析时须要作大量的 Join 操做，下降性能。若是在数据清洗导入过程当中就能流式的完成 Join，那么分析时就无需再次 Join，从而提高查询性能。mysql

利用实时数仓，企业能够实现实时 OLAP 分析、实时数据看板、实时业务监控、实时数据接口服务等用途。但想到实时数仓，不少人的第一印象就是架构复杂，难以操做与维护。而得益于新版 Flink 对 SQL 的支持，以及 TiDB HTAP 的特性，咱们探索了一个高效、易用的 Flink+TiDB 实时数仓解决方案。算法

本文将首先介绍实时数仓的概念，而后介绍 Flink+TiDB 实时数仓的架构与优点，接着给出一些已经在使用中的用户场景，最后给出在 docker-compose 环境下的 Demo，用于读者进行尝试。sql

实时数仓的概念

数据仓库的概念在 90 年代由 Bill Inmon 提出，是指一个面向主题的、集成的、相对稳定的、反映历史变化的集合，用于支持管理决策。当时的数据仓库经过消息队列收集来自数据源的数据，经过天天或每周进行一次计算以供报表使用，也称为离线数仓。docker

离线数仓架构数据库

进入 21 世纪，随着计算技术的发展、以及总体算力的提高，决策的主体逐渐从人工控制转变为计算机算法，出现了实时推荐、实时监控分析等需求，对应的决策周期时间由天级逐步变为秒级，在这些场景下，实时数仓应运而生。json

当前的实时数仓主要有三种架构：Lambda架构、Kappa 架构以及实时 OLAP 变体架构：架构

  • Lambda 架构是指在离线数仓的基础上叠加了实时数仓部分，使用流式引擎处理实时性较高的数据，最后将离线和在线的结果统一供应用使用。

实时数仓的 Lambda 架构app

  • Kappa 架构则移除了离线数仓部分，所有使用实时数据生产。这种架构统一了计算引擎，下降了开发成本。

实时数仓的 Kappa 架构ide

  • 随着实时 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，Flink 能够既做为采集层采集 MySQL 的 binlog 生成动态表，也做为流计算层实现流式计算，如流式 Join、预聚合等。最后，Flink 经过 JDBC 链接器将计算完成的数据写入 TiDB 中。

以 MySQL 做为数据源的简便架构

这个架构的优势是很是简洁方便，在 MySQL 和 TiDB 都准备好对应数据库和表的状况下，能够经过只编写 Flink SQL 来完成任务的注册与提交。读者能够在本文末尾的【在docker-compose 中进行尝试】一节中尝试此架构。

以 Kafka 对接 Flink

若是数据已经从其它途径存放到了Kafka 中，能够方便地经过 Flink Kafka Connector 使 Flink 从 Kafka 中得到数据。

在这里须要提一下的是，若是想要将 MySQL 或其它数据源的变动日志存放在 Kafka 中后续供 Flink 处理，那么推荐使用 Canal 或 Debezium 采集数据源变动日志，由于 Flink 1.11 原生支持解析这两种工具格式的 changelog，无需再额外实现解析器。

以 MySQL 做为数据源，通过 Kafka 的架构示例

以 TiDB 做为数据源

TiCDC 是一款经过拉取 TiKV 变动日志实现的 TiDB 增量数据同步工具，能够利用其将 TiDB 的变动数据输出到消息队列中，再由 Flink 提取。

以 TiDB 做为数据源，经过 TiCDC 将 TiDB 的增量变化输出到 Flink 中

在 4.0.7 版本，能够经过 TiCDC Open Protocol来完成与 Flink 的对接。在以后的版本，TiCDC 将支持直接输出为 canal-json 形式，以供 Flink 使用。

案例与实践

上个部分介绍了一些基础的架构，实践中的探索每每更加复杂和有趣，这一部分将介绍一些具备表明性和启发性的用户案例。

小红书

小红书是年轻人的生活方式平台，用户能够经过短视频、图文等形式记录生活点滴，分享生活方式，并基于兴趣造成互动。截至到 2019 年 10 月，小红书月活跃用户数已通过亿，并持续快速增加。

在小红书的业务架构中，Flink 的数据来源和数据汇总处都是 TiDB，以达到相似于“物化视图”的效果：

  1. 左上角的线上业务表执行正常的 OLTP 任务。
  2. 下方的 TiCDC 集群抽取 TiDB 的实时变动数据，以 changelog 形式传递到 Kafka 中。
  3. Flink 读取 Kafka 中的 changelog，进行计算，如拼好宽表或聚合表。
  4. Flink 将结果写回到 TiDB 的宽表中，用于后续分析使用。

小红书 Flink TiDB 集群架构

整个过程造成了 TiDB 的闭环，将后续分析任务的 Join 工做转移到了 Flink 上，并经过流式计算来缓解压力。目前这套方案已经支持起了小红书的内容审核、笔记标签推荐、增加审计等业务，经历了大吞吐量的线上业务考验且持续运行稳定。

贝壳金服

贝壳金服持续多年深耕居住场景，积累了丰富的中国房产大数据。贝壳金服以金融科技为驱动，利用 AI 算法高效应用多维海量数据以提高产品体验，为用户提供丰富、定制化的金融服务。

在贝壳数据组的数据服务中，Flink 实时计算用于典型的维表 Join：

  1. 首先，使用 Syncer （MySQL 到 TiDB 的一个轻量级同步工具）采集业务数据源上的维表数据同步到 TiDB 中。
  2. 而后，业务数据源上的流表数据则经过 Canal 采集 binlog 存入 kafka 消息队列中。
  3. Flink 读取 Kafka 中流表的变动日志，尝试进行流式 Join，每当须要维表中的数据时，就去 TiDB 中查找。
  4. 最后，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，主要包括了以下功能：

  1. TiDB 做为 Flink Source Connector，用于批式同步数据。
  2. TiDB 做为 Flink Sink Connector，基于 JDBC 实现。
  3. Flink TiDB Catalog，能够在 Flink SQL 中直接使用 TiDB 的表，无需再次建立。

Flink TiDB 实时数仓 Slides 中提供了该场景下一个简单的教程，包括概念解释、代码示例、简单原理以及一些注意事项，其中示例包括：

  1. Flink SQL 简单尝试
  2. 利用 Flink 进行从 MySQL 到 TiDB 的数据导入
  3. 双流 Join
  4. 维表 Join

在启动 docker-compose 后，能够经过 Flink SQL Client 来编写并提交 Flink 任务，并经过 localhost:8081 来观察任务执行状况。

做者：齐智@TiDB

 

原文连接

本文为阿里云原创内容，未经容许不得转载。

联系我们 沪ICP备13005482号-10