如何为二级分析扩展实时数据仓库

当一家数据驱动型公司发展到一定规模时，传统的数据存储已不能满足其需求。对于实时商业智能，您需要一个实时数据仓库。公司可以使用实时数据仓库来实施实时在线分析处理(OLAP)分析、实时数据面板、实时应用程序监控和实时数据接口服务。

有些人认为实时数据仓库架构很复杂，很难操作和维护。今天，我将解释为什么这不是真的。Apache Flink是一个框架和分布式处理引擎，用于在无界和有界数据流上进行有状态计算。TiDB是一个开源、分布式、混合事务/分析处理(HTAP)数据库。由于Flink 1.11；增强了对SQL语言的支持和TiDB的HTAP功能，我们将Flink和TiDB结合在一起，构建了一个高效、易用、实时的数据仓库，具有横向可伸缩性和高可用性。

在这篇文章中，我将描述什么是实时数据仓库，Flink+TiDB实时数据仓库的架构和优势，这个解决方案的实际案例研究，以及一个使用Docker Compose的测试环境。

在20世纪90年代，Bill Inmon将数据仓库定义为支持管理决策的面向主题、集成、时变和非易失性的数据集合。数据仓库通过消息队列收集数据，并每天或每周计算一次以创建报告。它也被称为离线数据仓库。

随着技术的进步，人们对实时推荐、实时监控分析等提出了新的要求。相应的决策期逐渐从几天变成了几秒。为了满足这些需求，实时数据仓库应运而生。

实时数据仓库有三种主要的数据处理架构：Lambda架构、Kappa架构和实时OLAP变体架构。

Lambda架构维护批处理层和流层，因此它的开发成本高于其他两个层。与Kappa架构相比，实时OLAP变体架构可以执行更灵活的计算，但需要更多的实时OLAP计算资源。

Lambda架构有实时数据仓库和离线数据仓库，流处理引擎直接计算实时性要求高的数据。Lambda架构聚合了应用程序的离线和在线结果。

Kappa架构消除了离线数据仓库层，只使用实时数据仓库。它统一了计算引擎，降低了开发成本。

实时OLAP变体架构将部分计算压力从流处理引擎转移到实时OLAP分析引擎。结果是更加灵活、实时的数据仓库计算。

接下来，我们将介绍一个实时OLAP变体体系结构的示例，即用于实时数据仓库的Flink+TiDB解决方案。

Flink是一个低延迟、高吞吐量、统一流和批处理的大数据计算引擎。它被广泛应用于对实时计算要求很高的场景中，并提供只有一次的语义。

TiDB 4.0是一个真正的HTAP数据库。在实时数据仓库架构中，您可以使用TiDB作为应用程序数据源来执行事务性查询，也可以将其作为实时OLAP引擎用于分析场景中的计算。

横向可伸缩性。您可以通过向Flink和TiDB添加节点来提高计算能力。

高可用性。使用TiDB，如果实例出现故障，集群服务不受影响，数据保持完整和可用。Flink支持针对作业或实例的多种备份和恢复措施。

学习和配置成本低。TiDB兼容MySQL5.7协议。在Flink 1.11中，您可以使用Flink SQL语法和强大的连接器来编写和提交任务。

通过使用Ververica的Flink-Connector-MySQL-CDC，您不仅可以使用Flink作为采集层收集MySQL binlog生成动态表，还可以作为流计算层实现流计算，如流连接和预聚合。最后，通过JDBC连接器，Flink将计算出的数据写入TiDB。

该体系结构简单方便。当你为MySQL和TiDB准备了相应的数据库和表之后，你就可以编写Flink SQL语句来注册和提交任务了。您可以在尝试Flink+TiDB with Docker Compose一节中尝试这种架构。

如果数据已经通过其他渠道存储在Kafka中，Flink可以通过Flink Kafka连接器获取数据。

如果您想要在Kafka中存储MySQL更改日志或其他数据源以进行Flink处理，建议您使用Canal或Debezium来收集数据源更改日志。Flink 1.11可以解析这些工具的更改日志。您不需要实现额外的解析器。

TiCDC是TiDB的变更数据捕获框架。它是一个开源功能，可以将TiDB的增量更改复制到下游平台。您可以使用它将TiDB更改数据输出到消息队列，然后Flink可以提取该数据。

在TiDB 4.0.8中，您可以通过TiCDC开放协议将TiDB连接到Flink。在以后的版本中，TiCDC将支持Canal-json输出格式以供Flink使用。

现在我们已经对Flink+TiDB架构有了基本的了解，让我们来看一些现实世界的案例研究。你可能会发现它们对你自己的工作很有启发性。

小红书是中国流行的社交媒体和电子商务平台。小红书应用允许用户通过短视频和照片发布和分享产品评论、旅游博客和生活方式故事。截至2019年7月，它的注册用户超过3亿。在之前的一篇文章中，小红书的一位工程师讨论了该公司为什么选择TiDB，以及TiDB的实时HTAP功能如何帮助管理他们的数据。

