在 QCon 舊金山會議上，Neha Narkhede 做了“ETL 已死，而實時流長存”的演講，并討論了企業(yè)級數(shù)據(jù)處理領(lǐng)域所面臨的挑戰(zhàn)。該演講的核心前提是開源的 Apache Kafka 流處理平臺能夠提供靈活且統(tǒng)一的框架，支持數(shù)據(jù)轉(zhuǎn)換和處理的現(xiàn)代需求。

Narkhede 是 Confluent 的聯(lián)合創(chuàng)始人和 CTO，在演講中，他首先闡述了在過去的十年間，數(shù)據(jù)和數(shù)據(jù)系統(tǒng)的重要變化。該領(lǐng)域的傳統(tǒng)功能包括提供聯(lián)機事務(wù)處理(online transaction processing，OLTP)的操作性數(shù)據(jù)庫以及提供在線分析處理(online analytical processing，OLAP)的關(guān)系型數(shù)據(jù)倉庫。來自各種操作性數(shù)據(jù)庫的數(shù)據(jù)會以批處理的方式加載到數(shù)據(jù)倉庫的主模式中，批處理運行的周期可能是每天一次或兩次。這種數(shù)據(jù)集成過程通常稱為抽取 - 轉(zhuǎn)換 - 加載(extract-transform-load，ETL)。

最近的一些數(shù)據(jù)發(fā)展趨勢推動傳統(tǒng)的 ETL 架構(gòu)發(fā)生了巨大的變化：

• 單服務(wù)器的數(shù)據(jù)庫正在被各種分布式數(shù)據(jù)平臺所取代，這種平臺在整個公司范圍內(nèi)運行;
• 除了事務(wù)性數(shù)據(jù)之外，現(xiàn)在有了類型更多的數(shù)據(jù)源，比如日志、傳感器、指標數(shù)據(jù)等;
• 流數(shù)據(jù)得到了普遍性增長，在速度方面比每日的批處理有了更快的業(yè)務(wù)需求。

這些趨勢所造成的后果就是傳統(tǒng)的數(shù)據(jù)集成方式最終看起來像一團亂麻，比如組合自定義的轉(zhuǎn)換腳本、使用企業(yè)級中間件如企業(yè)服務(wù)總線(ESB)和消息隊列(MQ)以及像 Hadoop 這樣的批處理技術(shù)。

在探討現(xiàn)代流處理技術(shù)如何緩解這些問題之前，Narkhede 簡要回顧了一下數(shù)據(jù)集成的歷史。在上世紀 90 年代的零售行業(yè)中，業(yè)務(wù)得到了一些新形式的數(shù)據(jù)，所以對購買者行為趨勢進行分析的需求迫切增長。

存儲在 OLTP 數(shù)據(jù)庫中的操作性數(shù)據(jù)必須要進行抽取、轉(zhuǎn)換為目標倉庫模式，然后加載到中心數(shù)據(jù)倉庫中。這項技術(shù)在過去二十年間不斷成熟，但是數(shù)據(jù)倉庫中的數(shù)據(jù)覆蓋度依然相對非常低，這主要歸因于 ETL 的如下缺點：

• 需要一個全局的模式;
• 數(shù)據(jù)的清洗和管理需要手工操作并且易于出錯;
• ETL 的操作成本很高：它通常很慢，并且是時間和資源密集型的;
• ETL 所構(gòu)建的范圍非常有限，只關(guān)注于以批處理的方式連接數(shù)據(jù)庫和數(shù)據(jù)倉庫。

在實時 ETL 方面，早期采用的方式是企業(yè)應(yīng)用集成(Enterprise application integration，EAI)，并使用 ESB 和 MQ 實現(xiàn)數(shù)據(jù)集成。盡管這可以說是有效的實時處理，但這些技術(shù)通常很難廣泛擴展。這給傳統(tǒng)的數(shù)據(jù)集成帶來了兩難的選擇：實時但不可擴展，或者可擴展但采用的是批處理方案。

Narkhede 指出現(xiàn)代流處理對數(shù)據(jù)集成有了新的需求：

• 能夠處理大量且多樣性的數(shù)據(jù);
• 平臺必須要從底層就支持實時處理，這會促進向以事件為中心的根本轉(zhuǎn)變;
• 必須使用向前兼容的數(shù)據(jù)架構(gòu)，必須能夠支持添加新的應(yīng)用，這些新的應(yīng)用可能會以不同的方式來處理相同的數(shù)據(jù)。

