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

LinkTime_Cloud

于 2021-12-22 19:58:51 发布

阅读量2.4k

点赞数

文章标签：数据库大数据编程语言 hadoop python

本文链接：https://blog.csdn.net/LinkTime_Cloud/article/details/122098468

版权

在绝大部分企业的数据中台建设中，数据流水线的建设都是核心工作之一。数据流水线系统承担着将数据从原始形态转换到用户与业务应用可以直接使用的形态的整个过程。在绝大多数时候，这些工作必须是自动且高度可靠的，并能够实时确保数据的正确性。数据流水线是数据驱动的重要环节，也是数据中台建设的重要过程。

本文主要介绍数据流水线的具体任务以及建设数据流水线的注意事项。

数据流水线定义与模型

简单来讲，数据流水线就是从原始数据到最终数据能力（如报表、大屏、数据服务）的整个转换流程的管理系统，就像工厂里从原材料到成品的流水线管理一样。数据流水线管理的是这个转换流程中的程序和数据。这些程序的输入/输出数据是什么，两个相关联的程序如何协调运行，如何保证程序和数据的质量，如何在出现问题时报警，都是数据流水线的工作。图中所示为一个典型的数据流水线模型。

图 | 常见数据流水线模型

数据流水线输入的数据是各种形式的原始数据，例如业务系统的OLTP数据库、服务器的日志、第三方合作伙伴的数据接口、用户上传的文件、ERP/CRM系统的数据、从互联网上下载的媒体文件等。它们必须经过数据流水线的清洗、转换、分析，才能最终产生数据价值。

数据流水线中的应用，运行平台和处理的数据是多种多样的，例如用Python编写的采集互联网数据的爬虫，用Java编写的接受第三方数据的API服务，采集关系型数据库数据的Sqoop（运行在Hadoop上），DataX（运行在命令行上），进行数据转换的SQL程序（运行在Hive上）等。如果需要处理实时数据，可能还有Kafka/Flink流处理应用。这些程序之间一般都有依赖关系，而且有不同的调度周期，有的是持续运行的，有的是按小时/天定时运行，还有的是按照数据到达的时间来运行。

为了管理这些数据处理应用以及它们处理的数据，我们需要一个完善的数据流水线系统。这里我们对数据流水线下一个定义：

数据流水线是一个数据处理应用管理系统，它负责发布、调度、运行、管理所有自动的数据处理应用，将数据从各种数据来源进行提取、转换、分析、存储，最后形成可被直接使用的形式。

数据流水线与传统的ETL有何不同呢？数据流水线是一个更为广泛的术语，其中包含ETL。ETL（Extract-Transform-Load）及其变形ELT（Extract-Load-Transform），是指数据的萃取、转换、治理过程，一般由一系列SQL语句完成，在Hadoop生态中也可以由一些MapReduce任务来完成。而数据流水线需要管理系统中所有数据流动的全流程。在流动的过程中，数据可以转换，也可以不转换，可以使用机器学习算法生成新数据，并且可以以实时或流式处理的方式来进行，而不只是批量处理。

谁会需要数据流水线呢？企业不分大小，只要业务增长依赖数据驱动，就可以开始搭建数据流水线。如果有以下几个特征，那么企业就可以计划铺设数据流水线了：

依赖批处理ETL的流程已经难以承载由业务的持续增长带来的分析压力；
不能很好地对非结构、结构化数据进行分析；
无法进行全局的数据汇聚和治理；
无法利用机器学习的手段对数据进行深度分析；
数据驱动的应用从设计到实际实施的时间太久；
在传统报表之外需要更多类型的数据能力的支持。

数据流水线中的应用类别

数据流水线中的应用承担了将数据从原始形态转换到最终数据能力各个阶段的工作，它们可以按照转换的功能分为以下几类：数据采集、数据转换、数据分析和数据传输。

数据采集应用负责从各种数据源采集原始数据，采集后可以将数据存放到数据湖中，也可以输入Kafka之类的流处理系统中供后续处理。常用的数据采集应用可以采集以下数据。

