LinkTime_Cloud

深入浅出：数据流水线管理（下）

在《深入浅出：数据流水线管理（上）》中，我们详细介绍了数据流水线的定义与模型、应用类别、运行方式、示例及挑战。在下半部分，我们将详细介绍数据流水线的功能需求、系统组件等内容。

数据流水线管理系统功能需求

为应对12.5节列出的挑战，需要搭建一个满足以下功能需求的数据流水线管理系统：自动化流水线、数据管理和性能要求。

1、自动化流水线

数据中台的应用运营和调度，离不开一个高度可靠和自动化的数据流水线管理系统。用开源组件搭建的数据流水线可以完成很多工作，但在生产环境中，我们需要将软件工程的严谨性应用于数据管道的开发和执行中，加速数据处理和分析应用的交付，同时提高质量，降低成本。这样数据团队才能通过提供“更快、更好、更便宜”的数据来提高数据的商业价值和客户满意度。所以，像拼接积木一样将组件拼凑在一起是远远不够的。

这里举一个Uber的例子。Uber在早期快速发展阶段，使用了众多的数据工作流，因为缺乏一个良好的数据流管理工具，员工必须为每个用例从几个功能重叠的工具中进行选择。这个大工具箱虽然允许快速扩展，但要求工程师学习重复的数据工作流系统以应对不同的项目，被证明是难以管理和维护的。

因此，我们需要一个可以创建、管理、调度和部署数据工作流的中心工具，来实现数据管理自动化。在数据管理自化的阶段，通过拼接组件，企业已经拥有一个基本的大数据平台，接下来可能有以下需求：

一些定期运行的Hive查询，比如每小时或每天一次，以生成商业智能报告;
使用Spark程序运行机器学习程序，生成一些用户分析模型，使产品系统可以提供个性化服务;
一些需要不时从远程站点抓取数据的爬虫程序;
一些流数据处理程序，用于创建实时数据仪表板并显示在大屏幕上。

要实现这些需求，需要一个作业调度引擎，一般称为工作流系统，能够根据时间或数据可用性来运行这些程序和查询（类似Linux机器上的Cron程序），常见的工作流系统包括Oozie、Azkaban、Airflow。

不同工作流系统之间的功能差异很大。例如，一些系统提供依赖关系管理，允许指定调度逻辑，如作业A仅在作业B和作业C完成时运行；一些系统允许仅管理Hadoop程序，而另一些系统则允许更多类型的工作流程，必须决定一个最符合要求的。

除了工作流系统，还有其他需要自动化的任务。例如，如果HDFS上的某些数据需要在一段时间后删除，假设数据只保留一年，那么在一年后的第一天，我们需要从数据集中删除最早一天的数据，依次类推，这就是数据保留策略。需要编写一个程序，为每个数据源指定并实施数据保留策略，否则硬盘容量将很快耗尽。

2、数据管理

当数据流水线投入生产并开始正常提供报告后，真正焦灼且有挑战性的问题来了：数据管理问题。一个企业级大数据系统不仅要处理与任何标准系统操作类似的硬件和软件故障问题，还要处理与数据相关的问题。一个真正数据驱动的系统需要确保数据完整、正确、准时，并为数据进化做好准备。因此，数据流水线管理系统应该满足下列数据管理需求：

确保在数据流水线的任何步骤中数据都不会丢失，因此，需要监控每个程序正在处理的数据量，以便尽快检测到任何异常；
有对数据质量进行测试的机制，以便在数据中出现任何意外值时，接收到告警信息；
监控应用程序的运行时间，以使每个数据源都有一个预定义的ETA（Estimated Time of Arrival），并且会对延迟的数据源发出警报；
管理数据血缘关系，以便我们了解每个数据源的生成方式，在出现问题时，知道哪些数据和结果会受到影响；
系统应自动处理合法的元数据变更，并应立即发现和报告非法元数据变更；
对应用程序进行版本控制并将其与数据相关联，以便在程序更改时，我们知道相关数据是如何被更改的。

此外，我们要为数据科学家提供单独的测试环境来测试代码，并提供各种便捷和安全的工具，使他们能够快速验证自己的想法，并将其方便地发布到生产环境。

3、性能要求

除了上面在自动化和数据管理方面的功能需求之外，数据流水线管理系统还必须满足下面的性能要求。

低事件延迟：数据分析师（数据科学家）应该能在数据被发送到某条管道后的几分钟或几秒钟内开始数据的查询工作。
可伸缩性：根据业务的规模能够扩充数据处理的节点。提高性能和可扩展性，不仅要满足存储此数据，还应该使完整的数据可用于查询。
高效查询：高性能的流水线应同时支持长期运行的批查询和较小的交互式查询，数据科学家可以从任意层级（数据湖、数据仓库、数据集市）开始探索。
版本控制：能够对数据应用进行版本定义，并通过创建数据流水线的分支，避免对正在用于生产的数据进行破坏性的操作。
自动监控：跟踪管道的执行情况（正常、延迟、失败或失败冻结）进行监控，自动通过邮件或短信工具生成警报。

数据流水线管理系统组件

为了达到上面列出的管理功能，搭建一个完善的数据流水线管理系统需要如图所示的系统组件。

数据流水线组件图

