☞ 新型 ETL 工具 [ StreamSets、WarterDrop ]
☞ 計算引擎 [ MapReduce、Tez、Spark、Flink、ClickHouse、Doris ]
☞ 流程控制工具 [ Hudson、Airflow、Azkaban、Oozie、 DolphinScheduler]
0x00 前言上篇，我們介紹了五種傳統 ETL 工具和八種數據同步集成工具。
數據倉庫詳細介紹（五.ETL）工具篇上
本篇，我們接著介紹兩種新型 ETL 工具、大數據發展不同階段產生的六種主要計算引擎、五種流程控制組件。
最後我們簡單討論兩個話題：
這麼多組件我們該如何抉擇？
如何快速將工具引入生產實踐？
0x01 新型 ETL 工具
傳統 ETL 工具，通常工具化程度很高，不需要編程能力且提供一套可視化的操作界面供廣大數據從業者使用，但是隨著數據量的激增，跟關係型資料庫一樣只能縱向擴展去增加單機的性能，這樣數據規模的增長跟硬體的成本的增長不是線性的。而新型 ETL 工具天然適應大數據量的同步集成計算，且支持實時處理，但缺點也很明顯，就是工具化可視化程度低，搭建配置難度也比傳統 ETL 工具要高，並且需要數據從業者具備一定的程序開發功底而傳統數倉環境中的數據人絕大多數是不懂開發的。
但相信隨著大數據技術的進一步成熟，終究還會走向低代碼和 SQL 化的方向上去的。那時候少部分人負責組件/平臺的開發和維護，大部分人使用這些組件去完成業務開發。
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 ,執行相應任務。例如：某個組件處理失敗，發送郵件通知。
WarterDropWaterdrop 項目由 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 使用場景：
Waterdrop 的特性：
0x02 計算引擎上邊兩種新型 ETL 工具的出現簡化了數據處理操作，同步、集成、計算可以統一在一個工具內完成且有不錯的界面可以使用，但對於一些更加複雜靈活的場景不一定能夠支撐。大數據場景下計算引擎還是主流，並且衍生出了許許多多的組件。我們這裡無法一一列舉，就分別挑選不同時期被廣泛使用的幾個做介紹吧。MapReduceMapReduce 將複雜的、運行於大規模集群上的並行計算過程高度地抽象到了兩個函數：Map 和 Reduce。它採用「分而治之」策略，一個存儲在分布式文件系統中的大規模數據集，會被切分成許多獨立的分片（split），這些分片可以被多個 Map 任務並行處理。
MapReduce 工作流程，來源於網絡
不同的 Map 任務之間不會進行通信
不同的 Reduce 任務之間也不會發生任何信息交換
用戶不能顯式地從一臺機器向另一臺機器發送消息
所有的數據交換都是通過 MapReduce 框架自身去實現的
MapReduc 是 Hadoop 組件裡的計算框架模型，另外還有分布式存儲組件 HDFS、資源管理組件 Yarn。一開始計算和資源管理是耦合在一起的，Hadoop 2.0 才將其拆分開，這大大增加 Hadoop 使用的靈活性。
MapReduce 的缺陷：
第一，MapReduce 模型的抽象層次低，大量的底層邏輯都需要開發者手工完成。
第二，只提供 Map 和 Reduce 兩個操作。很多現實的數據處理場景並不適合用這個模型來描述。實現複雜的操作很有技巧性，也會讓整個工程變得龐大以及難以維護。
第三，在 Hadoop 中，每一個 Job 的計算結果都會存儲在 HDFS 文件存儲系統中，所以每一步計算都要進行硬碟的讀取和寫入，大大增加了系統的延遲。
TezHadoop（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 、FlinkApache 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 信息比如列名列數據類型。
RDD、DataFrame、DataSet 對比
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 、DorisClickHouse 是 Yandex 在 20160615 開源的一個數據分析的 MPP 資料庫。並且在 18 年初成立了 ClickHouse 中文社區，應該是易觀負責運營的。
ClickHouse 實質上是一個資料庫。為了獲得極致的性能，ClickHouse 在計算層做了非常細緻的工作，竭盡所能榨乾硬體能力，提升查詢速度。它實現了單機多核並行、分布式計算、向量化執行與 SIMD 指令、代碼生成等多種重要技術。普通大數據集群，單機十幾億數據檢索秒出。因此許多即席查詢場景 ClickHouse 被廣泛使用。
Apache Doris 是一個現代化的 MPP 分析型資料庫產品，百度開源並貢獻給 Apache 社區。僅需亞秒級響應時間即可獲得查詢結果，有效地支持實時數據分析。Apache Doris 的分布式架構非常簡潔，易於運維，並且可以支持 10PB 以上的超大數據集。
Apache Doris 可以滿足多種數據分析需求，例如固定歷史報表，實時數據分析，交互式數據分析和探索式數據分析等。令您的數據分析工作更加簡單高效！
ClickHouse 確實是一個非常優秀的產品。但為了獲得查詢時的高性能我們放棄了一些東西：
Doris 的誕生試圖去解決 ClickHouse 的這些問題，讓我們拭目以待吧。
0x03 流程控制組件流程控制（也稱工作流、任務流）是 ETL 重要的組成部分，通常是以 DAG 的方式配置，每次調用都會沿著有向無環圖從前往後依次執行直至最後一個任務完成。流程控制可以在 ETL 工具內配置，也可以在調度系統配置。傳統 ETL 工具基本上都是單機版的，如果 ETL 的任務節點分布在多個伺服器上，整體的流程依賴就會變的複雜起來（跨伺服器的調度無法解決，就只剩下兩種方法了：預估前置依賴完成時間、監控前置依賴運行狀態比如將運行狀態寫入資料庫等），這時候使用調度工具裡的流程控制功能就是最優解。
HudsonHudson 是一個可擴展的持續集成引擎，是 SUN 公司時期就有的 CI 工具，後來因為 ORACLE 收購 SUN 之後的商標之爭，創始人 KK 搞了新的分支叫 Jenkins 。今天的Hudson還在由ORACLE 持續維護，但風頭已經遠不如社區以及CloudBees 驅動的 Jenkins。
主要用於：
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 是一個可編程，調度和監控的工作流平臺，基於有向無環圖(DAG)，Airflow 可以定義一組有依賴的任務，按照依賴依次執行。Airflow 提供了豐富的命令行工具用於系統管控，而其 web 管理界面同樣也可以方便的管控調度任務，並且對任務運行狀態進行實時監控，方便了系統的運維和管理。
上圖以及以下兩段文字來源於公眾號：數據社
主要有如下幾種組件構成：
具體執行流程：
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 還有一定的市場。
DolphinSchedulerApache 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 工具，我們如何能夠在兩周內達到生產應用的水平呢？
首先我們需要搞明白我們需要 ETL 系統做什麼？
正常來說，所有 ETL 工具都是能夠支持以上功能的，我們需要找到它們（否則就得儘快尋找補救方案），然後就能正常的進行 ETL 開發了。我們需要使用新的工具先讓系統穩定、準確的跑起來，同時能夠提供有效的自動化運行監控，性能優化是下一步該做的事情。
好了，ETL 工具篇分上下兩部分，合計一萬五千多字，到這裡就介紹完了。
下篇的 ETL 實踐經驗總結我們下周見。感興趣的話歡迎關注下方公眾號。
擴展閱讀：
數據倉庫詳細介紹（一.概述）
數據倉庫詳細介紹（二.架構）
數據倉庫詳細介紹（三.規範）心法篇
數據倉庫詳細介紹（三.規範）招式篇
數據倉庫詳細介紹（四.建模）理論篇
數據倉庫詳細介紹（四.建模）實踐篇
數據倉庫詳細介紹（五.ETL）方法篇
數據倉庫詳細介紹（五.ETL）工具篇上
數據倉庫實踐-拉鍊表設計
數據倉庫漫談-前世今生
用戶畫像-標籤體系
留個微信，大家不妨交個朋友，共同交流。同時，歡迎關注、分享、轉載。