etl介绍与etl工具比较，数据仓库ETL工具全解-第二部分

关于【etl介绍与etl工具比较】，今天小编给您分享一下，如果对您有所帮助别忘了关注本站哦。

• 内容导航：
• 1、etl介绍与etl工具比较：数据仓库ETL工具全解-第二部分
• 2、etl介绍与etl工具比较，ETL系统相关技术和注意事项

1、etl介绍与etl工具比较：数据仓库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。

如果要从0到1学习和引入，作者建议直接上最好的，比如 ETL 工具传统的那些就没必要学了，直接学 StreamSets 或者 WaterDrop 即可；实时计算直接学 Flink 即可不用看 Spark 了；众多的 OLAP 我们直接学 ClickHouse 或者 Doris 即可其它的也不用看了；调度嘛直接 DS 就好了。

第二部分

承上，我们接着介绍两种新型 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 control hub(收费项目)：可以将 collector 编辑好的 pipeline 放入 control hub 进行管理，可实现定时调度、管理和 pipeline 拓扑。

StreamSets 开发页面

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

• data collector pipeline：用户普通 collector 开发。
• data collector Edge Pipeline：将开发好的 pipeline 上传到对应 Edge 系统。
• microservice pipeline：提供微服务。

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

主要有以下几类组件：

• origins (extract)：数据来源，数据从不同的数据源抽取。（一个 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 任务并行处理。

MapReduce 工作流程，来源于网络

不同的 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 的性能有了质的提升。

MR 与 Tez 的比较，来源于网络

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 的任务节点分布在多个服务器上，整体的流程依赖就会变的复杂起来（跨服务器的调度无法解决，就只剩下两种方法了：预估前置依赖完成时间、监控前置依赖运行状态比如将运行状态写入数据库等），这时候使用调度工具里的流程控制功能就是最优解。

Hudson

Hudson 是一个可扩展的持续集成引擎，是 SUN 公司时期就有的 CI 工具，后来因为 ORACLE 收购 SUN 之后的商标之争，创始人 KK 搞了新的分支叫 Jenkins 。今天的Hudson还在由ORACLE 持续维护，但风头已经远不如社区以及CloudBees 驱动的 Jenkins。

主要用于：

• 持续、自动地构建/测试软件项目，如 CruiseControl 与 DamageControl。
• 监控一些定时执行的任务。

Hudson 操作界面

Hudson 拥有的特性包括：

• 易于安装：只要把 hudson.war 部署到 servlet 容器，不需要数据库支持。
• 易于配置：所有配置都是通过其提供的 web 界面实现。
• 集成 RSS/E-mail/IM：通过 RSS 发布构建结果或当构建失败时通过 e-mail 实时通知。
• 生成 JUnit/TestNG 测试报告。
• 分布式构建支持，Hudson 能够让多台计算机一起构建/测试。
• 文件识别：Hudson 能够跟踪哪次构建生成哪些 jar，哪次构建使用哪个版本的 jar 等。
• 插件支持：Hudson 可以通过插件扩展，你可以开发适合自己团队使用的工具。

Hudson 是我们早期数仓项目中使用的一个调度工具，当然 Hudson 还有其它的一些功能，但我们用到的仅仅是调度。由于 ETL 系统整体的复杂性，源端数据汇总集成、数仓分层计算、数据推送到外部系统，我们分别部署在了三台服务器上，这时候 Hudson 就起到了跨服务器调度依赖控制的作用。

Airflow、 Azkaban、Oozie

Airflow 是一个可编程，调度和监控的工作流平台，基于有向无环图(DAG)，Airflow 可以定义一组有依赖的任务，按照依赖依次执行。Airflow 提供了丰富的命令行工具用于系统管控，而其 web 管理界面同样也可以方便的管控调度任务，并且对任务运行状态进行实时监控，方便了系统的运维和管理。

上图以及以下两段文字来源于公众号：数据社

