串流資料函式庫統一批次串流處理

串流資料函式庫的興起，源於將資料函式庫系統的成熟技術與串流處理的新正規化相結合，以簡化實時資料處理的複雜性。傳統資料函式庫系統擅長處理靜態資料，而串流處理框架則專注於動態資料。串流資料函式庫的出現，彌合了兩者之間的差距，讓非技術使用者也能像查詢靜態資料一樣輕鬆處理動態資料。此一轉變如同 Martin Kleppmann 提出的「將資料函式庫內外翻轉」概念，將資料函式庫的內部功能，如預寫日誌（WAL）和物化檢視，外部化為即時串流，從而提升資料處理的效率和擴充套件性。早期串流處理框架如 Apache Kafka Streams 和 Apache Samza 率先實作了物化檢視，為串流資料函式庫的發展奠定了基礎。

串流資料函式庫：統一批次與串流處理

在現今的資料驅動時代，實時應用程式正逐漸成為主流。要建立一個運作良好的模型，需要從源頭取得實時資料，進行流暢的串流處理，並提供低延遲的分析結果。本文旨在幫助資料工程師、資料架構師和資料分析師學習如何使用串流資料函式庫來建立實時解決方案。

本文內容與架構

本文由Hubert Dulay和Ralph M. Debusmann共同撰寫，探討串流資料函式庫的基礎知識，包括如何減少實時解決方案的基礎設施。讀者將學習到串流資料函式庫、串流處理和實時線上分析處理（OLAP）資料函式庫之間的差異，並瞭解何時使用推播查詢與提取查詢，以及如何服務由串流資料函式庫處理的同步和非同步資料。

章節簡介

1. 串流基礎：本章節介紹了串流資料函式庫的基本概念，包括將資料函式庫功能外部化、預寫日誌、串流平台、物化檢視等，並透過點選流分析的案例研究，探討了事務和事件的理解、領域驅動設計、上下文豐富化和變更資料捕捉等主題。

2. 串流處理平台：本章節探討了串流處理平台，包括狀態轉換、資料管道、ELT的限制、串流處理器等，並介紹瞭如何在Apache Spark中模擬物化檢視。

3. 服務實時資料：本章節討論瞭如何選擇分析資料儲存、從主題源取得資料、進行攝入轉換、OLTP與OLAP的比較、ACID特性、行列式最佳化、每秒查詢次數和並發性、索引等主題，並介紹瞭如何服務分析結果，包括同步查詢、非同步查詢和推播與提取查詢的區別。

4. 物化檢視：本章節重點介紹了物化檢視的概念，包括檢視、物化檢視和增量更新、變更資料捕捉、推播與提取查詢、CDC和Upsert、連線流等，並透過點選流案例研究，展示了物化檢視的實際應用。

5. 串流資料函式庫簡介：本章節介紹了串流資料函式庫的識別、列式串流資料函式庫、行式串流資料函式庫、邊緣串流類別資料函式庫和SQL表達能力等主題，為讀者提供了對串流資料函式庫的全面瞭解。

本文特色與適用物件

本文是為資料工程師、資料架構師和資料分析師量身開發的實用。無論您是經驗豐富的串流實踐者，還是剛剛踏上實時資料旅程的新手，本文都將為您提供寶貴的知識和技能，幫助您建立優異的串流ETL、CDC或實時分析解決方案。

內容解密：

本文透過詳細的章節安排和豐富的實務案例，為讀者提供了深入瞭解串流資料函式庫和相關技術的機會。從基礎概念到實際應用，本文都給予了全面的介紹和指導。讀者可以透過本文學習到如何有效地利用串流資料函式庫來建立和管理實時資料處理系統，從而在資料驅動的世界中取得競爭優勢。

內容解密：

此圖示展示了實時應用程式如何透過串流資料函式庫來減少基礎設施並提升實時資料處理能力，最終支援同步與非同步查詢的多樣需求。串流資料函式庫作為核心技術，不僅簡化了系統架構，還提高了資料處理的效率和靈活性。

串流資料函式庫的新正規化：前言解析