数据应用开发工具：这里既包括常见的BI、ETL程序，也包括机器学习程序的开发、测试和调度界面。有很多系统使用Eclipse、Jupyter这些常见的开发工具，再配上调度配置工具。
代码库：为数据开发人员提供的一个存储代码（如Spark或ETL代码）的地方。代码库需要提供签入/签出和版本控制功能，并与这里所列出的大多数类型的开发工具集成。
配置库：用于存储所有系统的配置和设置，涵盖开发、测试和生产系统。配置库可管理软件版本并确保无错误部署。
调度引擎：这是整个数据流水线管理系统的核心部分，负责所有任务的发布、运行、容错，管理数据任务之间的依赖、重跑，以及收集批处理数据应用运行的元数据等。
应用元数据、运营数据库：由调度引擎写入数据应用的运行指标、运行状况等关键信息，用于数据流水线的运营管理。
运营管理工具：包括数据应用间的血缘关系追溯、批处理重跑、性能监控等，例如它会监视底层系统并查明是什么原因造成业务应用程序的性能问题和中断；然后通知管理员，并采取措施解决。

总而言之，建设一个完善的数据流水线管理系统的核心是在受控制的环境中应用一系列工具链，以支持在复杂分布式计算环境中的数据开发。

批流合一数据流水线

上一篇介绍过数据流水线的应用举例，其中有批处理和流处理两种核心模式。在处理的时候一般需要将批处理和流处理数据分别存储和处理，这就会造成资源的冗余和额外的协调工作。其实时下还有一种非常流行的说法叫作批流合一(也叫作批流融合)。这个概念的兴起并不意外，流式处理引擎的发展非常迅速，从Storm到Spark Streaming再到Flink，原因有二：一是底层数据处理技术的更新迭代，二是业务的发展对流式处理框架提出了同时支持低延迟和高吞吐的要求。那么，企业在设计流水线整体架构时就需要考虑，是走批流分离路线还是走批流合一路线？

批流分离比较好理解，这里分析一下批流合一的底层逻辑。批流合一路线中一个比较激进的分支认定“批处理逐渐走向历史，流处理即将挑起大梁”，参考Jay Kreps提出的Kappa架构（如图）。

Kappa架构图

正如作者Jay Kreps自述的那样：

Kappa架构体系中的规范数据存储不是使用像SQL这样的关系型数据库或像Cassandra这样的键值存储，而是仅附加不可变的日志。数据从日志中流过计算系统，并注入辅助的存储中以进行应用服务。

Kappa架构将Lambda架构化繁为简。Kappa体系结构系统类似于Lambda体系结构系统，但删除了批处理系统。要代替批处理，只需简单地将数据快速输送至流式系统中。

在继续分析之前，先来回顾一下Lambda架构的基本特性。Lambda作为在传统数据分析平台进化的架构，其数据处理分为Speed Layer、Batch Layer和Serving Layer三个部分，其中：

Speed Layer负责实时处理数据；
Batch Layer负责批量规模化处理数据；
Serving Layer负责融合Speed和Batch两部分的数据能力，对外提供简单一致的数据访问视图。

通过对比可以看出，Kappa的整体思路是在单个流式处理引擎中同时进行实时数据处理和连续再处理。这就要求传入的数据流可以全部或从特定位置进行回溯，如果有任何代码更改，则使用第二次流处理将通过最新的实时引擎重播所有先前的数据，并替换存储在服务层的数据。Kappa专注于仅将数据作为流处理，所以除了有非常适合的实际使用场景，其本质上不能替代Lambda体系结构。Kappa可以算是批流合一这个领域的突出代表，但是通过对它的分析，可以推导出一个初步结论：全面的批流合一的大一统是有一定难度的，但在用例非常确定的场景下，可以尝试。

分析完Kappa之后，继续来看Lambda。Lambda在一套平台中将批计算和流计算整合在了一起，但是经典的Lambda架构并不完美，随后出现的有状态流计算架构就是在其之上的不断优化：

在数据产生的过程中进行计算并直接产生统计结果；
同时满足高性能、高吞吐、低延时等众多目标。

在批流合一这个领域，在有状态流式计算架构中，基于Flink的解决方案是值得探讨的。Flink支持流式计算的状态管理，即计算过程中将算子的中间结果数据保存在内存或文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果来计算当前的结果。这在大数据的实时数据应用处理场景中有非常好的支持，其中值得特别说明的应用场景是实时数据仓库的建设实践。在这个场景中，流式计算框架与离线数据仓库相结合，利用SQL灵活的加工能力，对流式数据进行实时清洗和结构化处理，同时利用有状态流式计算技术，降低在离线数据计算过程中调度逻辑的复杂度，快速产出分析及统计结果。

Flink的DataStream API用于开发流式应用，而DataSet API则用于处理批量数据。Flink提供丰富的转换操作以完成对数据集的批量处理，最终将数据写入外部存储介质中。原则上，Flink倾向于将批量数据作为流式数据的子集，进而通过一套引擎同时处理批量和流式数据。目前来看，批流合一的关注重点是将批作为流的特殊情况处理。Flink社区表示未来将会加大在批流合一这个领域的投入。

批和流是数据应用中的两种形态，有各自的应用场景。如果需要将两种状态融合，那么在容错性、数据异构性及数据一致性等方面都要进行相应的考量，并非一定要具体选择哪一种。在企业发展的不同阶段，业务的需求不尽相同，最重要的是在一个数据驱动的IT架构下，架构能随着企业发展的不同阶段而演化。

小结

数据流水线是数据驱动的重要环节，也是数据中台建设的重要过程。数据流水线中数据流转的效率决定了数据中台建设过程中的数据能力共享、复用的效率。本章介绍了数据流水线及其在建设过程中的问题，并对数据流水线的最佳实践形式进行了详细阐述。

以上内容摘自《云原生数据中台：架构、方法论与实践》，经出版方授权发布。前Twitter大数据平台主任工程师撰写，融合硅谷与国内经验，全面讲解云原生数据中台架构、选型、方法论、实施路径，国内外专家联袂推荐。

该书刚刚荣获“财资中国2021年度好书”殊荣，欢迎大家阅读。