這些需求推動一個統(tǒng)一數(shù)據(jù)集成平臺的出現(xiàn)，而不是一系列專門定制的工具。這個平臺必須擁抱現(xiàn)代架構(gòu)和基礎(chǔ)設(shè)施的基本理念、能夠容錯、能夠并行、支持多種投遞語義、提供有效的運維和監(jiān)控并且允許進行模式管理。Apache Kafka 是七年前由 LinkedIn 開發(fā)的，它就是這樣的一個開源流平臺，能夠作為組織中數(shù)據(jù)的中樞神經(jīng)系統(tǒng)來運行，方式如下：

• 作為應(yīng)用的實時、可擴展消息總線，不需要 EAI;
• 為所有的消息處理目的地提供現(xiàn)實狀況來源的管道;
• 作為有狀態(tài)流處理微服務(wù)的基礎(chǔ)構(gòu)建塊。

Apache Kafka 在 LinkedIn 目前每天處理 14 萬億條的消息，并且已經(jīng)部署到了世界范圍內(nèi)成千上萬的組織之中，包括財富 500 強的公司，如 Cisco、Netflix、PayPal 和 Verizon。Kafka 已經(jīng)快速成為流數(shù)據(jù)的存儲方案，并且為應(yīng)用集成提供了一個可擴展的消息支撐(backbone)，能夠跨多個數(shù)據(jù)中心。

Kafka 的基礎(chǔ)是 log 的理念，log 是只能往上追加(append)，完全有序的數(shù)據(jù)結(jié)構(gòu)。log 本身采用了發(fā)布 - 訂閱(publish-subscribe，pubsub)的語義，發(fā)布者能夠非常容易地以不可變的形式往 log 上追加數(shù)據(jù)，訂閱者可以維護自己的指針，以便指示當前正在處理的消息。

Kafka 能夠通過 Kafka Connect API 實現(xiàn)流數(shù)據(jù)管道的構(gòu)建，也就是 ETL 中的 E 和 L。Connect API 利用了 Kafka 的可擴展性，基于 Kafka 的容錯模型進行構(gòu)建并且提供了一種統(tǒng)一的方式監(jiān)控所有的連接器。流處理和轉(zhuǎn)換可以通過 Kafka Streams API 來實現(xiàn)，這提供了 ETL 中的 T。使用 Kafka 作為流處理平臺能夠消除為每個目標 sink、數(shù)據(jù)存儲或系統(tǒng)創(chuàng)建定制化(很可能是重復(fù)的)抽取、轉(zhuǎn)換和加載組件的需求。來自 source 的數(shù)據(jù)經(jīng)過抽取后可以作為結(jié)構(gòu)化的事件放到平臺中，然后可以通過流處理進行任意的轉(zhuǎn)換。

在演講的***一部分，Narkhede 詳細討論了流處理的概念，也就是流數(shù)據(jù)的轉(zhuǎn)換，并且提出了兩個相互對立的愿景：實時的 MapReduce 和事件驅(qū)動的微服務(wù)。實時的 MapReduce 適用于分析用例并且需要中心化的集群和自定義的打包、部署和監(jiān)控。Apache Storm、Spark Streaming 和 Apache Flink 實現(xiàn)了這種模式。Narkhede 認為事件驅(qū)動微服務(wù)的方式(通過 Kafka Streams API 來實現(xiàn))讓任何用例都能訪問流處理，這只需添加一個嵌入式庫到 Java 應(yīng)用中并搭建一個 Kafka 集群即可。

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

這是真正的每次一個事件(event-at-a-time)的流處理，沒有任何微小的批處理，它使用數(shù)據(jù)流(dataflow)風格的窗口(window)方式，基于事件的時間來處理后續(xù)到達的數(shù)據(jù)。Kafka Streams 內(nèi)置了對本地狀態(tài)的支持，并且支持快速的狀態(tài)化和容錯處理。它還支持流的重新處理，在更新應(yīng)用、遷移數(shù)據(jù)或執(zhí)行 A/B 測試的時候，這是非常有用的。

Narkhede 總結(jié)說，log 統(tǒng)一了批處理和流處理，log 可以通過批處理的窗口方式進行消費，也能在每個元素抵達的時候進行檢查以實現(xiàn)實時處理，Apache Kafka 能夠提供“ETL 的嶄新未來”。