在軟體工程領域，開創新的軟體系統類別是許多工程師的夢想。當 Ralph 和 Hubert 決定撰寫一本關於串流資料函式庫的書籍時，作者對此產生了濃厚的興趣。串流資料函式庫的概念源自於將成熟的資料函式庫系統技術與串流處理的新正規化相結合，以簡化串流處理的複雜度。

串流資料函式庫的定義與重要性

串流資料函式庫是一種新興的資料函式庫系統類別，它結合了傳統資料函式庫系統的優勢和串流處理的創新思維。傳統的資料函式庫系統，如關係型資料函式庫，已有數十年的歷史，而串流處理則是在近十年來隨著 Apache Kafka 的興起而迅速發展。串流資料函式庫旨在使非技術使用者也能輕鬆處理動態資料，就像查詢靜態資料一樣方便。

歷史背景與技術演進

在過去，串流處理被視為一項具有挑戰性的任務，只有大型組織中具備專業串流技術團隊才能掌握。類別似地，50 年前，資料處理和計算也曾經是專業人士的領域，直到 SQL 和關係型資料函式庫系統的出現，才使得非技術使用者也能運算元據。如今，SQL 已成為資料處理的通用語言。

串流資料函式庫的核心價值

串流資料函式庫代表了串流處理的下一個演化階段。它統一了成熟的資料函式庫系統技術和串流處理的新正規化，使非技術使用者能夠輕鬆地處理動態資料。這種創新不僅簡化了串流處理的複雜度，也拓展了資料處理的應用範圍。

資料處理的新境界

透過串流資料函式庫，使用者可以像查詢靜態資料一樣，輕鬆地處理動態資料。這一創新思維不僅改變了資料處理的方式，也為未來的資料應用開啟了新的可能性。

串流資料函式庫的興起與未來

在第三個千禧年的開始，隨著「大資料」的崛起，為了滿足日益增長的擴充套件需求，人們發明瞭像MapReduce這樣的新系統。然而，這些新系統是由技術專家為技術專家開發的，它們使我們遠離了SQL的熟悉度。

隨著資料湖（data lakes）的出現，這是「大資料」時代的第一個產物，人們很快意識到需要SQL來使非技術使用者能夠充分利用這些新技術。因此，SQL被重新引入，如今所有現代資料湖都使用SQL來查詢儲存的資料。

串流資料（data streaming）作為「大資料」時代的第二個產物，也遵循了相同的趨勢：首先，串流處理系統由專家為專家構建，沒有SQL的支援。沒過多久，SQL和資料函式庫技術被引入，以使非技術使用者能夠使用這些新的串流系統。這一發展導致了串流資料函式庫的出現以及隨之而來的創新浪潮。

隨著越來越多的人意識到串流資料函式庫在串流處理和資料函式庫技術領域的重要性，他們需要指導如何將其與現有的系統一起使用。串流處理，如本文所述，在操作平面（OLTP）和分析平面（OLAP）之間增加了一個新的層面。串流平面為資料系統的未來開闢了一個豐富的可能性領域。

串流資料函式庫的多樣性與選擇

在本文中，Hubert和Ralph討論了串流資料函式庫的三個不同的起點：

• 採用資料函式庫技術和SQL的串流處理系統
• 擴充套件以包含串流概念的資料函式庫系統
• 已經採用SQL的資料湖，它們被擴充套件以使用串流功能

這三個起點產生了多種不同的串流資料函式庫，每種都有其自身的限制，並針對不同的使用場景進行了最佳化。這就引出了一個問題：我們應該為什麼使用場景選擇哪種系統，以及有哪些權衡？

串流資料函式庫的未來與創新

隨著Jay Kreps預測「公司正在變成軟體」，我們在資料處理方面有著令人興奮的未來，而串流資料函式庫正是其核心。串流資料函式庫和串流SQL提供的簡化使得更多的非技術使用者能夠採用串流處理，這將引領串流變得無處不在。

我們仍處於串流資料函式庫時代的早期階段，觀察當前趨勢和發現新構建的系統是非常令人興奮的。

