批處理ETL已死，Kafka纔是數據處理的將來？

最近的一些數據發展趨勢推進了傳統的批處理抽取 - 轉換 - 加載（ETL）架構發生了巨大的變化：數據平臺要在整個企業範圍內運行；數據源的類型變得更多；流數據獲得了廣泛性增加。 在 QCon 舊金山 2016 會議上，Neha Narkhede 作了「ETL 已死，而實時流長存」的演講，並討論了企業級數據處理領域所面臨的挑戰。該演講的核心前提是開源的 Apache Kafka 流處理平臺可以提供靈活且統一的框架，支持數據轉換和處理的現代需求。

Narkhede 是 Confluent 的聯合創始人和 CTO，在演講中，他首先闡述了在過去的十年間，數據和數據系統的重要變化。該領域的傳統功能包括提供聯機事務處理（online transaction processing，OLTP）的操做性數據庫以及提供在線分析處理（online analytical processing，OLAP）的關係型數據倉庫。來自各類操做性數據庫的數據會以批處理的方式加載到數據倉庫的主模式中，批處理運行的週期多是天天一次或兩次。這種數據集成過程一般稱爲抽取 - 轉換 - 加載（extract-transform-load，ETL）。

最近的一些數據發展趨勢推進傳統的 ETL 架構發生了巨大的變化：

單服務器的數據庫正在被各類分佈式數據平臺所取代，這種平臺在整個公司範圍內運行；

除了事務性數據以外，如今有了類型更多的數據源，好比日誌、傳感器、指標數據等；

流數據獲得了廣泛性的增加，就業務需求而言，須要有一種比每日批處理更快的方案。

這些趨勢所形成的後果就是傳統的數據集成方式最終看起來像一團亂麻，好比組合自定義的轉換腳本、使用企業級中間件如企業服務總線（ESB）和消息隊列（MQ）以及像 Hadoop 這樣的批處理技術。

在探討現代流處理技術如何緩解這些問題以前，Narkhede 簡要回顧了一下數據集成的歷史。在上世紀 90 年代的零售行業中，業務獲得了一些新形式的數據，因此對購買者行爲趨勢進行分析的需求迫切增加。

存儲在 OLTP 數據庫中的操做性數據必需要進行抽取、轉換爲目標倉庫模式，而後加載到中心數據倉庫中。這項技術在過去二十年間不斷成熟，可是數據倉庫中的數據覆蓋度依然相對很是低，這主要歸因於 ETL 的以下缺點：

須要一個全局的模式；

數據的清洗和管理須要手工操做而且易於出錯；

ETL 的操做成本很高：它一般很慢，而且是時間和資源密集型的；

ETL 所構建的範圍很是有限，只關注於以批處理的方式鏈接數據庫和數據倉庫。

在實時 ETL 方面，早期採用的方式是企業應用集成（Enterprise application integration，EAI），並使用 ESB 和 MQ 實現數據集成。儘管這能夠說是有效的實時處理，但這些技術一般很難普遍擴展。這給傳統的數據集成帶來了兩難的選擇：實時但不可擴展，或者可擴展但採用的是批處理方案。

Narkhede 指出現代流處理對數據集成有了新的需求：

可以處理大量且多樣性的數據；

平臺必需要從底層就支持實時處理，這會促進向以事件爲中心的根本轉變；

必須使用向前兼容的數據架構，必須可以支持添加新的應用，這些新的應用可能會以不一樣的方式來處理相同的數據。

這些需求推進一個統一數據集成平臺的出現，而不是一系列專門定製的工具。這個平臺必須擁抱現代架構和基礎設施的基本理念、可以容錯、可以並行、支持多種投遞語義、提供有效的運維和監控而且容許進行模式管理。Apache Kafka 是七年前由 LinkedIn 開發的，它就是這樣的一個開源流平臺，可以做爲組織中數據的中樞神經系統來運行，方式以下：

做爲應用的實時、可擴展消息總線，不須要 EAI；

爲全部的消息處理目的地提供現實情況來源的管道；

做爲有狀態流處理微服務的基礎構建塊。

Apache Kafka 在 LinkedIn 目前天天處理 14 萬億條的消息，而且已經部署到了世界範圍內成千上萬的組織之中，包括財富 500 強的公司，如 Cisco、Netflix、PayPal 和 Verizon。Kafka 已經快速成爲流數據的存儲方案，而且爲應用集成提供了一個可擴展的消息支撐（backbone），可以跨多個數據中心。

Kafka 的基礎是 log 的理念，log 是隻能往上追加（append），徹底有序的數據結構。log 自己採用了發佈 - 訂閱（publish-subscribe，pubsub）的語義，發佈者可以很是容易地以不可變的形式往 log 上追加數據，訂閱者能夠維護本身的指針，以便指示當前正在處理的消息。

Kafka 可以經過 Kafka Connect API 實現流數據管道的構建，也就是 ETL 中的 E 和 L。Connect API 利用了 Kafka 的可擴展性，基於 Kafka 的容錯模型進行構建而且提供了一種統一的方式監控全部的鏈接器。流處理和轉換能夠經過 Kafka Streams API 來實現，這提供了 ETL 中的 T。使用 Kafka 做爲流處理平臺可以消除爲每一個目標 sink、數據存儲或系統建立定製化（極可能是重複的）抽取、轉換和加載組件的需求。來自 source 的數據通過抽取後能夠做爲結構化的事件放到平臺中，而後能夠經過流處理進行任意的轉換。

在演講的最後一部分，Narkhede 詳細討論了流處理的概念，也就是流數據的轉換，而且提出了兩個相互對立的願景：實時的 MapReduce 和事件驅動的微服務。實時的 MapReduce 適用於分析用例而且須要中心化的集羣和自定義的打包、部署和監控。Apache Storm、Spark Streaming 和 Apache Flink 實現了這種模式。Narkhede 認爲事件驅動微服務的方式（經過 Kafka Streams API 來實現）讓任何用例都能訪問流處理，這隻需添加一個嵌入式庫到 Java 應用中並搭建一個 Kafka 集羣便可。

Kafka Streams API 提供了一個便利的 fluent DSL，具備像 join、map、filter 和 window 這樣的操做符。

這是真正的每次一個事件（event-at-a-time）的流處理，沒有任何微小的批處理，它使用數據流（dataflow）風格的窗口（window）方式，基於事件的時間來處理後續到達的數據。Kafka Streams 內置了對本地狀態的支持，而且支持快速的狀態化和容錯處理。它還支持流的從新處理，在更新應用、遷移數據或執行 A/B 測試的時候，這是很是有用的。

Narkhede 總結說，log 統一了批處理和流處理，log 能夠經過批處理的窗口方式進行消費，也能在每一個元素抵達的時候進行檢查以實現實時處理，Apache Kafka 可以提供「ETL 的嶄新將來」。

歡迎工做一到五年的Java工程師朋友們加入Java程序員開發： 854393687 羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！