大資料與 AI 時代不僅給人們帶來了生活上的便利，也給軟體工程師、系統架構師、資料分析師帶來了技術上的挑戰。那麼，如何在面臨海量資料的情況下構 建一個健壯、可擴充套件、響應迅速的資料類應用，並且兼顧系統模型的靈活性？如果你也是一名被這些問題困擾的開發者，我想《事件流實戰》會給你一些啟示。

“事件”對於開發者而言是個熟悉的詞，各種開發框架、程式語言中都或多或少有“事件”的概念，但很少有書籍談及如何運用事件對系統建模。“流”的概念 亦是如此，計算機世界中充斥著各種流：輸入輸出流、網路流，還有最近幾年出 現的流計算。而本書把事件與流的概念結合在一起，展示了一種嶄新的架構；通 過流這種資料架構在系統之間傳遞事件，不僅解除了系統間的耦合，也為系統帶 來了更好的擴充套件性，同時資料分析師可以自由地開展各種分析。

系統架構上不存在銀彈，但基於事件流的架構設計讓我們多了一種選擇，它帶來的特性與優勢是之前傳統架構所沒有的。而使用事件流實現 Event Sourcing 這樣的模式就非常簡單且自然，能解決以往架構方案很難處理的問題。本書延續 了“實戰”系列書籍的一貫風格，強調實戰性，大部分示例來源於我們日常開發 中耳熟能詳的場景。無論你是一位經驗豐富的架構師，還是一個初出茅廬的開發 者，一定能從書中獲得自己想要的答案。

《事件流實戰》是一本全程關注事件的書籍，主要討論如何定義事件，如何向 Apache Kafka、Amazon Kinesis 這類統一日誌系統傳送事件，以及如何編寫一個處理流資料的應用程式。

《事件流實戰》涵蓋了以下技術的基礎知識：Kafka、Kinesis、Samza 和 Spark Streaming 等流式處理框架，以及與事件處理契合的資料庫(如 Redshift)。

節選自《事件流實戰》一書

-----------------------------------------------圖書基本資訊------------------------------------------------------

書名： 《事件流實戰》

ISBN:9787302559412

定價：98元

出版時間：2020年9月

京東連結：https://item.jd.com/12965562.html

內容簡介：

Linkedln、Netflix等知名應用都通過實時響應使用者和系統事件，來提高靈活度和響應速度。在大規模系統中，需要能高效地監控、管理和處理大量的事件流。
Kafka工具以及諸如統一日誌處理的創新模式可幫助我們為基於事件的系統建立連貫的資料處理架構。
《事件流實戰》講解如何使用統一日誌模式，來聚合、儲存和處理事件流。在這本實用指南中，你將看到Lambda架構、流聚合和事件重放處理等重要的系統設計，還將看到擴充套件、彈性和高階流模式!讀完本書，你將能設計出易於構建、部署和維護的由資料驅動的大型應用。
主要內容
校驗與監控事件流
事件分析
事件建模
Apache Kafka與Amazon Kinesis的使用示例

------------------------------------------------------試讀樣章--------------------------------------------------------

第 1 章 事 件 流

無論你相信與否，真實世界中不間斷的“流”與數字化事件已經對你所在的 公司產生了深遠影響，只不過並不是像你同事設想的那樣。相反，他們覺得自己 的工作是按照以下方式進行的：

每天和他人或其他事物(例如客戶、市場團隊)進行互動，提交程式碼或釋出 一款新產品。

使用軟體與硬體完成日常工作。

完成工作列表中的待辦任務。

人類會按照上面的方式思考與工作，這與計算機是不同的。因為要在午餐時 間向老闆提交報告，所以 QA 部門的 Sue 需要早起並工作。如果換一種思考方式， 假定我們的工作方式變為建立和響應一系列持續的、由事件組成的“流”，這對於 我們來說或許難以接受，因為很可能你會在休假期間被叫回辦公室。

計算機對此卻不會有任何問題，它們對以下業務定義會非常滿意：

公司是一個能夠產生和響應持續事件流的組織。 這樣的定義並不是想從經濟學家那裡“要掌聲”，但是作為本書的作者，我們 相信從持續事件流的角度來重塑你的業務模型會帶來巨大收益。事件流會帶來以 下這些特別的好處。

