大資料平臺之大資料處理系統的架構

大資料處理系統的架構介紹

Lamdba架構

Lambda 架構是一種用於處理大規模資料的設計模式，旨在結合批處理和實時處理，以應對對大量資料進行高效處理的需求。Lambda 架構的核心思想是將資料處理流程分為批處理層和實時處理層，並將它們整合在一起，以獲得高可擴充套件性和靈活性。

Lambda 架構的主要組成部分包括：

批處理層(Batch Layer)：

儲存： 使用分散式儲存系統(如 Apache Hadoop HDFS)儲存原始資料。

處理： 批處理層採用批處理引擎(如 Apache MapReduce、Apache Spark)對原始資料進行離線處理和分析。

目的： 生成離線批處理檢視，以支援全面的資料分析和查詢。

實時處理層(Speed Layer)：

儲存： 使用分散式實時資料庫(如 Apache HBase、Cassandra)儲存實時資料流。

處理： 實時處理層採用流處理引擎(如 Apache Storm、Apache Flink)對實時資料進行流式處理。

目的： 提供低延遲的、近實時的資料處理，以支援實時查詢和分析。

服務層(Serving Layer)：

儲存： 使用分散式資料庫或索引(如 Apache HBase、Cassandra、Elasticsearch)儲存批處理層和實時處理層的計算結果。

處理： 在服務層上建立查詢服務，以支援使用者查詢和應用程式查詢。

目的： 提供查詢介面，使使用者能夠檢索批處理和實時處理的結果。

Lambda 架構的優勢包括：

綜合處理： 結合了批處理和實時處理，可以滿足廣泛的資料處理需求，從離線分析到實時查詢。

容錯性： 由於資料處理被分為兩個層次，即使在實時層發生故障時，批處理層的結果仍然可用，反之亦然。

靈活性： 可以選擇不同的技術棧用於批處理和實時處理，以適應不同的需求。

然而，Lambda 架構也面臨一些挑戰，如系統複雜性、維護成本以及對兩個處理層之間一致性的管理。為瞭解決一致性問題，有時候會使用一個合併層(Merge Layer)來合併批處理和實時處理的結果。此外，近年來出現了一些替代模式，如 Kappa 架構，它更加強調使用流式處理引擎來處理所有資料。選擇 Lambda 架構還是其他模式通常取決於具體的需求和系統設計的目標。

Lambda 架構的三個層次包括批處理層、加速層(實時處理層)和服務層。這三個層次協同工作，以實現全面、實時、低延遲的大資料處理和查詢。以下是對每個層次的詳細描述：

1. 批處理層(Batch Layer)：

儲存： 批處理層使用分散式儲存系統(如 Apache Hadoop HDFS)來儲存原始資料。這些資料以不可變(immutable)的方式儲存，新的批處理任務生成的結果會追加到儲存系統中。

處理： 批處理層採用批處理引擎(如 Apache MapReduce、Apache Spark)來執行離線的、全面的資料處理和分析。這些任務可以包括資料清洗、轉換、計算聚合指標等。由於資料在這一層是不可變的，每次處理都會生成新的資料集，而不會修改原始資料。

目的： 主要目標是生成離線批處理檢視，這些檢視包含經過處理和計算的資料結果，以支援全面的資料分析和查詢。由於處理是離線的，可能需要一定的時間間隔來生成和更新這些批處理檢視。

2. 加速層(實時處理層，Speed Layer)：

儲存： 加速層使用分散式實時資料庫(如 Apache HBase、Cassandra)來儲存實時資料流。這些儲存系統具有低延遲、高吞吐量的特性，支援實時寫入和讀取。

處理： 加速層採用流處理引擎(如 Apache Storm、Apache Flink)來處理實時資料流。流處理引擎允許在資料到達時立即進行處理和計算，以提供低延遲的實時資料處理。

目的： 提供低延遲的、近實時的資料處理和計算。加速層的結果可以用於實時查詢、監控、儀表盤等實時應用場景。由於流處理是實時的，因此可以更快地響應資料變化。

3. 服務層(Serving Layer)：

儲存： 服務層使用分散式資料庫或索引(如 Apache HBase、Cassandra、Elasticsearch)儲存批處理層和實時處理層的計算結果。這些儲存系統通常用於支援快速查詢和檢索。

處理： 在服務層上建立查詢服務，以支援使用者查詢和應用程式查詢。查詢服務可以透過介面提供資料查詢功能，並從批處理層和實時處理層的結果中檢索資料。