主要有如下几种组件构成：

• web server: 主要包括工作流配置，监控，管理等操作。
• scheduler: 工作流调度进程，触发工作流执行，状态更新等操作。
• 消息队列：存放任务执行命令和任务执行状态报告。
• worker: 执行任务和汇报状态。
• mysql: 存放工作流，任务元数据信息。

具体执行流程：

• scheduler 扫描 dag 文件存入数据库，判断是否触发执行。
• 到达触发执行时间的 dag ,生成 dag_run，task_instance 存入数据库。
• 发送执行任务命令到消息队列。
• worker 从队列获取任务执行命令执行任务。
• worker 汇报任务执行状态到消息队列。
• schduler 获取任务执行状态，并做下一步操作。
• schduler 根据状态更新数据库。

Azkaban 是由 Linkedin 开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。Azkaban 定义了一种 KV 文件格式来建立任务之间的依赖关系，并提供一个易于使用的 web 用户界面维护和跟踪你的工作流。

Azkaban 操作界面

Oozie 起源于雅虎，主要用于管理与组织 Hadoop 工作流。Oozie 的工作流必须是一个有向无环图，实际上 Oozie 就相当于 Hadoop 的一个客户端，当用户需要执行多个关联的 MR 任务时，只需要将 MR 执行顺序写入 workflow.xml，然后使用 Oozie 提交本次任务，Oozie 会托管此任务流。

以上三个组件都是在大数据环境下使用的调度工具，Oozie 属于非常早期的调度系统了并且深度服务于 Hadoop 生态目前使用的很少了，Azkaban 目前也使用的不多，Airflow 还有一定的市场。

DolphinScheduler

Apache DolphinScheduler 是一个分布式、去中心化、易扩展的可视化 DAG 工作流任务调度系统，其致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。

DolphinScheduler 于 2019 年 8 月 29 日 进入 Apache 孵化器，于 2021 年 4 月 9 日成为 Apache 顶级项目。

DolphinScheduler 操作界面

DolphinScheduler 提供了许多易于使用的功能，可加快数据 ETL 工作开发流程的效率。其主要特点如下：

• 通过拖拽以 DAG 图的方式将 Task 按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态；
• 支持丰富的任务类型；
• 支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警、从指定节点恢复失败、Kill 任务等操作；
• 支持工作流全局参数及节点自定义参数设置；
• 支持集群 HA，通过 Zookeeper 实现 Master 集群和 Worker 集群去中心化；
• 支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计；
• 支持补数，并行或串行回填数据。

0x04 总结

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

写到这里，计划中的 ETL 工具以及类 ETL 组件已经全部介绍完了，但我只是挑了不同时期比较流行的很少一部分，刚数了下有 26 个。

工具组件这么多，做为技术人肯定是学不完的，经常看到一些简历罗列了一二十个，大而全哪哪都不精这样的人市场上是没啥竞争力的。所以我们必须聚焦，在数据处理的全流程，每一类型选取其中一种组件深入学习并努力在生产实践中运用。在特定的场景，多种工具其实实现的功能大体是类似的，无非是后起的在性能、稳定性、易用性上会比早出现的好很多。

• 如果你已经在一家公司做数据了，就先看下公司的技术栈。如果市面上还是比较流行，恭喜你努力的去学精学透，从生产使用技巧到底层运行原理去深挖，其它的类似组件简单了解就行。如果公司使用的技术不好用或者过于陈旧就努力推动促使公司更换技术栈吧。

• 如果你还不是做数据的，或者以后想转数据，或者公司的技术栈陈旧又没法更换，这就需要自我学习了。我们需要挑选不同类型下最流行或者最优秀的那个深入学习，一通百通。比如 ETL 工具传统的那些就没必要学了直接学 StreamSets 或者 WaterDrop 即可；实时计算直接学 Flink 即可不用看 Spark 了；众多的 OLAP 我们直接学 ClickHouse 或者 Doris 即可其它的也不用看了；调度嘛直接 DS 就好了。求职时候尝试把你最最擅长的那一两个组件表现出来反而更容易获得面试官的认可。

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

