知乎的 Flink 数据集成平台建设实践

简介： 本文由知乎技术平台负责人孙晓光分享，主要介绍知乎 Flink 数据集成平台建设实践。内容以下： 1. 业务场景 ； 2. 历史设计 ； 3. 全面转向 Flink 后的设计 ； 4. 将来 Flink 应用场景的规划。

本文由知乎技术平台负责人孙晓光分享，主要介绍知乎 Flink 数据集成平台建设实践。内容以下：

业务场景
历史设计
全面转向 Flink 后的设计
将来 Flink 应用场景的规划

1、业务场景

很高兴和你们分享近期知乎以 Flink 为基础，重构上一代数据集成平台过程当中的一些收获。数据集成平台做为链接各类异构数据的纽带，须要链接多种多样的存储系统。而不一样的技术栈和不一样的业务场景会对数据集成系统提出不一样的设计要求。

咱们首先来看一下在知乎内部数据集成的业务场景。同许多互联网公司类似，过去知乎的在线存储系统主要以 MySQL 和 Redis 为主，同时对于部分数据量级较大的业务也使用了 HBase。近年来随着技术的演进，咱们开始了从 MySQL 向 TiDB 的迁移。与此相似，咱们也开始将 HBase 向基于 TiKV 技术栈研发的 Zetta 演进。在离线存储方面绝大多数的场景则是以 Hive 表来支撑的。

从在线存储到离线存储，期间有着很是强的数据同步需求。除此之外也存在着大量的流式数据，好比消息系统中的数据，咱们也但愿它可以同各类在线或离线存储系统打通。过去知乎主要使用 Kafka 支撑流式数据，近期也开始引入 Pulsar。这两套消息系统同存储系统之间的数据交换存在着较强的需求。

在知乎的业务场景和当前发展状态下，数据集成工做在技术和流程管理上都存在着一些挑战。

首先从技术角度看，数据源多样化会对数据集成系统的链接扩展能力提出较高的要求。并且下一代的存储系统在给业务带来更强能力的同时也释放了业务的压力，进而促使了数据量的加速膨胀。数据量级上的快速增加对数据集成平台的吞吐和实时性都提出了更高的要求。固然做为数据相关的基础系统，数据准确性则是最基础的要求，这块咱们也必须把它作好。

另外从流程管理角度看，咱们须要理解并整合散落在不一样业务团队的数据，作好管理并确保数据访问的安全，因此整个数据整合的流程是相对复杂的。虽然平台化可以将复杂的流程自动化起来，但数据集成工做所固有的高成本并不能彻底以平台化的方式消除。所以尽最大的可能提高流程的可复用性和可管理性也是数据集成系统须要持续应对的挑战。

基于这两个方向上的挑战，咱们对数据集成平台的设计目标进行了规划。

从技术方向看，咱们须要支持知乎已经投入使用和未来要推广使用的多种存储系统，具有将这些系统中多样化的数据进行集成的能力。此外咱们还须要在知足高吞吐，低调度时延的前提下保障数据集成的可靠性和准确性。

从流程方面看，能够经过整合各类内部存储系统的元数据以及调度系统，复用现有系统基础设施的能力，达到简化数据接入流程，下降用户接入成本的目的。咱们还但愿可以以平台化的方式为用户提供自助知足数据需求的手段，从而提高数据集成工做的总体效率。

从提高任务可管理性的角度看，咱们还要维护好数据的血缘关系。让业务更好的去度量数据产出之间的关系，更有效的评估数据产出的业务价值，避免低质量和重复性的数据集成工做。最后咱们须要对全部任务提供系统化的监控和报警能力来保障数据产出的稳定性。

2、历史设计

在知乎的第一代数据集成平台成型前，大量的任务散落在各个业务方本身维护的 crontab 或者自行搭建的各类调度系统中。在这样的无管理状态下，各项集成任务的可靠性和数据质量都很可贵到有效的保障。所以在这个阶段咱们要最迫切解决的是管理上的问题，让数据集成的流程可管理可监控。

所以，咱们整合了各类存储系统的元数据系统，让你们能够在统一的地方看到公司全部的数据资产。而后在调度中心统一管理这些数据的同步任务，由调度中心负责任务的依赖管理。同时调度中心对任务的关键指标进行监控并提供异常告警能力。在这个阶段咱们沿用了从前你们普遍使用的 Sqoop 来实现 MySQL 和 Hive 之间数据的同步。且在平台建设后期，随着流数据同步需求的出现，咱们又引入了 Flink 来同步 Kafka 数据到 HDFS。