目的： 提供查詢介面，使使用者能夠檢索批處理和實時處理的結果。服務層充當使用者與 Lambda 架構的互動點，為使用者提供全面的資料查詢能力。

Lambda 架構的整體目標是透過協同工作的三個層次，提供全面、實時、低延遲的大資料處理和查詢。每個層次都有其獨特的優勢，共同構建了一個強大而靈活的大資料架構。

lambda架構的應用

Lambda 架構的核心思想是將大資料處理流程分為批處理層和實時處理層，以實現全面、實時、低延遲的資料處理。以下是一些大資料計算框架，可以用於實現 Lambda 架構的各個層次：

批處理層：

Apache Hadoop MapReduce:

型別：分散式批處理框架。

特點：經典的大資料批處理框架，適用於離線資料處理任務。

Apache Spark:

型別：分散式批處理和流處理框架。

特點：支援離線批處理和實時流處理，提供更快的資料處理速度和高階的 API，如 Spark SQL。

實時處理層：

Apache Storm:

型別：實時流處理框架。

特點：提供低延遲的流式資料處理，適用於實時資料分析和計算。

Apache Flink:

型別：分散式流處理框架。

特點：支援事件時間處理、精確一次處理語義(Exactly-Once Semantics)等先進功能，適用於實時資料處理。

Apache Kafka Streams:

型別：流處理庫。

特點：建立在 Apache Kafka 之上，提供流處理能力，可以用於實時處理和分析。

服務層：

Apache HBase:

型別：分散式 NoSQL 資料庫。

特點：適用於實時讀寫大規模資料，提供高度可伸縮性的列族儲存。

Cassandra:

型別：分散式 NoSQL 資料庫。

特點：具有高可用性和橫向擴充套件性，適用於實時資料儲存和檢索。

Elasticsearch:

型別：分散式搜尋和分析引擎。

特點：用於實時搜尋和分析大量資料，支援全文搜尋和複雜查詢。

Apache Druid:

型別：實時分析資料庫。

特點：用於實時分析大規模資料，支援快速的查詢和聚合。

以上框架可以組合使用，形成 Lambda 架構。例如，可以使用 Apache Spark 或 Apache Flink 進行批處理，使用 Apache Storm 進行實時處理，然後將結果儲存在 Apache HBase、Cassandra 或 Elasticsearch 中供查詢服務。

事件溯源 (Event Sourcing)架構

事件溯源(Event Sourcing)是一種軟體架構設計模式，它將系統狀態的變化表示為一系列不可變的事件。每個事件都描述了在系統中發生的某個動作或狀態變化，並且這些事件按照發生的順序被記錄下來。透過儲存和重放事件，可以重建系統的當前狀態。

特點：

不可變事件： 事件是不可變的，一旦被建立就不再改變。這樣可以確保事件歷史的不變性，對系統狀態的更改都以事件的形式進行記錄。

事件儲存： 所有事件都被持久化儲存，形成事件日誌。這個事件儲存可以是資料庫、訊息佇列，或者專門的事件儲存系統。

重建狀態： 當需要獲取當前系統狀態時，可以透過重放事件日誌來重建系統狀態。透過順序處理事件，可以還原出系統的當前狀態。

時間順序： 事件按照發生的時間順序被記錄，這樣可以確保系統狀態的一致性和可追溯性。

靈活性： 事件溯源允許輕鬆實現事件回溯、版本控制、審計等功能，同時支援多檢視、CQRS(Command Query Responsibility Segregation)等架構模式。

組成部分：

聚合根(Aggregate Root)： 在事件溯源中，系統的狀態通常被劃分為多個聚合根。聚合根是一組相關聯的領域物件，負責保持領域內的一致性和完整性。

事件： 事件是對系統狀態變化的描述，包含了發生的動作、狀態變化的原因等資訊。事件是不可變的，且按照發生的時間有序記錄。

事件處理器： 事件處理器負責接收並處理事件。它們可以更新聚合根的狀態，並將事件儲存到事件儲存中。

事件儲存： 事件儲存是持久化儲存事件的地方，通常是一個高效能的資料庫或專門設計的事件儲存系統。

投影/讀模型： 為了支援查詢操作，通常會構建一個或多個投影或讀模型，用於快速查詢當前系統狀態。

工作流程：

命令觸發： 系統狀態的變化透過命令進行觸發，命令被髮送到聚合根。

聚合根處理： 聚合根處理命令，併產生相應的領域事件。