更加及時的洞察力——持續事件流猶如公司業務的“脈搏”，相比而言， 基於傳統批處理的資料倉庫就顯得有些延滯。

觀察事實的單一視角——對於你和你的同事們，相同的問題可能會具有不 同的答案。因為他們工作在資料的不同“點”上。一個建模良好的持續事 件流對於事實將提供單一視角，以此來消除歧義。

更快的反應——自動化、近實時的持續事件流處理流程使業務能在幾分鐘 (甚至幾秒鐘)內對事件作出響應。

更簡潔的架構——大部分業務都建立在由雜亂的點對點連線的事務性系 統之上。而事件流可以幫助我們解開這些系統之間雜亂的耦合關係。

本章將首先探討“究竟什麼是事件”，將介紹一些事件的簡單例子，也將解釋 什麼是持續事件流。這對於你來說是個很好的機會去發現這樣一個事實：事件流 已經是你工作的一部分——只不過不是以你預想的那種方式存在。

在展示了一些耳熟能詳的事件流後，將重點介紹在過去 20 年中企業是如何處 理事件的。你將看到，持續的技術演進是如何將一件簡單的事情變得過於複雜， 而一種被稱為統一日誌的新架構模式，又是如何把事情化繁為簡的。

新技術必須能解決那些棘手的使用者問題，才能被主流所接受。因此我們將通 過各種行業的實際示例，讓持續事件流和統一日誌的優勢顯得更為真實。

1.1 術語定義

如果你在一個現代化的企業工作，那麼很可能已經和各種形式的事件流打過 交道，只是從未意識到而已。接下來將展示事件的定義，以及事件是如何組成一 個持續事件流的。

1.1.1 事件

在我們定義什麼是持續事件流之前，先明確單一事件的定義。幸運的是，這個 定義非常簡單：事件是在某個具體時間觀察到的發生的任何事物。如圖 1.1 所示， 我們舉了 4 個不同行業的“事件”示例。

由於事件的定義如此簡單，很多時候可能會引起歧義。因此在進一步討論之 前，我們先明確什麼不是事件。下面並不是一份詳盡的列表，但列出了應當避免 的最常見錯誤，一個事件絕不是以下列出的任何一項：

對某樣東西持續狀態的描述。如天氣很溫暖、這輛車是黑色的、客戶端 API 崩潰了。但“客戶端 API 在週二下午崩潰了”是一個事件。

經常發生的事。如納斯達克(NASDAQ)每天上午 9:30 開盤。但是“2018 年某一天的納斯達克開盤”是一個事件。 一系列單獨事件的集合。如普法戰爭由施皮謝亨戰役、麥茨攻城戰以及色當戰役組成。但是“法國與普魯士於 1870 年 7 月 19 日爆發戰爭”是一個事件。

一個具體時間範圍內發生的事情。如 2018 年的黑色星期五促銷開始於 0 點，結束於晚上 11 點 59 分 59 秒。但是一個營銷活動的開始是一個事件， 營銷活動的結束同樣是一個事件。

圖 1.1 雖然在時間精度上並不完全相同，但可看到四個事件都是具體、可記錄的， 發生於現實世界與數字世界(或兩者兼而有之)

這裡有個經驗性的判斷法則：如果在描述某樣事物時，可將它和一個具體時 間點聯絡起來，就可以嘗試用事件的形式描述它。有時可能需要組織一下語言， 讓描述更通順。

1.1.2 持續事件流

我們已經明確了事件的定義，那究竟什麼才是持續事件流呢？簡而言之，一 個持續事件流就是一連串不會終止、連續的單獨事件，它們按照發生的時間先後 排序。圖 1.2 從抽象的角度描繪了一個持續事件流的樣子：可以看到一連串的單 獨事件按時間順序依次排列。

圖 1.2 持續事件流的詳細結構：時間與事件都是按自左向右的方向遞進。事件流是 沒有終止的，它的起始方向和終止方向都可能超出我們能夠處理的範圍

基於以下原因，我們稱這一系列事件是不會終止的：

流開始的時間可能早於我們開始觀察的時間。

流可能在未來某個不確定的時間終止。

為說明這一點，我們以客人入住日本 Hoshi Ryokan 旅館的場景為列。Hoshi Ryokan 旅館創建於公元 718 年，被認為是世界上最古老的旅館之一。當在分析客 人入住的事件流時，你會發現最早的那些客人入住事件已經隨著時間的流逝，不得而知。未來客人入住的事件會一直持續發生，直到我們退休都不會終結。