本文的目的與內容

本文提供了學習所有這些尖端創新和多種選擇的絕佳切入點，這是新時代早期的典型特徵。

本文超越了傳統批處理的界限，無縫地整合了動態的串流資料世界。如果您來自串流世界，我們為串流處理提供了一個資料函式庫視角。串流資料函式庫彌合了靜態資料和動態資料之間的差距。

透過從Martin Kleppmann關於「將資料函式庫內部翻轉出來」的開創性工作中汲取靈感，我們將敘述翻轉為「將串流系統帶回資料函式庫」。透過這種正規化轉變，我們可以首先解開串流處理的複雜層次，然後找到使實時串流對開發人員來說更易於理解和使用的熟悉抽象。

核心原理與實務應用

我們的探索探討了串流資料函式庫的核心原理，揭示了它們如何使開發人員在熟悉的資料函式庫環境中承擔實時資料處理使用案例。專注於實用性和可用性，我們揭示了串流資料函式庫如何使實時資料分析民主化，為創新應用和洞察鋪平了道路。

無論您是經驗豐富的資料函式庫工程師還是新手開發人員，本文都將指導您釋放串流資料函式庫的全部潛力，並擁抱資料處理的未來。

本文使用的排版慣例

本文使用的排版慣例如下：

• 斜體 表示新的術語、URL、電子郵件地址、檔名和副檔名。
• 等寬字型 用於程式列表，以及在段落中參照程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。
• 等寬粗體 表示應該由使用者逐字輸入的命令或其他文字。
• 等寬斜體 表示應該替換為使用者提供的值或由上下文確定的值的文字。

使用程式碼示例

補充材料（程式碼示例、練習等）可在 https://github.com/hdulay/streaming-databases 下載。

串流基礎

英雄的旅程始於召喚。某種程度上，必須有一位引導者來告訴你：「看，你現在身處沉睡之地。醒來，踏上一段旅程。你的意識、你的存在，有一部分尚未被觸及。你在這裡感到安心？但你還沒有完全展現自我。」就這樣，一切開始了。

—喬瑟夫·坎貝爾，《反思生活藝術：喬瑟夫·坎貝爾伴侶》

串流資料函式庫的概念源自超過十年的資料處理與服務經驗。導致串流資料函式庫出現的演進，根植於更廣泛的資料函式倉管理系統歷史、資料處理以及數位時代不斷變化的需求。要了解這種演進，讓我們一起回顧那些塑造串流資料函式庫發展的重要里程碑。

資料管理的演進

20世紀末，網際網路的興起和數位資料的爆炸性成長，促使人們需要更具擴充套件性和彈性的資料管理解決方案。資料倉儲和批次導向的處理框架，如Hadoop，應運而生，以應對這個時代資料規模帶來的挑戰。

「大資料」這個術語曾經（並且仍然）用來指代的不僅是資料的規模，還包括所有儲存和處理極大量資料的解決方案。大資料無法容納在單一電腦或伺服器上。你需要將它分成較小、大小相等的部分，並將它們儲存在多台電腦中。像Hadoop和MapReduce這樣的系統變得流行，因為它們支援分散式儲存和處理。

分散式串流的出現

這導致了使用分散式串流技術將大量資料傳輸到Hadoop的想法。Apache Kafka作為這樣一種訊息服務應運而生，它被設計用來處理大資料。它不僅提供了一種在系統之間行動資料的方法，還提供了一種即時存取流動資料的方式。這一發展引發了對即時串流使用案例的新一波需求。

技術革新與挑戰

Kafka的出現標誌著串流技術的一個重要里程碑。它不僅解決了資料傳輸的問題，還開啟了即時資料處理的大門。這種即時性對於許多應用程式來說至關重要，例如金融交易監控、即時分析等。

實時資料處理的需求

隨著即時串流使用案例的增加，對即時資料處理技術的需求也隨之增加。傳統的批次處理模式已經無法滿足即時資料分析的需求。因此，串流資料函式庫開始受到關注，它們能夠提供即時資料處理和分析能力。

串流基礎與資料函式庫內外翻轉