事件儲存： 事件被儲存到事件儲存中。

事件釋出： 事件被髮布給事件處理器，它們更新相應的聚合根狀態，並可能更新讀模型。

查詢： 查詢操作可以直接查詢讀模型，或者透過重放事件日誌來還原系統狀態。

事件溯源架構適用於需要追溯資料歷史、支援審計、實現事件回溯等場景，但也需要權衡系統的複雜性和效能開銷。

命令查詢分離 (Command Query Responsibility Segregation,CQRS) 架構

命令查詢分離(Command Query Responsibility Segregation，CQRS)是一種軟體架構模式，旨在將系統的讀和寫操作分離開來，使得每個部分都可以獨立演化並進行最佳化。在CQRS架構中，命令處理和查詢處理是獨立的，擁有各自的資料模型和邏輯。

特點：

分離命令和查詢： CQRS明確區分了系統的寫操作(命令)和讀操作(查詢)。每個操作有獨立的模型和處理邏輯。

獨立模型： 命令處理和查詢處理分別使用適合自身需求的資料模型。這使得可以根據每個部分的要求最佳化和演化資料模型。

解耦： CQRS透過解耦命令和查詢，使得系統更容易擴充套件、修改和維護。不同的部分可以獨立地進行演化，而不影響彼此。

靈活性： 不同的儲存和處理機制可以被用於命令和查詢部分。例如，可以使用不同的資料庫、快取或處理引擎。

更好的效能： 由於命令和查詢擁有各自的資料模型和邏輯，可以對它們進行更好的最佳化。例如，在查詢端可以建立更適合讀取的資料結構。

領域事件： CQRS通常與事件溯源(Event Sourcing)結合使用。領域事件被用於捕獲系統狀態的變更，而不僅僅是資料變更。

組成部分：

命令模型(Command Model)： 命令模型負責處理寫操作，它包含了處理命令的業務邏輯。通常，命令模型透過領域服務或聚合根來執行業務規則。

查詢模型(Query Model)： 查詢模型負責處理讀操作，它包含了處理查詢的業務邏輯。查詢模型通常用於構建用於展示的檢視或資料，支援使用者介面的查詢操作。

命令處理器(Command Handler)： 命令處理器負責接收和處理命令，並將命令傳遞給相應的命令模型。

查詢處理器(Query Handler)： 查詢處理器負責接收和處理查詢，並將查詢傳遞給相應的查詢模型。它構建查詢所需的資料結構，以滿足使用者介面或其他查詢需求。

訊息匯流排(Message Bus)： 訊息匯流排用於在不同的元件之間傳遞命令和事件。這可以是同步或非同步的訊息傳遞機制。

工作流程：

使用者傳送命令(寫請求)到命令處理器。

命令處理器呼叫命令模型處理命令，並可能產生領域事件。

領域事件透過訊息匯流排傳遞給感興趣的其他部分，如查詢模型。

查詢處理器使用查詢模型構建用於查詢的資料結構。

使用者傳送查詢請求到查詢處理器。

查詢處理器返回查詢結果給使用者。

CQRS架構適用於複雜業務規則和需求變化頻繁的系統，同時它提供了更大的靈活性和可維護性。然而，引入CQRS也增加了系統的複雜性，需要權衡使用它所帶來的利弊。

Kappa架構

Kappa 架構是一種大資料系統的設計正規化，它主張使用流式處理(Stream Processing)作為唯一的資料處理方式，而不區分批處理和實時處理。Kappa 架構的目標是簡化系統架構，提高系統的靈活性和可維護性。

特點：

統一處理模型： Kappa 架構中，所有的資料處理都透過流式處理進行，不再區分批處理和實時處理。這簡化了系統架構，使得資料處理邏輯更一致。

無批處理引擎： 與傳統的Lambda 架構不同，Kappa 架構不使用專門的批處理引擎，而是全部使用流處理引擎來處理資料。

持久化的無界流： 資料以無界流(Unbounded Stream)的形式持久化儲存，這表示資料在產生後立即可用，並且沒有固定的結束點。這與有界流(Bounded Stream)相對，有界流有一個明確的結束點，例如一個檔案。

事件溯源： Kappa 架構通常與事件溯源(Event Sourcing)結合使用，將所有的資料變更表示為事件，並透過流式處理引擎進行實時處理。

資料湖： Kappa 架構傾向於將所有原始資料儲存在資料湖中，以供後續分析和處理。這有助於保留所有歷史資料，並支援未來的查詢和分析需求。