1）数据库数据。Sqoop、DataX、Canal、Kettle等工具都能从数据库中采集数据，选择哪种工具一般看吞吐量要求、实时要求、兼容性要求，例如Sqoop比较适合将关系型数据库中的数据采集到HDFS或Hive中，而Canal比较适合采集MySQL的实时更新数据。

2）服务器日志。Flume、Logstash等工具可用于采集服务器日志，一般将采集的日志上传到HDFS供后续处理。选择工具时考虑的性能指标有延迟、CPU/内存占用量、是否支持断点续传、容错性等。

3）API数据。访问内部或外部API以获取数据并将其存放到数据库或HDFS中，一般需要编写定制的数据采集程序来完成这种需求。这种采集程序有无状态和有状态两种。无状态程序一般按固定时间间隔去访问固定API以获取数据。有状态程序需要使用一定的参数序列去访问API，这类程序的主要需求是能记录之前访问的状态，这样重启后可以从上次访问的地方继续，而不需要完全重来。

4）用户上传数据。允许用户上传数据文件。最简单的方式是让用户通过FTP服务器上传文件，然后使用监控程序扫描整个FTP目录，发现新上传的文件并将其传送到HDFS上。还有一种可能的方式是编写一个可以接受用户上传文件的Web Service，通过POST请求上传文件。

5）互联网数据。使用爬虫程序读取互联网上公开的数据，例如网页、在线数据库、公开的数据服务等，并将其结果存放到HDFS。如果采集的需求比较复杂，那么对爬虫程序的要求就比较类似于搜索引擎的爬虫程序，要求对并发度、网页模式、自动跳转、表格填充有很好的管理。如果需求比较简单，借助Scrapy这样的框架，我们就可以快速编写出简单的爬虫，而数据流水线的主要任务则是高效和稳定地运行这些爬虫程序。

数据转换应用主要负责将采集上来的数据转换成可以分析的形式，这有两种转换形式。一种转换是将非结构化数据转换成结构化或半结构化数据。例如，将采集回来的网页数据从HTML格式转换成可用文本，将其中的表格变成Hive中的表，或者将服务器日志中的关键字段提取出来，形成半结构化的JSON数据结构。另一种转换是将多个关系型数据表进行join和过滤，使得结果表更容易被后续程序处理。ETL中的转换主要就是这种转换。除了形式上的转换之外，语义上的转换也很常见，例如数据清洗应用负责转换后数据语义上的正确性和一致性。上面列出的数据采集应用的输出一般都需要经过数据转换才能使用。

在数据转换完成后，数据分析应用负责从数据中产生各种统计数据以及商业洞见，例如使用SQL产生报表或者使用机器学习算法生成模型。我们常说的数据应用主要是指这些数据分析应用。第15章将会详细介绍数据应用的开发。

数据传输应用的功能比较简单，就是将数据在各个系统中传输，例如将Hive SQL产生的报表装载到MySQL中供BI报表使用，放到Redis中供数据服务使用。另一种常见的数据传输场景是数据复制，例如将数据从一个Hadoop集群复制到另一个Hadoop集群，有时是为了备份，有时是为了提供测试数据。这些数据传输应用有的有现成的工具，例如HDFS复制常用的distcp，但很多时候需要编写专门的工具。

数据流水线运行方式

上节提到各种功能的应用按照运行方式可以分为批处理应用（batch）、流处理应用（streaming）及服务应用（service）。

批处理应用一般是按照固定的时间粒度（如小时、天）来运行。图中所示为一个典型的批处理应用流程，其中，每小时使用Sqoop从业务数据库里采集数据存放到HDFS上，然后在采集完毕后运行用Spark编写的ETL程序将数据导入Hive数据仓库中，最后将Hive数据导入Impala用以支持BI工具查询。这种数据流水线的主要优点是吞吐率高（单位时间内处理的数据量大），但缺点也很明显：数据延迟大，用户通过查询系统只能查到指定时间之前的分析数据。