1.2 探尋我們熟悉的事件流

如果閱讀了上一節，你覺得事件和持續事件流的概念似曾相識，那你很有可 能已經使用了事件流的相關技術，只是未將它們辨識出來。大量的軟體系統受到 持續事件流的影響，包括：

交易系統——大部分這類系統需要響應外部事件，例如客戶下單或供應商 交付貨品。

資料倉庫——從其他系統中收集事件的歷史資訊，並稍後在因子表中對它 們進行分析和排序。 系統監控——從軟體或硬體裝置持續地檢查系統級別和應用級別的事件， 以此監測異常。

站點分析——通過分析網站訪問者的行為事件流，分析師可形成相關的 觀點。

本節將介紹三個最常見且最接近事件流概念的程式設計領域。希望這能讓你更多 地從事件的角度來思考現有的程式設計工具。但如果這些例子對你而言有些陌生，也 不必擔心，之後你將有大量機會從無到有地掌握事件流。

1.2.1 應用級日誌

讓我們首先討論大部分後端開發者和前端開發者都熟悉的“應用級日誌”。如 果你曾用過 Java，那麼很可能也用過 Apache Log4j；如果沒有，也不必擔心，它 與其他日誌工具非常類似。假設 Log4j.properties 檔案配置完成，而一個靜態的日誌記錄器也已被成功初始化，那麼使用 Log4j 相當容易。程式碼清單 1.1 展示了一 個 Java 開發者如何使用它在應用中記錄日誌。

程式碼清單 1.1 使用了 Log4j 的應用日誌

doSomethingInteresting(); log.info("Did something interesting"); doSomethingLessInteresting(); log.debug("Did something less interesting");

// Log output: // INFO 2018-10-15 10:50:14,125 [Log4jExample_main] "org.alexanderdean.Log4jExample": Did something interesting // INFO 2018-10-15 10:55:34,345 [Log4jExample_main] "org.alexanderdean.Log4jExample": Did something less interesting Listing

1.1 Application logging with Log

可以看到應用級日誌常用來在某個時間點記錄特定事件。記錄日誌事件的代 碼非常基礎，僅記錄了事件的重要等級，以及用來描述事件的訊息字串。但是 Log4j 也額外添加了一些元資料，包括事件發生的時間、記錄該事件的執行緒以及 對應的 Java 類。

當你的應用產生日誌事件後，應該做什麼呢？最佳實踐告訴我們，應該將日 志事件寫入磁碟上的一個日誌檔案。然後使用日誌收集技術(如 Flume、Flunted、 Logstash 或 Filebeat)將這些日誌檔案從不同伺服器上收集過來，並進行彙總，用 於後續的系統監控和日誌分析。圖 1.3 說明了這種型別的事件流。

圖 1.3 一個執行在兩臺伺服器上的應用，每個應用例項都會生成日誌資訊。日誌資訊 在被迴圈寫入本地磁碟後，由日誌收集器轉發給系統監控或日誌分析工具

很明顯，應用級別的日誌是一個持續事件流，只是它很大程度上依賴於無模 式的訊息結構(而這種通常是人類可閱讀的)。就像 Log4j 示例中所展示的，應用級 日誌是高度可配置的，並沒有跨語言和框架的標準配置。在一個多程式語言的項 目中，通用日誌的標準化是一項令人痛苦的工作。

1.2.2 站點分析

讓我們來看下一個例子。如果你是一個前端 Web 開發者，那麼在網站或網站 應用中嵌入 JavaScript 來進行一些 Web 或事件分析是自然而然的事。在這類軟體 中，最受歡迎的是一款由 Google 提供的“軟體即服務”(SaaS，Software-as-a-Service) 軟體，Google Analytics。2012 年，Google 釋出了新一代的分析軟體，即 Universal Analytics。

程式碼清單 1.2 展示了通過 JavaScript 呼叫 Universal Analytics 的示例。這部分代 碼可以直接嵌入站點的原始碼中，或通過一個 JavaScript 標籤管理器來呼叫。無論哪 種方式，當任何一個網站訪問者訪問站點時，這段程式碼都會被執行，用來產生一個 持續的事件流，代表訪問者與站點的互動行為。這些事件最終會流向 Google，然後 被儲存、處理並展示在不同的報表上。圖 1.4 展示了整個事件流程。