組成部分：

流式處理引擎： 使用流式處理引擎(如 Apache Flink、Apache Kafka Streams)來處理實時資料流。流式處理引擎負責接收、處理和輸出資料流。

事件日誌： 所有的資料變更以事件的形式寫入事件日誌，例如 Apache Kafka。事件日誌是不可變的，記錄了系統中所有的資料變更。

資料湖儲存： 資料湖是用於儲存所有原始資料的地方，可以使用分散式儲存系統(如 Apache Hadoop HDFS)。

流處理應用： 在流式處理引擎上執行的流處理應用負責實時處理資料流，產生新的結果並將其寫回事件日誌。

工作流程：

資料產生： 資料產生後以事件的形式寫入事件日誌。

流處理應用： 流處理應用從事件日誌中讀取資料流，進行實時處理，產生新的事件，並將結果寫回事件日誌。

資料湖儲存： 所有原始資料和處理結果儲存在資料湖中，以支援後續的分析和查詢。

優勢：

簡化架構： Kappa 架構透過統一流處理模型，簡化了系統架構，降低了系統複雜性。

實時性： 由於所有資料處理都是實時進行的，系統具有更好的實時性和低延遲。

靈活性： Kappa 架構更加靈活，適應不同的資料處理需求，並且更容易擴充套件和維護。

事件溯源： 與事件溯源的結合使得系統能夠追溯和重放所有資料變更，提供更好的審計和故障排查能力。

Kappa 架構適用於需要實時資料處理、簡化架構、支援事件溯源的場景。然而，選擇使用 Kappa 架構還是其他架構需要根據具體的業務需求和系統特點進行權衡。

Kappa+ 架構

Kappa+ 架構是對 Kappa 架構的一種演進，目的是解決 Kappa 架構在一些特定場景下的一些挑戰，主要是與批處理相關的一些需求。Kappa+ 架構在流處理的基礎上引入了一些元素，以更好地支援離線批處理和實時流處理的結合。

特點：

統一處理模型： 與 Kappa 架構一樣，Kappa+ 依然主張使用流式處理作為唯一的資料處理方式，統一了批處理和實時處理。

增強批處理： Kappa+ 引入了增強的批處理，以滿足一些特定場景下對離線批處理的需求。這使得 Kappa+ 在某些方面更靈活。

儲存改進： Kappa+ 可能使用改進後的儲存系統，以支援更高效的批處理和流處理。這可能涉及到對儲存系統的最佳化或替換。

增強的後設資料管理： Kappa+ 引入了更強大的後設資料管理，以支援跟蹤和管理處理的狀態，包括批處理和流處理的狀態。

組成部分：

流式處理引擎： 與 Kappa 架構一樣，使用流式處理引擎(如 Apache Flink、Apache Kafka Streams)來處理實時資料流。

增強批處理： 引入了一些機制，使得批處理更加靈活和高效，以滿足一些離線處理需求。

改進的儲存系統： 可能對儲存系統進行了改進，以更好地支援批處理和流處理的需求。這可能包括更高效的儲存引擎或者更強大的索引機制。

後設資料管理： 引入了更強大的後設資料管理系統，用於跟蹤和管理處理的狀態、資料的版本資訊等。

工作流程：

資料產生： 資料產生後以事件的形式寫入事件日誌。

流處理應用： 流處理應用從事件日誌中讀取資料流，進行實時處理，產生新的事件，並將結果寫回事件日誌。

批處理： 在需要的情況下，觸發離線批處理作業，使用儲存系統中的事件日誌資料進行離線處理。

改進的儲存系統： 儲存系統可能經過最佳化，以更好地支援批處理和流處理。

後設資料管理： 使用後設資料管理系統跟蹤和管理批處理和流處理的狀態，確保處理的一致性和可追溯性。

Kappa+ 架構試圖在保留 Kappa 架構的優點的同時，透過引入一些改進和增強，更好地滿足一些特定場景下對離線批處理的需求。選擇使用 Kappa+ 還是其他架構取決於具體的業務需求和系統特點。

混合分析系統的 Kappa架構

混合分析系統的 Kappa 架構是將 Kappa 架構與混合分析需求相結合的一種架構設計。在混合分析系統中，通常需要同時支援實時流處理和離線批處理，以滿足不同業務場景下的分析和查詢需求。以下是混合分析系統的 Kappa 架構的主要特點和組成部分：

特點：