图 | 批处理流水线样例

流处理应用对每一个到达系统的数据项进行即时处理，数据就像流经的水流一样被连续处理，而不是被人为地分批处理。流处理的好处在于能够在数据产生的很短时间内就对数据进行捕捉和处理，并将处理后的数据快速输出到数据6应用中，整个过程的延迟一般在秒级或以下。流数据处理的一个常用场景是实时大屏，比如电商部门可以在实时大屏中显示实时的销售数据。常用的开源流数据处理框架有Kafka、Spark Streaming和Flink。

根据流式计算引擎的数据组织特点，可将其分为两类：基于行处理（Row Based）和基于小批量处理（Micro-batch Based）。二者的区别见下表。

表 | 基于行处理和基于小批量处理的区别

服务应用又称为“长时间运行服务”（long running service），采集第三方API数据的应用服务，接受用户上传数据的FTP或类似的Web Service，持续采集服务器日志的Flume，读取数据库修改记录的Canal，都是需要持续运行的服务应用。传统关系型数据库中的数据流水线一般不考虑这些应用，但是数据中台中的流水线因为要处理多源异构的数据，这些服务必不可少，而且必须纳入数据流水线的管理。

数据流水线示例

下图展示了一个比较复杂的数据流水线架构，它包含移动应用的用户行为埋点数据的采集，实时处理，机器学习分析产生产品推荐服务，以及提供用户行为分析报表的整个流程。

图 | 复杂数据流水线架构图

图字：

Kafka connet => Kafka Connect

Spark Steaming => Spark Streaming

Node JS => Node.js

上图中的蓝色组件为数据流水线体系需要管理的组件。

数据线1：客户端的Logging SDK与Logging Service进行通信，将用户行为数据以JSON格式上传到服务端，这个服务将这些数据同时写到log storage和Kafka中。
数据线2：业务数据库MySQL中的数据被Sqoop采集到Hive数据湖中，这里包括各种产品的信息以及用户购买产品等业务交易相关的数据。
数据线3：Kafka中的数据经过与实时采集的业务数据的流式分析，可以生成一些用户行为的实时数据，这些数据通过Spark Streaming的程序处理，可以实时更新用户数据画像和产品推荐模型。
数据线4：Flume负责将log storage中的行为数据传输到HDFS中的数据湖。
数据线5：一个Spark Log Parsing程序负责分析用户行为的JSON数据，并将其写到Hive数据湖相应的数据表中。
数据线6：Hive数据湖中的产品数据、交易数据、用户行为数据，经过一系列Hive ETL程序被写入Hive数据仓库中，形成各种用户、产品、销售基础数据。
数据线7：在全局数据仓库明细和汇总事实表的基础上，经过一些统计分析形成各种主题的数据集市数据，这些数据都可以被上层的BI工具使用。
数据线8：Hive数据仓库中的数据经过Spark机器学习程序的计算，生成用户画像和产品推荐模型，存储在HDFS中。然后，一个数据加载程序负责将用户画像和产品推荐模型装载进Redis中，以数据服务的方式为其他应用服务。

在打造这样一个数据流水线之后，每个用户在使用移动应用或网页的时候都可以根据用户画像得到实时的产品推荐，业务人员可以通过看板查看各种实时的运营情况报表。这样的数据流水线已经超出了传统数据仓库的能力范畴。

更重要的是，这种数据流水线可以处理各种数据，将数据处理集成到同一系统中，并将处理后的数据以可复用的数据能力（用户画像的数据服务，用户、产品、销售的主题数据集市，实时行为分析）呈现给上层的业务部门和产品。这种将底层数据处理和上层数据应用隔离的方式，正是数据中台需要的数据应用模式。

数据流水线管理系统面临的挑战