在建设初代集成平台时咱们作过一次技术选型的选择，是继续使用已经获得普遍验证的 Sqoop 仍是迁移到其它可选的技术方案。同 Sqoop 相比，阿里开源的 DataX 是这个领域一个很是有竞争力的对手。若是把这两个产品进行横向对比，能够发现他们在不一样的方面互相有对方所不具有的优点。

好比 Sqoop 在系统规模上具有 MapReduce 级别的扩展性和原生的 Hive 支持。但 Sqoop 又有数据源支持不丰富，缺少一些重要功能特性的缺点。

而 DataX 提供了很是丰富的数据源支持，内置了数据集成系统很是重要的限速能力，还有它的良好设计所带来的易于定制和扩展的能力。但它也存在无集群资源管理支持和欠缺 Hive Catalog 原生支持的缺陷。

在当时的状态下这两个产品相互比较起来没有一款产品具备绝对的优点。因此咱们选择了继续使用 Sqoop，而维持使用 Sqoop 在验证环节上也为咱们节约了许多投入，因此第一代的数据集成平台在很是短的时间内就完成了开发和验证并完成上线。

随着初代数据集成平台的上线和成熟，它很好的支撑了公司的数据集成业务需求并得到了显著的收益。到目前为止平台上一共有大约 4000 个任务，天天运行超过 6000 个任务实例，同步大约 82 亿条共计 124TB 的数据。

在平台的帮助下，数据接入流程获得了极大的简化，为用户提供了自助解决数据集成需求的能力。而且，平台在关键的流程节点上可以辅以必要的规范约束和安全审查，在提高了管理水平的同时，总体的安全性和数据质量也获得了显著的提高。

借助于 Yarn 和 K8s 的弹性能力，集成任务的规模扩展能力也有了很大的提高。固然，做为解决从 0 到 1 问题的第一代系统，也必然会伴随着一系列问题。好比：

Sqoop 的 MapReduce 模式所固有的高调度时延问题
业务数据分布不均所致使的数据倾斜问题
社区不活跃致使部分 Issue 长期没法获得解决的问题
Sqoop 代码设计不理想致使的可扩展性和可管理性弱的问题。

3、转向 Flink

与 Sqoop 相对的，是用于支持 Kafka 消息到 HDFS 数据集成任务的 Flink，它以优秀的可靠性和灵活的可定制性得到了你们更多的信任。基于流式数据集成任务为 Flink 创建的信心，咱们开始尝试全面转向 Flink 来建设下一代的数据集成平台。

虽然 Flink 是本次平台演进中的最佳候选，咱们仍是基于当时的状况对市面上可选的技术方案再次进行了调研。此次咱们将 Apache NIFI 项目和 Flink 进行了多方面的比较，从功能角度看：

Apache NIFI 很是强大且彻底覆盖了咱们当前的数据集成需求。可是偏偏由于它功能过于强大而且自成体系，因此也带来了较高的整合门槛。并且，没法利用现有 Yarn 和 K8s 资源池也会带来额外的资源池建设和维护的成本。

相比之下， Flink 具备一个很是活跃和开放的社区，在立项时刻就已经具有了很是丰富的数据源支持，能够预期在将来它的数据源覆盖必定会更加全面。并且 Flink 做为一个通用计算引擎有着强大易用的 API 设计，在这个基础上进行二次开发很是容易，因此它在可扩展性方面的优点也很是突出。

最后基于咱们对批流一体目标的认同，将来在知乎完成大数据计算引擎技术栈的统一也是一个极具吸引力的目标。

基于这些考量，在本轮迭代中咱们选择了全面使用 Flink 替代 Sqoop，基于 Flink 完整实现了以前 Sqoop 的功能并从新建设了全新的集成平台。

以下图所示，橙色部分是本轮迭代中发生了变化的部分。除了做为主角出现的 Flink 以外，在本轮迭代的过程当中咱们还开发了 TiDB、Redis 和 Zetta 三种存储系统的数据集成功能。在消息系统这边则直接从社区得到了 Pulsar 的支持。在咱们开始开发工做的时候，Flink 已经演进到了比较成熟的阶段，对 Hive 内建了原生的支持，整个迁移过程没有遇到过多的技术困难，很是顺畅。

Flink 的迁移为咱们带来了许多收益。

1. 首先从可维护性上看，相比 Sqoop 有了很是显著的改善。以下图所示，左边是过去使用 Sqoop 时的任务定义，这里是一大堆非结构化的容易出错的原始命令。而 Flink 则只需使用 SQL 定义一个源表和一个目标表再配合写入命令来定义任务。任务的可理解性、可调试性远好于从前，变成最终用户也可以理解的模式。不少问题再也不须要平台开发者配合排查，用户就可以自助的解决许多常见的任务异常。

1. 在性能角度方面，咱们也有针对性的作了许多优化。