統一流處理模型： 與傳統的Lambda 架構不同，混合分析系統的 Kappa 架構強調統一的流處理模型，即將實時和離線處理都看作是流處理。

實時處理： 利用流式處理引擎(如 Apache Flink、Apache Kafka Streams)對實時資料進行實時分析和處理，以滿足對實時性要求較高的業務場景。

離線處理： 使用增強的批處理機制，透過離線批處理作業對歷史資料進行分析和處理，以支援更復雜、計算密集型的分析任務。

資料湖： 原始資料和處理結果都儲存在資料湖中，以支援後續的查詢、分析和挖掘。

後設資料管理： 引入後設資料管理系統，用於跟蹤和管理處理的狀態、資料版本資訊，確保混合分析系統的一致性和可追溯性。

組成部分：

流式處理引擎： 使用流式處理引擎進行實時資料處理，保證系統對實時資料流的低延遲響應。

增強批處理： 引入增強的批處理機制，以支援對歷史資料的複雜分析任務，滿足混合分析需求。

資料湖儲存： 將原始資料和處理結果儲存在資料湖中，可以使用分散式儲存系統(如 Apache Hadoop HDFS)。

後設資料管理： 引入後設資料管理系統，用於跟蹤和管理批處理和流處理的狀態、資料版本資訊。

工作流程：

資料產生： 實時產生的資料以事件的形式寫入事件日誌，也可能有歷史資料匯入到資料湖中。

流處理應用： 流處理應用從事件日誌中讀取資料流，進行實時處理，產生新的事件，並將結果寫回事件日誌。

增強批處理： 觸發離線批處理作業，使用儲存系統中的事件日誌資料進行離線處理。

資料湖儲存： 所有原始資料和處理結果儲存在資料湖中，以支援後續的混合分析任務。

後設資料管理： 使用後設資料管理系統跟蹤和管理批處理和流處理的狀態，確保處理的一致性和可追溯性。

混合分析系統的 Kappa 架構旨在兼顧實時性和靈活性，同時透過流處理的統一模型簡化了系統的架構。選擇使用這種架構還是其他架構需要綜合考慮業務需求、資料特點以及系統的可維護性和擴充套件性。

Lambda架構和Kappa架構的對比

特性對比

Lambda 架構和 Kappa 架構都是用於構建大資料系統的架構設計模式，它們在資料處理方式、架構特點和適用場景等方面有一些顯著的區別。以下是它們的主要特性對比：

Lambda 架構：

資料處理方式：

批處理和實時處理： Lambda 架構將資料處理分為批處理層和實時處理層，分別使用批處理引擎和實時流處理引擎。

離線和實時： 批處理層用於離線處理，實時處理層用於實時處理。

資料儲存：

批處理層儲存： 資料儲存在離線批處理引擎的儲存系統(如 Hadoop HDFS)中。

實時處理層儲存： 資料儲存在實時流處理引擎的儲存系統(如 Apache Kafka)中。

複雜性：

複雜性較高： Lambda 架構的管理和維護相對較為複雜，因為需要同時維護批處理和實時處理兩個層次。

一致性：

一致性挑戰： 由於同時存在批處理和實時處理，可能會出現資料一致性的挑戰，需要考慮如何解決。

適用場景：

複雜場景： Lambda 架構適用於複雜的大資料分析場景，需要同時滿足離線和實時處理需求的應用。

Kappa 架構：

資料處理方式：

統一流處理： Kappa 架構強調統一的流處理模型，不再區分批處理和實時處理，所有資料處理都透過流式處理引擎進行。

資料儲存：

事件日誌： 資料儲存在事件日誌中，通常使用分散式流處理引擎的儲存系統(如 Apache Kafka)。

複雜性：

簡化： Kappa 架構相對於 Lambda 架構來說更為簡化，因為不需要維護並行的批處理和實時處理層。

一致性：

一致性： Kappa 架構透過將所有資料處理視為事件流，避免了Lambda架構中的一致性挑戰。

適用場景：

實時場景： Kappa 架構更適用於實時處理場景，特別是對低延遲要求較高的應用。

共同點：

資料湖： Lambda 架構和 Kappa 架構都強調將原始資料儲存在資料湖中，以支援後續的查詢、分析和挖掘。

事件溯源： 兩者都可以與事件溯源結合使用，將所有資料變更表示為事件，實現資料追溯和重放。

後設資料管理： 都可能需要引入後設資料管理系統，用於跟蹤和管理資料處理的狀態、資料版本資訊等。