当我们选好一个新的组件后，从入门到精通大致需要以下三个过程：

• 第一步，先用起来，并且对组件有基本的认知。我们需要先想明白我们想让该组件帮我们解决什么问题然后将问题分类细化逐个解决，拿最小集合快速的跑通全流程。
• 第二步，学习组件原理特性，将更多的特性运用到业务中去解决更多的实际问题，同时对现有流程进行调优。
• 第三步，学习源码对组件本身进行优化改造，用于解决更多的现实问题，如果有可能就贡献给社区。当然走到这一步的还是少数人，这是平台开发的事，数据开发很少有这样的机会因为投入产出比很差。

最后，我们举个例子吧：一个项目需要使用一个之前没用过的 ETL 工具，我们如何能够在两周内达到生产应用的水平呢？

首先我们需要搞明白我们需要 ETL 系统做什么？

• 数据源连接，连接上之后我们能够抽取或者加载数据。
• 文件的导入导出功能。
• 源端库数据的全量/增量抽取。
• 目标库数据的插入/更新/删除。
• 流程控制：任务流动方向的控制、串行/并行控制、任务成功/失败后的处理、必要的条件判断并能依据判断结果执行不同的操作。
• 参数传递与接收：多层/多级任务，参数能够从最外层往下一层或者从最上游往下游传递，每个任务节点要能通过变量接收到上层或者上游参数。
• ETL 执行过程监控，方便后续自动化监控和告警。
• ETL 运行出错时候的重试/补数。

正常来说，所有 ETL 工具都是能够支持以上功能的，我们需要找到它们（否则就得尽快寻找补救方案），然后就能正常的进行 ETL 开发了。我们需要使用新的工具先让系统稳定、准确的跑起来，同时能够提供有效的自动化运行监控，性能优化是下一步该做的事情。

2、etl介绍与etl工具比较，ETL系统相关技术和注意事项

需求综合

需求综合的含义是：收集并且理解所有已知的将会影响ETL系统的需求、现实和约束等。需求的列表可能会很长，但在开始ETL系统开发前，都已经收集到了表中。

需求一：业务需求

用户的信息需求。用户用于制定明智的商业抉择所需要的信息内容。因为商业需求直接驱动对数据源的选择以及选择的数据源在ETL系统中转换的结果。

在项目支持业务需求定义期间，必须维护一个揭示关键性能指标的列表，以及业务用户需要研究某个关键指标为什么发生变化时，所需要的下钻和跨钻目标。

需求二：合规性

合规性

列出所有数据以及最终报表主题需要遵守的法律限制。列出这些数据输入和数据转换的步骤，需要维护“监管链”，现实并且证明最终报表是来自发布的数据源的原始数据。

对于合规性，我工作还没有这方面严格的要求。

需求三：数据质量

数据质量

需要将那些已经知道的不中意的数据元素记录下来，是否与源系统达成共识以便在获取数据之前进行更正。

列举数据分析期间发现的那些需要在ETL过程中持续监控和标记的数据元素。

需求四：安全性

安全性

1，对于大多数DW/BI小组来说，安全通畅处于时候考虑的位置且被视为负担而不受欢迎。

2，应该将合规性列表扩展，使其包含熟知的安全和隐私需求。

3，数据应该被限制发送给那些需要知道的那些人。

4，物理备份也需要做安全性的检查。

5，在需求综合期间，DW/BI小组应该寻求高管层的明确指示，指明DW/BI 系统的那些方面应该运用额外的安全措施。如果没有明确指示，也没有安全管理员参与的时候，使用最小扩散范围。

需求五：数据集成

数据集成

1，对于数据集成来说，我们的最终目标是做出企业的全景视图。