程式碼清單 1.2 通過 Universal Analytics 服務進行網站追蹤

通過這樣部署 Google Analytics，業務分析師可以登入到 Google Analytics，通 過站點提供的介面入口，瞭解所有網站訪問者的事件流。圖 1.5 是 Universal Analytics 實時資料儀表盤的截圖，它展示了過去 30 分鐘 Snowplow Analytics 網站 所發生的事件。

1.2.3 釋出/訂閱訊息 讓我們看一個更底層的例子，也許仍是很多讀者所熟悉的內容：應用程式消 息，特別是釋出/訂閱模式的訊息。釋出/訂閱有時簡稱為 pub/sub，是一種簡單的訊息通訊方式。

訊息的傳送者(sender)可以釋出(publish)訊息，訊息可能屬於一個或多個主 題(topic)。

訊息的接收者(receiver)可以訂閱(subscribe)特定的主題(topic)，之後便可收 到所有訂閱主題的訊息。

如果曾經使用過 pub/sub 傳送訊息，那很有可能傳送的就是某種形式的事件。

讓我們動手嘗試一下 NSQ。NSQ 是一個頗受歡迎的分散式 pub/sub 訊息中間 件，最初由 Bitly 建立。如圖 1.6 所示，NSQ 在一個訊息釋出應用和兩個訊息訂閱 應用之間進行事件代理。

使用 NSQ 進行演示的優點在於，它易於安裝和使用。在 macOS 中，我們只需要 開啟一個終端視窗，使用 Homebrew 進行安裝，然後啟動 nsqlookupd 守護程序即可：

$ brew install nsq

...

$ nsqlookupd

...

然後在另一個終端視窗中，我們啟動 NSQ 的主程序 nsqd：

$ nsqd --lookupd-tcp-address=127.0.0.1:4160

...

我們讓之前的兩個守護程序保持執行，並開啟第三個終端視窗。我們使用 nsqd 提供的 HTTP API 建立一個新的主題：

$ curl -X POST http://127.0.0.1:4151/topic/create\?topic\=Topic1

接著開始建立兩個新的訂閱者，應用 2 和應用 3。再開啟兩個新的終端視窗， 執行 nswq_tail 來模擬應用 2 和應用 3 訂閱 Topic1：

$ nsq_tail --lookupd-http-address=127.0.0.1:4161 \

--topic=Topic1 --channel=App2

2018/10/15 20:53:10 INF 1 [Topic1/App2]

querying nsqlookupd http://127.0.0.1:4161/lookup?topic=Topic1

2018/10/15 20:53:10 INF 1 [Topic1/App2]

(Alexanders-MacBook-Pro.local:4150) connecting to nsqd

然後開啟第五個，也是最後一個終端視窗：

$ nsq_tail --lookupd-http-address=127.0.0.1:4161 \

--topic=Topic1 --channel=App3

2018/10/15 20:57:55 INF 1 [Topic1/App3]

querying nsqlookupd http://127.0.0.1:4161/lookup?topic=Topic1

2018/10/15 20:57:55 INF 1 [Topic1/App3]

(Alexanders-MacBook-Pro.local:4150) connecting to nsqd

回到第三個終端視窗(唯一沒有執行守護程序的視窗)，我們通過HTTP API 發 送一些事件：

$ curl -d 'checkout' 'http://127.0.0.1:4151/pub?topic=Topic1'

OK%

$ curl -d 'ad_click' 'http://127.0.0.1:4151/pub?topic=Topic1'

OK%

$ curl -d 'save_game' 'http://127.0.0.1:4151/pub?topic=Topic1'

OK%

在執行應用 2 的視窗中可以看到事件到達的資訊：

2018/10/15 20:59:06 INF 1 [Topic1/App2] querying nsqlookupd

http://127.0.0.1:4161/lookup?topic=Topic1

checkout

ad_click

save_game

在應用 3 的視窗中，也會看到相同的資訊：

2018/10/15 20:59:08 INF 1 [Topic1/App3] querying nsqlookupd

http://127.0.0.1:4161/lookup?topic=Topic1

checkout

ad_click

save_game

在 pub/sub 架構中，我們的事件由一個應用釋出，並被其他兩個應用所訂閱。 只要新增更多事件，就會獲得一個被不斷處理的持續事件流。

