在 QCon 舊金山會議上，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 的嶄新未來”。