上面介绍了数据流水线中运行的应用类型和调度方式，数据流水线管理系统就是负责运行和管理这些应用的数据中台组件。作为数据中台中负责管理数据处理的核心组件，数据流水线是数据驱动整个架构当中不可或缺的环节。有一种更加激进的说法是，数据流水线是企业数字化运营的关键因素，因为它控制了数据从源头到价值的高效流转，这个流转速率有多高效，数据驱动的齿轮就会转动得有多快。

数据中台需要解决数据孤岛、重复开发的问题，因此其中的数据流水线必须能从机制和工具上来防止这些问题。数据中台需要提供可共享和复用的数据能力，因此其中的数据流水线必须提供相应的机制和工具来支持这样的数据能力。

需要注意的是，数据流水线的建设不可能一蹴而就，在其实施的过程中，会面临非常多的挑战。

（1）复杂且繁多的数据源适配

通过简单的统计实验就可以列出数据源，但如何适配这些数据源并确保对这些数据源的语义的正确理解一般需要大量的沟通工作。那么由谁来管理这些数据源信息？管理数据源信息的人如果离开了怎么办？

（2）数据流水线中数据的真正含义数据的意义是难以了解的，特别是在企业范围内，因为部门与部门之间（特别是在没有统一数据驱动架构的情况下）一般不会共享IT架构和应用程序，数据的管理者几乎不可能了解全局。

（3）独立的数据使用者企业中几乎人人都是独立的数据使用者。不同部门的人员，甚至同一个小组内的不同人，出于不同目的以不同方式使用数据时，都会面临缺乏标准和规范流程的问题。他们经常创建点对点的连接以获取所需的数据，并在数据集上一次又一次地执行相同的转换以便于自己使用。可以想象，个人、团队和部门都重复执行此操作会造成多少计算资源浪费。

（4）数据使用权限和敏感信息处理数据的使用权限和敏感信息也是个挑战。企业中的数据消费者都应该有对应的数据访问权限，并非所有信息（字段）都是可以公开查看的。数据的所有者应该有能力对数据流水线中可能会被使用的数据进行权限限制和分享操控，以及在某些情况下对数据进行脱敏操作，可以作为一个脱敏应用来单独维护。

（5）数据质量和异常检测数据流水线的过程和结果是在两个或两个以上系统中对数据进行汇聚、计算和转移。数据是一种新能源，如何保证这种能源得到准确和高质量的处理是企业面临的一大难题。这个过程不仅要满足数据的治理、监管等要求，还要能够自动捕捉经常出现的异常状况并及时发送告警。

（6）数据模型的转换将数据模型转换为可执行代码的过程可能缓慢且效率低下，这一般发生在实操层面。企业捕获数据是为了使用，使用方式是将所捕获的数据定义为数据模型，然后提供给利益相关者。这个过程会涉及这几个利益相关者：开发团队、数据所有者（负责数据模型的业务分析师）和构建运行时流程的团队。他们之间的关系可能很微妙，各团队通常是临时组建的，各团队的处理流程也缺乏透明度。这个过程通常要求开发人员或团队手动创建可执行代码以在生产中运行，而数据分析师需要依赖这种“不确定的关系”来保障自己的分析成果。事实上，如果数据分析师需要保证数据模型在生产系统中输出正确的最终结果，数据流水线必须对数据的来源和消费有清晰的定义，提供清晰可查的整个处理过程，明确数据源之间的依赖关系，并能够提供各个处理点的控制和治理。

（7）数据流水线的管理管理一条数据流水线比较容易，手动就可以完成，但是企业用户要面对成千上万条数据流水线，无法手动管理。企业用户需要自动化流水线生命周期管理，利用算法来匹配数据处理中的异常状态，通过环境的切分来分开管理用于实验的数据流水线和用于生产的数据流水线，分开管理使用脱敏数据的流水线和使用敏感数据的流水线，并使已经完成实验的数据模型自动一键投放到生产环节中以缩短数据研发周期。

以上内容摘自《云原生数据中台：架构、方法论与实践》，经出版方授权发布。