希望本節的例子可以讓你意識到事件流是一個熟悉的概念，支援不同的系統 和解決方案，包括應用級日誌、站點分析和釋出/訂閱訊息。所採用的技術也許不 同，但從上述三例中可以看到相同的部分：事件的模式或結構(即使很少)、事件 的生成方式、事件的收集以及後續處理。

1.3 統一持續事件流

到目前為止，本章介紹了事件流的概念，定義了所使用的術語，並突出了我 們所熟悉的某種技術中是如何使用事件流的。這是一個良好開端，但你也應該看 到，這些技術的應用是碎片化的：它們的事件特性並不容易理解，它們的事件模 式並不是標準化的，而且它們的應用場景散落在各處。本節將介紹在業務中使用 持續事件流的更為先進和強大的方式。

簡而言之，本書的觀點是任何數字化業務都應該按照以下流程重新組織。

從各個不同的源系統收集各種事件。

將事件儲存在一個統一日誌中。

讓資料處理應用可以在這些事件流上執行。

這是個大膽的主意，而且聽起來有一大堆工作要做。那有什麼證據表明這是 一個對企業實用而有效的解決方案？

本節描述了業務資料處理的歷史和發展歷程，並把話題擴充套件到事件流和統一 日誌。我們將演變過程分為兩個截然不同的時代，我們有第一手的經驗，同時也 將迎來第三個嶄新的時代。

古典時代——“大資料、SaaS 時代”之前的業務系統和基於批處理作業的資料 倉庫。

混合時代——現如今的由不同系統和不同解決方案組成的“大雜燴”。

統一時代——新興的架構，通過在統一日誌中處理持續事件流。

1.3.1 古典時代

在古典時代，企業需要運維一整套本地部署的不同交易系統，並將資料灌入 資料倉庫。圖 1.7 展示了這種架構。每個交易系統都具有如下特點：

一個用來執行準實時資料處理的內部迴路。

具有自己的資料筒倉。

在需要時，和對等系統進行點對點連線(通過 API 或 Feed 匯入/匯出)。

資料倉庫通常在夜間通過一系列的抽取、轉換和載入(ETL)，從各個交易系統 獲取資料。因此資料倉庫為企業提供了對於真實狀況的單一視角，不僅具有完整 的資料歷史，還具有廣泛的覆蓋範圍。在內部，資料倉庫通常採用由 Ralph Kimball 推廣的、基於因子表和維度表的星型模型。

雖然我們稱之為古典時代，而且有越來越多的 SaaS 被引入，但實際上現今仍 有大量企業採用這種架構或由其衍生的架構。這是一個久經考驗的架構，但它仍 具有以下缺陷：

滯後的報表——事件發生到出現在報表中的事件跨度以小時計(甚至以天 計)，而不是以秒計。

點對點的“義大利麵條”結構——新增的交易系統會帶來更多點對點連線， 如圖 1.8 所示，這種點對點的“義大利麵條”結構帶來了昂貴的構建和維 護成本，同時增加了系統整體的脆弱性。

模型困境——傳統的資料倉庫假設每個企業都可從業務系統中挖掘出一個穩 定的資料模型，但正如我們將在第 5 章中所看到的，這是一個有缺陷的假設。

在面對這些問題時，有些企業完成了到新模式的飛躍，特別是零售、技術和 媒體這些飛速發展領域的企業。我們把這個新模式稱為混合時代。

1.3.2 混合時代

混合時代的一大特點是企業維護著一堆由交易系統和分析系統組成的大雜 燴。它們有的來自私有部署的商業軟體，有的來自某個 SaaS 供應商，而有的是自 己研發的軟體系統。圖 1.9 展示了一個混合時代架構的示例。

很難用寥寥數語概括混合時代的架構。同樣，混合時代的架構存在很嚴重的 “本地迴圈”和“資料孤島”的問題，但仍有一些試圖使用 Hadoop 或系統監控技 術“記錄所有事情”的嘗試。對於狹義的分析場景，例如產品推薦，往往傾向於 混合使用準實時處理技術，此外將資料批處理的工作從資料倉庫剝離，轉而由 Hadoop 處理。混合架構還會從 SaaS 系統中批量匯出資料並放入資料倉庫，同時 通過這些 SaaS 系統自有的 API，提供它們所需的專有資料。