在小红书的应用架构中，Flink从TiDB获取数据，并在TiDB中聚合数据。如下图所示：

Flink从Kafka读取更改日志并执行计算，例如连接宽表或聚合表。

这一过程是一个基于TiDB的闭环。TiDB将后续的分析任务JOIN操作转移到Flink，并使用流计算来缓解压力。

目前，该解决方案支持小红书的内容审核、注释标签推荐和增长审核应用。该系统能够应对高吞吐量在线应用的挑战，运行稳定。

北科金融是国内领先的消费房地产金融服务商。它使用人工智能算法高效地应用多维、海量数据，以增强用户的产品体验，并为他们提供丰富和定制的金融服务。

Synercer(将数据从MySQL复制到TiDB的工具)从应用程序数据源收集维度表数据，并将其复制到TiDB。

Canal收集应用程序数据源的流表数据的binlog，并将其存储在Kafka的消息队列中。

Flink读取Kafka中流表的更改日志，并执行流连接。当需要维度表数据时，Flink搜索TiDB。

在此过程中，数据服务中的主表可以实时联接。然后，服务团队只需要查询一个表。北科数据团队使用这种架构来开发每个核心应用程序使用的系统。数据服务获取跨系统的数据。北科金融不需要开发应用系统API或内存聚合数据代码。

PatSnap是一个全球专利搜索数据库，集成了来自116个国家的1.3亿条专利数据记录和1.7亿条化学结构数据记录。它的用户可以搜索、浏览、翻译专利，并生成专利分析报告。

当PatSnap用Kinesis+Flink+TiDB取代原来的Segment+RedShift架构时，他们发现他们不需要构建操作数据存储(ODS)层。

作为预计算单元，Flink为应用程序构建了一个Flink提取-转换-加载(ETL)作业。这完全控制了数据保存规则并定制了模式；也就是说，它只清理应用程序关注的指标，并将它们写入TiDB进行分析和查询。

PatSnap在TiDB之上构建了三层：数据仓库细节(DWD)、数据仓库服务(DWS)和分析数据存储(ADS)。这些层服务于应用程序统计和列表要求。它们基于用户、租户、地区和应用程序指标，以及几分钟或几天的时间窗口。上层应用程序可以直接使用构造的数据，获得二级实时能力。

合理的数据分层大大简化了基于TiDB的实时数据仓库，并使开发、扩展和维护变得更容易。

这个解决方案满足了不同即席查询的要求，而且他们不需要等待RedShift预编译。

目前，PatSnap正在将此架构部署到生产环境中。他们使用它进行用户行为分析，并跟踪和汇总有关公司运营和租户行为分析的总体数据。

网易游戏隶属于网易公司，是一家领先的自主开发的PC客户端和手机游戏提供商。作为世界上最大的七家游戏公司之一，它拥有超过250款游戏在运营，其中一些游戏保持着数百万的日活跃用户。在去年的一篇文章中，他们讨论了为什么选择TiDB而不是其他基于MySQL和NewSQL的存储解决方案。

TiDB充当分析数据源，Flink群集对数据执行实时流计算以生成分析报告。

网易游戏还开发了Flink作业管理平台来管理作业生命周期。

知乎，在文言文中的意思是你知道吗？它是中国的问答网站：一个由用户社区创建、回答、编辑和组织各种问题的网站。作为中国最大的知识共享平台，它拥有超过2.2亿注册用户和3000万个问题，在网站上有超过1.3亿个答案。

在2019年的一篇帖子中，他们展示了如何在拥有超过1.3万亿行数据的情况下，将查询响应时间保持在毫秒级。他们2020年的帖子描述了他们如何使用TiDB横向扩展蜂巢Metastore，以满足其不断增长的业务需求。

作为PingCAP合作伙伴和Flink深度用户，知乎开发了TiDB+Flink互动工具TiBigData，并将其贡献给开源社区。在此工具中：

Flink TiDB Catalog可以直接使用Flink SQL中的TiDB表。你不需要重新创建它们。

为了更好地理解我们的解决方案，也为了您自己进行测试，我们在GitHub上提供了一个MySQL-Flink-TiDB测试环境，其中包含Docker Compose in Flink-tidb-rdw。

启动Docker Compose后，您可以通过Flink SQL客户端编写和提交Flink任务，并通过localhost：8081观察任务执行情况。

如果您对Flink+TiDB实时数据仓库感兴趣或有任何问题，欢迎您加入我们的Slack社区，并将您的反馈发送给我们。您也可以通过[email protected]联系我，与我讨论问题。

在这篇文章中，小红书分享了他们选择TiDB的原因，以及TiDB的实时HTAP功能如何帮助他们管理数据。

这是业界第一篇关于分布式实时HTAP数据库实现的论文。