在資料處理領域中，新技術如Apache Flink和Apache Spark的發展，成功滿足了日益增長的即時資料處理需求。這些分散式框架能夠在多台伺服器上處理資料，並提供分析結果。當與Kafka結合時，這三者共同提供了一個支援即時串流分析的解決方案。我們將在第2章中更詳細地討論串流處理器。

2010年代中期，為了提高即時資料處理的規模，出現了更簡單、更好的串流處理正規化。這包括兩個新的串流處理框架：Apache Kafka Streams（KStreams）和Apache Samza。KStreams和Samza是首批實作物化檢視（materialized views）的框架，使串流看起來更像資料函式庫。

Martin Kleppmann進一步推動了資料函式庫與串流的結合。在2015年的演講「Turning the Database Inside-Out」中，他描述了一種實作串流處理的方法，將內部資料函式庫功能外部化為即時串流。這種方法導致了更具擴充套件性、彈性和即時性的串流處理系統。

然而，串流處理的一個問題是（至今仍然是）它比批次處理更難使用。抽象層次較少，底層技術更為明顯。為了實作串流處理，資料工程師現在必須考慮資料順序、一致性、容錯性、彈性、擴充套件性等問題。這成為了阻礙資料團隊採用串流的障礙。因此，大多數團隊選擇繼續使用資料函式庫來轉換資料，並以批次方式執行資料處理，從而犧牲了效能需求。

在本文中，我們希望使串流和串流處理對熟悉資料函式庫的人來說更容易上手。我們將從Kleppmann的做法開始，討論如何將資料函式庫內外翻轉。

將資料函式庫內外翻轉

Martin Kleppmann是一位傑出的軟體開發者，他發表了發人深省的演講「Turning the Database Inside-Out」。他介紹了Apache Samza作為實作串流處理的新方法，將內部資料函式庫功能外部化為即時串流。他的思想長官力導致了將物化檢視引入串流處理的正規化轉變。

外部化資料函式庫功能

Kleppmann指出了資料函式庫中的兩個重要功能：預寫日誌（WAL）和物化檢視。事實證明，這些功能自然具有串流特性，能夠更好地即時處理資料。

預寫日誌

預寫日誌（WAL）是一種機制，允許資料函式庫確保資料的永續性和一致性。資料函式庫寫入資料的磁碟機並不提供事務支援。因此，資料函式庫需要在非事務性磁碟上提供事務支援。WAL是資料函式庫提供事務支援的一種方式，而無需具有事務性磁碟。

一個事務是指一個或多個資料函式庫操作作為單一工作單元執行的序列。這些操作可以包括資料插入（INSERT）、資料修改（UPDATE）或資料刪除（DELETE）（見圖1-1）。

-- 示範一個簡單的事務
BEGIN;
INSERT INTO users (name, email) VALUES ('John Doe', 'john@example.com');
UPDATE users SET name = 'Jane Doe' WHERE email = 'john@example.com';
COMMIT;

內容解密：

上述SQL程式碼展示了一個簡單的事務流程。首先，使用BEGIN開啟一個事務，接著執行插入和更新操作，最後使用COMMIT提交事務。這確保了操作的原子性，即要麼全部成功，要麼全部失敗。

WAL作為一個緩衝區，可以在進行新的更改時被覆寫。WAL將更改持久化到磁碟，如圖1-2所示。

在將事務儲存到磁碟時，資料函式庫遵循以下步驟：

1. 使用者端透過發出BEGIN陳述式開始一個事務。
2. 資料函式庫將一條記錄寫入WAL，指示事務已經開始。
3. 使用者端對資料函式庫資料進行更改。
4. 使用者端透過發出COMMIT陳述式提交事務。
5. 資料函式庫將一條記錄寫入WAL，指示事務已經提交。
6. 事務所做的更改被寫入磁碟。

當事務開始時，資料函式庫會將一條記錄寫入WAL，指示事務已經開始。然後，資料函式庫將對資料函式庫資料進行更改。然而，在事務提交之前，這些更改不會被寫入磁碟。此外，如果資料函式庫當機或斷電，可以從日誌中重放更改，並將資料函式庫還原到一致狀態。

