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

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

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

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

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

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

存儲(chǔ)在 OLTP 數(shù)據(jù)庫(kù)中的操作性數(shù)據(jù)必須要進(jìn)行抽取、轉(zhuǎn)換為目標(biāo)倉(cāng)庫(kù)模式，然后加載到中心數(shù)據(jù)倉(cāng)庫(kù)中。這項(xiàng)技術(shù)在過(guò)去二十年間不斷成熟，但是數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)覆蓋度依然相對(duì)非常低，這主要?dú)w因于 ETL 的如下缺點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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