最近的一些數據發展趨勢推動了傳統的批處理抽取 - 轉換 - 加載（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等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！