WAL提供了一種機制，可以透過允許外部系統訂閱它來捕捉即時資料函式庫事務。其中一個使用案例是資料函式庫災難還原。透過讀取WAL，可以將資料複製到輔助資料函式庫。如果主資料函式庫發生故障，資料函式庫客戶端可以容錯移轉到輔助資料函式庫，該資料函式庫是主資料函式庫的副本（見圖1-3）。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 串流資料函式庫統一批次串流處理

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

此圖示展示瞭如何使用WAL將資料從主資料函式庫複製到輔助資料函式庫，並在主資料函式庫發生故障時進行容錯移轉。

內容解密：

上述Plantuml圖表展示了主資料函式庫透過WAL將資料複製到輔助資料函式庫的過程。當主資料函式庫發生故障時，系統可以容錯移轉到輔助資料函式庫，確保資料的高用性。這個過程涉及到了WAL的重要性和它在資料複製及災難還原中的關鍵作用。

資料函式庫日誌（WAL）與串流平台的關聯

在資料函式庫系統中，預寫日誌（Write-Ahead Log, WAL）機制用於確保資料的一致性和永續性。WAL 不僅提供資料還原功能，還能支援即時資料串流。客戶端可以訂閱 WAL 並將交易轉發到串流平台，供其他系統使用。這些系統可以建立與原始主資料函式庫一致的副本。串流平台如 Apache Kafka 的儲存實作模擬了 WAL 的語義，將資料函式庫的 WAL 擴充套件到外部應用和系統。

WAL 的檢查點機制與串流相關概念

當交易被提交後，WAL 不會立即清除，而是透過檢查點（checkpointing）機制定期將交易重新整理到主資料檔案中。檢查點機制有多個作用，包括確保已提交的變更被永久寫入資料檔案，減少系統當機後還原所需的資料重放量，從而加快還原過程。此外，隨著交易的提交，WAL 會不斷增長，檢查點機制有助於控制 WAL 的大小，防止其過度佔用磁碟空間。這些特性在串流處理中同樣存在。

串流平台的架構與應用

串流平台如 Apache Kafka 是分散式、可擴充套件且容錯的系統，專為處理即時資料流設計。它們提供強大的基礎設施，用於接收、儲存和處理來自多種來源的大量連續資料。大多數串流平台具有類別似資料函式庫 WAL 的分割區（partitions）結構，用於附加交易並支援水平擴充套件。這些分割區被分組為主題（topics），應用程式可以對其進行發布或訂閱操作。

串流平台中的關鍵概念

• 主題（Topic）：串流平台中的抽象概念，用於分組相關的分割區。
• 分割區（Partition）：實際儲存交易的不可變、僅追加日誌，用於捕捉和提供交易。
• 偏移量（Offset）：用於追蹤消費者在分割區中的位置，使消費者能夠按自己的節奏讀取和處理交易。

不同串流平台的比較

串流平台的工作原理

在 Kafka 等串流平台中，交易透過鍵值分配到不同的分割區，以實作平行處理。圖 1-4 展示了資料函式庫的 WAL 如何被讀取並儲存到串流平台的主題中。與直接儲存資料供查詢不同，串流平台重建了 WAL 並將交易分發到不同的分割區，使其他系統能夠建立原始資料函式庫的副本。

程式碼範例：Kafka 生產者組態

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "key", "value");
producer.send(record);
producer.close();

內容解密：

1. 組態屬性：首先建立一個 Properties 物件來組態 Kafka 生產者。主要設定包括 bootstrap.servers（Kafka 叢集的地址）、acks（確認機制）、以及鍵值序列化器。
2. 建立生產者：使用組態好的屬性建立一個 KafkaProducer 物件。
3. 建立記錄：建立一個 ProducerRecord 物件，指定主題、鍵和值。
4. 傳送記錄：呼叫 send 方法將記錄傳送到 Kafka 主題。
5. 關閉生產者：操作完成後關閉生產者以釋放資源。