2，全面的数据集成很难实现，除非企业具有全面的、集中式的主数据管理系统（Master Data Management ，MDM）系统，即使有的话，也仍然可能会有一些重要的数据并没有进入到主 MDM 中。

3，一致性维度意味着跨不同的数据库系统建立公共维度属性。一致性意味着对公共业务度量达成一致，公共业务度量包括跨不同数据库的关键性能指标KPI，只有这样，才能使用这些数据通过计算差异和比率开展数学比较工作。

4，应当充分利用业务过程的总线矩阵建立一致性维度的优先列表，对每个总线矩阵的行进行标注，知明参与到集成过程中的业务是否有明确的执行需求。

需求六：数据延迟

数据延迟

1，标注每个需求，明确业务团体是否了解与他们特定选择相关的数据质量的权衡。

2，数据延迟需求对 ETL 架构具有较大的影响。高效的处理算法、并行化以及强大的硬件系统可以加快传统的面向批处理的数据流，但是在有些情况下，如果数据延迟需求非常紧迫，ETL 系统的架构必须从批处理方式转换为微批处理方式或者面向流处理的方式。

需求七：归档与世系

归档与世系

1，每个数据仓库也都需要有以往数据的各种副本，要么与新数据比较以便建立发生变化的记录，要么重新处理。

2，建议在每个ETL流水线的主要活动发生后暂存数据（将其写入磁盘）：在数据被获取、清洗和一致化、发布后 暂存数据。

3，那么什么时候将暂存转入归档，我喜欢将所有暂存数据归档。除非有专门的定义明确认为特定的数据集合将来不在需要。

4，每个暂存/归档数据集合都应该包含描述来源和建立数据的处理步骤的元数据。按照某些合规性需求的需求，对该世系的跟踪是明确需要的，应该成为每个归档环境的一部分内容。

5，应当记录数据源和归档的中间数据步骤以及保留政策、安全和隐私方面的约束。

需求八：BI发布接口

1，数据的内容和结构能够是BI引用简单而快速。以模糊的方式将数据推到BI应用是不负责任的表现，将会增加应用的复杂性，减缓查询或报表的构建，不必要地增加了商业用户使用数据的复杂性。

2，列出BI工具需要的所有OLAP多维数据库和特定的数据库结构，列出所有您已经打算建立用于支持BI性能的已知的索引和聚类。

需求九：可用的技能

1，查清所在部门的操作系统，ETL工具，脚本语言，编程语言，SQL，DBMS以及OLAP技能，这样可以理解如何暴露出所缺乏的技能。

2，列出需要支持当前系统以及未来可能有的系统的那些技能。

需求十：传统的许可证书

1，目前我们大多使用的是开源软件。还没有遇到许可证书的问题。

2，列出现有操作系统 的许可证书，无论他们是独家使用授权还是仅仅被建议使用的情况。

3，当打算更换目前的正在使用的许可证书时候，需要做出充分的准备。

数据仓库-读书笔记一

数据仓库-DW/BI架构对比-读书笔记二

数据仓库-事实表/维度表技术-读书笔记三

数据仓库-维度处理-读书笔记（四）

数据仓库-高级事实表技术-读书笔记五

数据仓库-高级维度表技术-读书笔记六

数据仓库-零售业务举例维度模型设计4步骤-读书笔记（七）

数据仓库-零售业务举例维度表设计细节-读书笔记（八）

数据仓库-零售业务举例如何提高仓库扩展能力-读书笔记（九）

数据平台建设整体思路阐述和总结

数据仓库-零售业务中库存如何设计-读书笔记（十）

数据仓库中如何使用缓慢变化维技术

本文关键词：etl主流工具，etl用到的技术，etl常用的三种工具介绍，etl工具软件，etl工具对比。这就是关于《etl介绍与etl工具比较，数据仓库ETL工具全解-第二部分》的所有内容，希望对您能有所帮助！