数据仓库ETL工具全解-第二部分

这篇文章比较全的介绍了传统ETL工具、新型ETL工具、主流计算引擎及流程控制引擎。

1、传统ETL工具包括Datastage、Informatica PowerCenter、Kettle、ODI、Sqoop、DataX、Flume、Canal、DTS、GoldenGate、Maxwell、DSG等等。

2、新型ETL工具包括Streamsets、Waterdrop等。

3、主流计算引擎包括MapReduce、Tez、Spark、Flink、ClickHouse 、Doris等等。

4、流程控制（也称工作流、任务流）是 ETL 重要的组成部分，主要包括Hudson、Airflow、 Azkaban、Oozie、DolphinScheduler。

第二部分

承上，我们接着介绍两种新型 ETL 工具、大数据发展不同阶段产生的六种主要计算引擎、五种流程控制组件。

最后我们简单讨论两个话题：

这么多组件我们该如何抉择？

如何快速将工具引入生产实践？

0x01 新型 ETL 工具

传统 ETL 工具，通常工具化程度很高，不需要编程能力且提供一套可视化的操作界面供广大数据从业者使用，但是随着数据量的激增，跟关系型数据库一样只能纵向扩展去增加单机的性能，这样数据规模的增长跟硬件的成本的增长不是线性的。

而新型 ETL 工具天然适应大数据量的同步集成计算，且支持实时处理，但缺点也很明显，就是工具化可视化程度低，搭建配置难度也比传统 ETL 工具要高，并且需要数据从业者具备一定的程序开发功底而传统数仓环境中的数据人绝大多数是不懂开发的。

但相信随着大数据技术的进一步成熟，终究还会走向低代码和 SQL 化的方向上去的。那时候少部分人负责组件/平台的开发和维护，大部分人使用这些组件去完成业务开发。

StreamSets

Streamsets 是由 Informatica 前首席产品官 Girish Pancha 和 Cloudera 前开发团队负责人 Arvind Prabhakar 于 2014 年创立的公司，总部设在旧金山。

Streamsets 产品是一个开源、可扩展、UI很不错的大数据 ETL 工具，支持包括结构化和半/非结构化数据源，拖拽式的可视化数据流程设计界面。Streamsets 利用管道处理模型（Pipeline）来处理数据流。你可以定义很多 Pipeline，一个 Pipeline 你理解为一个 Job 。

Streamsets 旗下有如下三个产品：

Streamsets data collector(核心产品,开源)：大数据 ETL 工具。

Streamsets data collector Edge(开源):将这个组件安装在物联 等设备上，占用少的内存和 CPU。

StreamSets 开发页面

在管道的创建上分为了三个管道：

data collector pipeline：用户普通 collector 开发。

data collector Edge Pipeline：将开发好的 pipeline 上传到对应 Edge 系统。

microservice pipeline：提供微服务。

管道创建好后，会根据需要去选择对应的组件信息。

主要有以下几类组件：

processor(transform)：数据转化，将抽取来的数据进行过滤，清洗。

destination(load)：数据存储，将数据处理完后存入目标系统或者转入另一个pipeline进行再次处理。

executor：由处理数据组件的事件触发 executor ,执行相应任务。例如：某个组件处理失败，发送邮件通知。

WarterDrop

Waterdrop 项目由 Interesting Lab 开源，是一个非常易用，高性能、支持实时流式和离线批处理的海量数据处理产品，架构于 Apache Spark 和 Apache Flink 之上。

Spark 固然是一个优秀的分布式数据处理工具，但是直接使用 Spark 开发是个不小的工程，需要一定的 Spark 基础以及使用经验才能开发出稳定高效的 Spark 代码。除此之外，项目的编译、打包、部署以及测试都比较繁琐，会带来不少的时间成本和学习成本。

除了开发方面的问题，数据处理时可能还会遇到以下不可逃避的麻烦：

数据丢失与重复

任务堆积与延迟

吞吐量低

应用到生产环境周期长

缺少应用运行状态监控

Waterdrop 诞生的目的就是为了让 Spark 的使用更简单，更高效，并将业界使用 Spark 的优质经验固化到 Waterdrop 这个产品中，明显减少学习成本，加快分布式数据处理能力在生产环境落地。

gitHub 地址：

https://github.com/InterestingLab/waterdrop

软件包地址：

https://github.com/InterestingLab/waterdrop/releases

文档地址：

https://interestinglab.github.io/waterdrop-docs/

项目负责人

Gary(微信: garyelephant) , RickyHuo(微信: chodomatte1994)

Waterdrop 架构

Waterdrop 使用场景：

海量数据 ETL

海量数据聚合

多源数据处理

Waterdrop 的特性：

简单易用，灵活配置，无需开发；可运行在单机、Spark Standalone 集群、Yarn 集群、Mesos 集群之上。

实时流式处理, 高性能, 海量数据处理能力。

模块化和插件化，易于扩展。Waterdrop 的用户可根据实际的需要来扩展需要的插件，支持 Java/Scala 实现的 Input、Filter、Output 插件。

支持利用 SQL 做数据处理和聚合。

