共计 5285 个字符，预计需要花费 14 分钟才能阅读完成。
简介：本文由知乎技术平台负责人孙晓光分享，次要介绍知乎 Flink 数据集成平台建设实际。内容如下：1. 业务场景；2. 历史设计；3. 全面转向 Flink 后的设计；4. 将来 Flink 利用场景的布局。
本文由知乎技术平台负责人孙晓光分享，次要介绍知乎 Flink 数据集成平台建设实际。内容如下：
业务场景
历史设计
全面转向 Flink 后的设计
将来 Flink 利用场景的布局
一、业务场景
很快乐和大家分享近期知乎以 Flink 为根底，重构上一代数据集成平台过程中的一些播种。数据集成平台作为连贯各种异构数据的纽带，须要连贯多种多样的存储系统。而不同的技术栈和不同的业务场景会对数据集成系统提出不同的设计要求。
咱们首先来看一下在知乎外部数据集成的业务场景。同许多互联网公司类似，过来知乎的在线存储系统次要以 MySQL 和 Redis 为主，同时对于局部数据量级较大的业务也应用了 HBase。近年来随着技术的演进，咱们开始了从 MySQL 向 TiDB 的迁徙。与此相似，咱们也开始将 HBase 向基于 TiKV 技术栈研发的 Zetta 演进。在离线存储方面绝大多数的场景则是以 Hive 表来撑持的。
从在线存储到离线存储，期间有着十分强的数据同步需要。除此以外也存在着大量的流式数据，比方音讯零碎中的数据，咱们也心愿它可能同各种在线或离线存储系统买通。过来知乎次要应用 Kafka 撑持流式数据，近期也开始引入 Pulsar。这两套音讯零碎同存储系统之间的数据交换存在着较强的需要。
在知乎的业务场景和以后倒退状态下，数据集成工作在技术和流程治理上都存在着一些挑战。
首先从技术角度看，数据源多样化会对数据集成系统的连贯扩大能力提出较高的要求。而且下一代的存储系统在给业务带来更强能力的同时也开释了业务的压力，进而促使了数据量的减速收缩。数据量级上的快速增长对数据集成平台的吞吐和实时性都提出了更高的要求。当然作为数据相干的根底零碎，数据准确性则是最根底的要求，这块咱们也必须把它做好。
另外从流程治理角度看，咱们须要了解并整合散落在不同业务团队的数据，做好治理并确保数据拜访的平安，所以整个数据整合的流程是绝对简单的。尽管平台化可能将简单的流程自动化起来，但数据集成工作所固有的高老本并不能齐全以平台化的形式打消。因而尽最大的可能晋升流程的可复用性和可管理性也是数据集成系统须要继续应答的挑战。
基于这两个方向上的挑战，咱们对数据集成平台的设计指标进行了布局。
从技术方向看，咱们须要反对知乎曾经投入使用和未来要推广应用的多种存储系统，具备将这些零碎中多样化的数据进行集成的能力。此外咱们还须要在满足高吞吐，低调度时延的前提下保障数据集成的可靠性和准确性。
从流程方面看，能够通过整合各种外部存储系统的元数据以及调度零碎，复用现有零碎基础设施的能力，达到简化数据接入流程，升高用户接入老本的目标。咱们还心愿可能以平台化的形式为用户提供自助满足数据需要的伎俩，从而晋升数据集成工作的整体效率。
从晋升工作可管理性的角度看，咱们还要保护好数据的血缘关系。让业务更好的去度量数据产出之间的关系，更无效的评估数据产出的业务价值，防止低质量和重复性的数据集成工作。最初咱们须要对所有工作提供系统化的监控和报警能力来保障数据产出的稳定性。
二、历史设计
在知乎的第一代数据集成平台成型前，大量的工作散落在各个业务方本人保护的 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 代码设计不现实导致的可扩展性和可管理性弱的问题。
三、转向 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 的迁徙为咱们带来了许多收益。
- 首先从可维护性上看，相比 Sqoop 有了十分显著的改善。如下图所示，右边是过来应用 Sqoop 时的工作定义，这里是一大堆非结构化的容易出错的原始命令。而 Flink 则只需应用 SQL 定义一个源表和一个指标表再配合写入命令来定义工作。工作的可了解性、可调试性远好于从前，变成最终用户也可能了解的模式。很多问题不再须要平台开发者配合排查，用户就可能自助的解决许多常见的工作异样。
- 在性能角度方面，咱们也有针对性的做了许多优化。
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 的能力隔离在线交易和数据抽取的负载。
最初咱们还引入了分布式的数据提交形式晋升了数据写入的吞吐能力。
- 最初是为知乎外部宽泛应用的 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 资源池所带来的资源效率晋升，在老本和治理角度看都使咱们取得了显著的收益。
四、Flink 即将来
回过头看，本次全面 Flink 化的演进投入产出比十分高，这也进一步加强了咱们对“Flink 即将来”的的信念。目前在知乎外部除了数据集成场景，Flink 在搜寻 Query 的时效性剖析、商业广告点击数据处理和要害业务指标的实时数仓上也都有所利用。
在将来咱们心愿可能进一步扩大 Flink 在知乎的应用场景，建设更加全面的实时数仓、系统化的在线机器学习平台。咱们更心愿批流一体的落地，让报表类和 ETL 类的大型批工作也可能在 Flink 平台上落地。
基于知乎大数据系统建设的模式和总体资源投入的状况，将来将技术栈向 Flink 收拢是一个非常适合知乎的抉择。作为用户咱们十分期待可能一起见证将来 Flink 批流一体指标的达成。同时作为社区的成员，咱们也心愿可能用本人的形式为这一指标的达成奉献一份力量。
原文链接
本文为阿里云原创内容，未经容许不得转载。