儘管這種混合的解決方案彌補了經典解決方案中的一些不足，但也帶來了自 己特有的問題。

缺乏對真實狀況的單一視角——基於資料量的大小和分析時效性的要求，數 據被倉儲在多個不同的系統。因此沒有哪個系統的資料是 100%完整可見的。

決策變得支離破碎——系統本地處理與資料孤島的數量較古典時代有增 無減。這讓基於資料的準實時決策變得脆弱。

點對點互動數量激增——隨著系統數量的增加，系統間點對點互動的數量 呈爆炸性增長。其中的許多互動是脆弱或不完整的，從外部的 SaaS 系統 中獲取精確及時的資料變得極具挑戰。

分析的實時性與資料覆蓋性不能兼得——當以低延遲執行流處理時，實際 上就變為一個本地處理程式。資料倉庫的目的在於更廣泛的資料覆蓋範 圍，但帶來的代價就是資料的冗餘和高延遲。

1.3.3 統一時代

這兩個時代把我們帶到了今時今日，也帶來了新興的資料處理的統一時代。 關鍵的創新就是將統一日誌作為我們所有資料收集與處理的核心。統一日誌 (unified log)是一個只可追加的日誌，系統中產生的所有事件都會寫入其中。此外， 統一日誌還具有如下特性：

支援各種低延遲的讀取要求。

支援多個不同系統同時讀取，不同的系統可以按照自己的速率讀取日誌。

僅保留一個“時間視窗”內的事件——可以是一週也可以是一個月。但可以將 歷史資料歸檔在 Hadoop 分散式檔案系統(Hadoop Distributed File System， HDFS)或 Amazon S3(Simple Storage Service，簡單儲存服務)中。

現在，先不要擔心統一日誌的實現機制，第 2 章會深入介紹這方面的細節。 目前，最重要的是要理解統一日誌在企業中是如何重塑資料處理流程的。圖 1.10 將零售商的系統架構更新至統一時代，新架構遵循以下兩個簡單規則：

所有軟體系統都可以且應該將它們各自的持續事件流寫入統一日誌。即使是 第三方的 SaaS 供應商也可通過 webhook 和流 API 釋出事件。

除非有低延遲或事務保證的要求，否則各個系統只能通過統一日誌以鬆耦 合的方式進行互動，絕不能通過點對點的方式。

與之前的兩種架構相比，統一日誌具有如下優勢：

對真實狀況的單一視角。統一日誌加上 Hadoop 的歸檔資料代表了對於真 實狀況的單一視角。它們包含了相同的資料(事件流)，但處於不同的“時 間視窗”中。

對真實狀況的單一視角處於資料倉庫的上游。在古典時代，資料倉庫提供 了對真實狀況的單一視角，使得基於它產生的所有報表均保持一致。在統 一時代，統一日誌提供了類似的單一視角。因此，業務系統(例如推薦系 統、廣告目標定位系統)和分析師製作管理報表都是基於相同的資料。

點對點的互動數量大大減少。取而代之的是系統可對統一日誌進行追加操 作，而其他系統則可讀取追加的日誌資料，如圖 1.11 所示。

本地迴圈可以打破“資料孤島”的限制。系統可以通過統一日誌進行準實 時的協作，並做出決策。

1.4 統一日誌的應用場景

閱讀前幾節後，你可能會認為“持續事件流與統一日誌看上去的確很不錯， 但它似乎是一種架構上的優化，而非用於實現一個全新系統”。事實上，它不僅是 針對之前解決方案在架構上的巨大進步，還推動了全新應用場景的出現。本節將 展示三個能引起你興趣的應用場景。

1.4.1 使用者反饋環路

持續資料處理最令人激動的應用場景之一就是當每個不同的客戶在使用服務 時，能對他們的行為做出不同響應。針對你所從事的不同行業，這種實時反饋回 路的表現可能有所不同。下面是一些具體例子：

零售業——無論何時，當消費者準備棄置購物車時，瀏覽器會彈出帶有優 惠券資訊的視窗，以吸引他們付款。圖 1.12 展示了這樣一個例子。

電視業——基於使用者當前的行為和歷史觀看記錄，實時調整線上節目的收 視指南，以使客戶的觀看時間最大化。

汽車業——檢測到異於平時的駕駛行為時，通知車主汽車是否被盜。