2.1 调度策略

首先是调度策略上的优化，在第一代集成平台中咱们只使用 Flink 同步流式数据，因此任务调度彻底使用 Per Job。如今平台同时支持了 Session 和 Per Job 的混合调度模式，因而，对于从消息系统接入数据的流式任务会继续使用 Per-Job 模式运行，而批同步的任务则采用 Session 模式复用集群从而避免集群启动的耗时提高同步效率。

固然，在这样的场景中使用 Session 集群也存在着一系列的挑战，好比工做负载随着任务提交不停变化而带来的资源需求变化问题。因此咱们建设了自动的扩缩容机制来帮助 Session 集群应对变化的负载。除此之外，为了简化计费机制和隔离风险，咱们还为不一样的业务线建立了私有 Session 集群用于服务对应业务线的数据集成任务。

2.2 数据库

在关系数据库方面，咱们采用了常见的 JDBC 方式对 MySQL 进行数据同步，但这种方式也会存在一些固有难以解决的问题。

好比因业务数据在主键维度上空间分布不均致使的数据倾斜问题。

再好比为了隔离在线离线工做负载所建设的专用同步从库，所产生的资源浪费和管理成本。

而且因为 MySQL 实例众多规格不一，合理协调多个并发任务的实例和实例所在的主机，进行合理的速度控制也很是困难。

相比之下，考虑到正在全面将数据从 MySQL 迁移到 TiDB 这一趋势。咱们开发了原生 TiDB 的 Flink connector 来充分利用 TiDB 架构上的优点。

首先 region 级别的负载均衡策略可以确保对于任何表结构和任何的数据分布，同步任务都可以以 region 为颗粒度进行拆分避免数据倾斜问题。

其次经过设定副本放置策略，能够在离线数据中心对数据统一放置一个 Follower 副本。进而在保持原有目标副本数量不变，无需额外资源成本的状况下，利用 Follower read 的能力隔离在线交易和数据抽取的负载。

最后咱们还引入了分布式的数据提交方式提高了数据写入的吞吐能力。

1. 最后是为知乎内部普遍使用的 Redis 提供数据集成的能力。Flink 社区已经有一个 Redis connector，但它目前只具有写入能力而且难以灵活定制写入时所使用的 key。因此咱们基于自身需求从新开发了一个 Redis connector，同时支持以 Redis 做为 Source 和 Sink。

一样为了不数据抽取过程影响在线交易，在数据读取路径上咱们采用了 Redis 原生的 master/slave 机制获取并解析 RDB 文件抽取数据，得到了单实例约 150MB 每秒的数据抽取吞吐。并且得益于打通内部存储系统的元数据，咱们不但可以支持分片模式 Redis 集群的数据抽取，还能够只选择每一个分片的 slave 节点做为数据抽取源头，避免抽取对 master 节点产生压力。

此次全面转向 Flink 的演进，解决了不少上一代数据集成平台的问题，得到了很是显著的收益。

从吞吐角度看，以 Flink 替代 MR 模式将整个调度的时延从分钟级下降到了 10 秒左右。而且在一样的数据量和一样的 Flink 资源量状况下，TiDB 原生 connector 可以比 JDBC 提高 4 倍的吞吐。

从功能角度看，新平台不但可以原生支持分库分表的数据集成任务，还可以以业务无关的方式避免数据倾斜的问题。

在数据源支持能力上，咱们以很是低的成本得到了 TiDB、Zetta、Redis 和 Pulsar 的支持。并且，随着 Flink 的生态愈来愈完善，将来必定会有更多的开箱即用的 connector 供咱们使用。

从成本上看，最后下线 MySQL 离线节点和统一使用 K8s 资源池所带来的资源效率提高，在成本和管理角度看都使咱们得到了显著的收益。

4、Flink 即将来

回过头看，本次全面 Flink 化的演进投入产出比很是高，这也进一步加强了咱们对 “Flink 即将来” 的的信心。目前在知乎内部除了数据集成场景，Flink 在搜索 Query 的时效性分析、商业广告点击数据处理和关键业务指标的实时数仓上也都有所应用。

在将来咱们但愿可以进一步扩展 Flink 在知乎的使用场景，建设更加全面的实时数仓、系统化的在线机器学习平台。咱们更但愿批流一体的落地，让报表类和 ETL 类的大型批任务也可以在 Flink 平台上落地。

基于知乎大数据系统建设的模式和整体资源投入的状况，将来将技术栈向 Flink 收拢是一个很是适合知乎的选择。做为用户咱们很是期待可以一同见证将来 Flink 批流一体目标的达成。同时做为社区的成员，咱们也但愿可以用本身的方式为这一目标的达成贡献一份力量。

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