方便的应用运行状态监控。

0x02 计算引擎

上边两种新型 ETL 工具的出现简化了数据处理操作，同步、集成、计算可以统一在一个工具内完成且有不错的界面可以使用，但对于一些更加复杂灵活的场景不一定能够支撑。

大数据场景下计算引擎还是主流，并且衍生出了许许多多的组件。我们这里无法一一列举，就分别挑选不同时期被广泛使用的几个做介绍吧。

MapReduce

MapReduce 将复杂的、运行于大规模集群上的并行计算过程高度地抽象到了两个函数：Map 和 Reduce。它采用“分而治之”策略，一个存储在分布式文件系统中的大规模数据集，会被切分成许多独立的分片（split），这些分片可以被多个 Map 任务并行处理。

不同的 Map 任务之间不会进行通信

不同的 Reduce 任务之间也不会发生任何信息交换

用户不能显式地从一台机器向另一台机器发送消息

所有的数据交换都是通过 MapReduce 框架自身去实现的

MapReduc 是 Hadoop 组件里的计算框架模型，另外还有分布式存储组件 HDFS、资源管理组件 Yarn。一开始计算和资源管理是耦合在一起的，Hadoop 2.0 才将其拆分开，这大大增加 Hadoop 使用的灵活性。

MapReduce 的缺陷：

第一，MapReduce 模型的抽象层次低，大量的底层逻辑都需要开发者手工完成。

第二，只提供 Map 和 Reduce 两个操作。很多现实的数据处理场景并不适合用这个模型来描述。实现复杂的操作很有技巧性，也会让整个工程变得庞大以及难以维护。

第三，在 Hadoop 中，每一个 Job 的计算结果都会存储在 HDFS 文件存储系统中，所以每一步计算都要进行硬盘的读取和写入，大大增加了系统的延迟。

Tez

Hadoop（MapReduce/Yarn、HDFS） 虽然能处理海量数据、水平扩展，但使用难度很大，而 Hive 的出现恰好解决这个问题，这使得 Hive 被迅速的推广普及成为大数据时代数据仓库组件的代名词（存储使用 hdfs，计算使用 MapReduce。Hive 只是一个壳根据自身维护的表字段跟底层存储之间映射关系 Hcatlog，对用户提交的 SQL 进行解析、优化，然后调用底层配置的执行引擎对底层数据进行计算）。

为解决 Hive 执行性能太差的问题，在计算引擎方面出现了 Tez，数据存储方面出现了 ORC（一种专门针对 Hive 开发的列式存储压缩格式。当然 HDFS 本身也有一些存储压缩格式，另外还有一个比较流行的列示存储格式 Parquet）这也使得 Hive 的性能有了质的提升。

MapReduce 每一步都会落磁盘，这大大影响力执行效率

Tez 是 Apache 开源的支持 DAG （有向无环图，Directed Acyclic Graph）作业的计算框架。它把 Ｍap/Reduce 过程拆分成若干个子过程，同时可以把多个 Ｍap/Reduce 任务组合成一个较大的 DAG 任务，减少了 Ｍap/Reduce 之间的文件存储。同时合理组合其子过程，也可以减少任务的运行时间。加上内存计算 Tez 的计算性能实际上跟 Spark 不相上下。

Tez 直接源于 MapReduce 框架，核心思想是将 Map 和 Reduce 两个操作进一步拆分，即 Map 被拆分成Input、Processor、Sort、Merge和Output， Reduce 被拆分成 Input、Shuffle、Sort、Merge、Processor 和 Output 等，这样，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的 DAG 作业。

Spark 、Flink

Apache Spark 是一个围绕速度、易用性和复杂分析构建的大数据处理框架，用于大规模数据处理的统一分析引擎，致力于一个组件满足大数据处理和分析的所有计算场景。

Spark 是当今最流行的分布式大规模数据处理引擎，被广泛应用在各类大数据处理场景。2009 年，美国加州大学伯克利分校的 AMP 实验室开发了 Spark。2013 年，Spark 成为 Apache 软件基金会旗下的孵化项目。而现在，Spark 已经成为了该基金会管理的项目中最活跃的一个。

SparkUI Stage 页面

Spark 应用场景：

离线计算：使用算子或 SQL 执行大规模批处理，对标 MapReduce、Hive。同时提供了对各种数据源（文件、各种数据库、HDFS 等）的读写支持。

实时处理：以一种微批的方式，使用各种窗口函数对流式数据进行实时计算。主要实现在这两部分：Spark Streaming、Structure Streaming（Spark 2.3 版本推出）。

MLlib：一个常用机器学习算法库，算法被实现为对 RDD 的 Spark 操作。这个库包含可扩展的学习算法，比如分类、回归等需要对大量数据集进行迭代的操作。

GraphX：控制图、并行图操作和计算的一组算法和工具的集合。GraphX 扩展了 RDD API，包含控制图、创建子图、访问路径上所有顶点的操作。

Spark 数据结构：