遊戲業——如果玩家發現四人合作遊戲太具挑戰性，調整難度級別以防止 他們退出從而破壞其他玩家的遊戲體驗。

使用者反饋迴路並不是新鮮事物。即使是在古典時代，你同樣可以通過獲取用 戶的行為資料來發送線下郵件或電子郵件進行市場營銷。時至今日，一些創業公 司會在你瀏覽的網站上放置 JavaScript 程式碼，實時跟蹤使用者的行為，並通過頁面 橫幅、Flash 訊息和彈出視窗來影響使用者的行為。但是統一日誌的使用讓反饋迴路 的功能更為強大：

它們完全處於服務供應商(而非第三方供應商，例如一個基於 SaaS 分析的供 應商)的控制之下，這意味著可以嘗試各種能提升業務的演算法。

驅動反饋的模型是基於完全相同的事件流完整歸檔資料測試的。

使用者對於反饋迴路的反應同樣可以被新增到事件流中，以便後續能夠進行 機器學習。

1.4.2 整體系統監控

對軟體和服務的可用性監控是一項棘手的工作，因為用於檢測和預防的指標 分散在各處：

系統的監控資料會放入第三方服務，或企業自己部署的時間序列資料 庫中。出於網路傳輸與儲存的考量，需要在儲存前對資料預先進行聚 合和取樣。

應用日誌訊息在伺服器關閉或宕機之前，應同日志文件一樣被寫入應用服 務器並完成收集。

客戶事件被髮送至第三方服務，因此無法對這部分客戶資料進行細粒度和 例項級的分析。 有了統一日誌後，所有系統問題都可以通過檢查存放在統一日誌中的事件流 資料來解決。並不需要專門為了系統監控將所有資料存放在統一日誌中。系統管 理員可瀏覽任何資料，從而識別問題之間的相關性，並以此查詢問題的根本原因。

圖 1.13 展示了一個移動應用的整體監控示例。

1.4.3 應用系統版本線上升級

我們之前曾提及，統一日誌可同時被多個不同的應用系統讀取，而且不同的 應用系統可按自己的速率讀取統一日誌。每個使用統一日誌的應用系統可以獨立 地跟蹤已經處理了哪些事件，並決定之後處理的事件。

假定我們有多個相同的應用系統從統一日誌讀取事件，那麼緊接著的問題是 也會有同一應用的不同版本從統一日誌處理事件。這非常有用，因為它允許我們 對資料處理系統進行熱替換(hot swap)——線上升級應用系統而不需要離線。在當 前版本的應用系統仍在執行時，可執行以下步驟：

啟動新版本的應用系統，從頭開始處理統一日誌。

讓新版本的應用系統跟蹤舊版本系統處理日誌的位置。

將使用者接入新版本的應用系統。 關閉舊版本應用系統。

圖 1.14 展示瞭如何將舊版本的應用系統線上升級為新版本。

每個應用系統(或不同版本的應用系統)可維護各自遊標位置，這種能力非常有用。除了可在不停機的狀態下對應用系統升級之外，還能利用這種能力做如下事情：

在實時事件流上測試應用系統的新版本。

將不同演算法的結果在同一事件流上相互比較。

讓不同使用者使用不同版本的應用。

1.5 本章小結

事件是可以在特定時間點觀察到的任何事物。

連續事件流是一系列不會終止的個體事件，這些事件按照發生時間進 行排序。

事件流的概念對大量軟體系統產生了深遠影響，包括應用級日誌、站點分 析和釋出/訂閱訊息。

古典時代的資料處理方案中，業務操作散佈在各個私有部署的系統中，並 將資料寫入資料倉庫中。這些系統存在的問題是：高資料延遲，嚴重的數 據孤島，大量的系統間點對點互動。

在混合時代的資料處理解決方案中，業務操作發生在一個混合了交易與分 析系統的大雜燴架構中。雖然仍存在資料孤島的問題，但嘗試通過 Hadoop 和系統監控的方式來“記錄所有日誌”。

在統一日誌時代，建議企業圍繞一個只可追加的日誌重新構建應用，而這 些應用負責向日志寫入產生的事件。

統一日誌架構的應用場景包括使用者反饋迴路、整體系統監控和應用系統版 本熱替換。

想了解更多關於《事件流實戰》內容，請點選：

https://item.jd.com/12965562.html