RDD：弹性分布式数据集，它代表一个可以被分区（partition）的只读数据集，它内部可以有很多分区，每个分区又有大量的数据记录（record）。RDD 表示已被分区、不可变的，并能够被并行操作的数据集合。

DataFrame：可以被看作是一种特殊的 DataSet 可以被当作 DataSet[Row] 来处理，我们必须要通过解析才能获取各列的值。

DataSet：数据集的意思，它是 Spark 1.6 新引入的接口。就像关系型数据库中的表一样，DataSet 提供数据表的 schema 信息比如列名列数据类型。

Spark 数据结构发展历史：

RDD API 在第一代 Spark 中就存在，是整个 Spark 框架的基石。

接下来，为了方便熟悉关系型数据库和 SQL 的开发人员使用，在 RDD 的基础上，Spark 创建了 DataFrame API。依靠它，我们可以方便地对数据的列进行操作。

DataSet 最早被加入 Spark SQL 是在 Spark 1.6，它在 DataFrame 的基础上添加了对数据的每一列的类型的限制。

在Spark 2.0 中，DataFrame 和 DataSet 被统一。DataFrame 作为 DataSet[Row]存在。在弱类型的语言，如 Python 中，DataFrame API 依然存在，但是在 Java 中，DataFrame API 已经不复存在了。

---

Flink 起源于 2008 年柏林理工大学一个研究性项目， 在 2014 年被 Apache 孵化器所接受，然后迅速地成为了 ASF（Apache Software Foundation）的顶级项目之一。德国人对 Flink 的推广力度跟美国人对 Spark 的推广差的比较远，直到 2019 年阿里下场才使得 Flink 在国内得到广泛应用，并且以很高的频率进行版本迭代。

Flink 组件栈

基于流执行引擎，Flink 提供了诸多更高抽象层的 API 以便用户编写分布式任务：

DataSet API：对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用 Flink 提供的各种操作符对分布式数据集进行处理，支持 Java、Scala 和 Python。

DataStream API：对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持 Java 和 Scala。

Table API：对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类 SQL 的 DSL 对关系表进行各种查询操作，支持 Java 和 Scala。

Flink ML：Flink 的机器学习库，提供了机器学习 Pipelines API 并实现了多种机器学习算法。

Gelly：Flink 的图计算库，提供了图计算的相关 API 及多种图计算算法实现。

---

如上所述，Flink 等于说是把 Spark 的功能重新实现了一遍，区别在于 Spark 是由批入流 Flink 是由流入批。由于起步较晚，Flink 能够大量吸收 Hadoop、Spark 的优秀经验，凭借更高层次的抽象、更简洁的调用方式、高的吞吐、更少的资源占用，在实时计算、实时数仓等场景迅速超越了 Spark。但 Flink 想要完全超越 Spark 还有很长的路要走，比如对 SQL 的支持、批流一体的实现、机器学习、图计算等等。

对于数据开发者来说，Spark 比 MapReduce 支持的场景更广使用起来也容易的多，Flink 相比 Spark 同样更易用了。所以往后大数据开发的门槛将会越来越低：完全 SQL 化、低代码甚至会像传统 ETL 工具一样无代码。大数据从业者未来的路该怎么走？这是个值得思考的问题。

ClickHouse 、Doris

ClickHouse 是 Yandex 在 20160615 开源的一个数据分析的 MPP 数据库。并且在 18 年初成立了 ClickHouse 中文社区，应该是易观负责运营的。

ClickHouse 实质上是一个数据库。为了获得极致的性能，ClickHouse 在计算层做了非常细致的工作，竭尽所能榨干硬件能力，提升查询速度。它实现了单机多核并行、分布式计算、向量化执行与 SIMD 指令、代码生成等多种重要技术。普通大数据集群，单机十几亿数据检索秒出。因此许多即席查询场景 ClickHouse 被广泛使用。

---

Apache Doris 是一个现代化的 MPP 分析型数据库产品，百度开源并贡献给 Apache 社区。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris 的分布式架构非常简洁，易于运维，并且可以支持 10PB 以上的超大数据集。

Apache Doris 可以满足多种数据分析需求，例如固定历史 表，实时数据分析，交互式数据分析和探索式数据分析等。令您的数据分析工作更加简单高效！

---

ClickHouse 确实是一个非常优秀的产品。但为了获得查询时的高性能我们放弃了一些东西：

ClickHouse 过度依赖大宽表。

ClickHouse 难以支持高并发的业务场景。

并不完全能够支持标准 SQL ，UDF 也是最近才支持的。

ClickHouse 集群的运维复杂度也一定曾让您感到过头疼。

Doris 的诞生试图去解决 ClickHouse 的这些问题，让我们拭目以待吧。

0x03 流程控制组件

流程控制（也称工作流、任务流）是 ETL 重要的组成部分，通常是以 DAG 的方式配置，每次调用都会沿着有向无环图从前往后依次执行直至最后一个任务完成。

流程控制可以在 ETL 工具内配置，也可以在调度系统配置。传统 ETL 工具基本上都是单机版的，如果 ETL 的任务节点分布在多个服务器上，整体的流程依赖就会变的复杂起来（跨服务器的调度