第3章Lambda架構：一種資料湖實作模式
在前一章中介紹資料湖的一系列概念時，粗略地提到了Lambda架構。在本章中，我們将介紹Lambda架構的一些細節，并解釋該架構模式在本書的資料湖實作方案中的重要意義。
本章雖然會盡量涵蓋Lambda架構範式的全部細節，但是并不會給出任何技術實作。這是為了保證讀者能夠首先了解這些模式的概念。我們在後續的章節中将詳細介紹該模式的技術支撐。
本章中，讀者将詳細學習Lambda架構模式。了解了該模式之後，讀者将會看到它是如何成為建構資料湖的一個不可或缺的組成部分的。
3.1 什麼是Lambda架構
Lambda架構不依賴于技術，不關心具體的技術實作，而是定義了一系列實用而完善的原則來處理大資料。Lambda架構是一種非常通用的模式，它試圖滿足大多數大資料應用程式的共性需求。這一模式允許我們同時處理曆史資料和實時資料。過去，我們使用兩種完全不同的應用程式來分别處理事務類——聯機事務處理（OnLine Transaction Processing，OLTP）資料和分析類——聯機分析處理（OnLine Analytical Processing，OLAP）資料，但這兩類程式不能混合在一起；它們獨立運作，且互相之間不通信。
下列要素說明了什麼是Lambda架構：
- 一套模式和準則。Lambda架構定義了一套面向大資料應用的模式和準則。更重要的是，它允許同時查詢曆史資料和實時新增的資料，并且獲得期望的分析視圖。
- 處理曆史資料（批處理）和實時資料。
- 技術無關和通用性。Lambda架構是一種通用的模式，完全不依賴于任何技術，而且任何技術隻要能滿足需求，都可以在Lambda架構中應用。
- Lambda架構清楚地把責任劃分到不同的功能子產品/層中。它按照層來劃分職責，完美地遵循了設計模式中的關注點分離原則。
- 領域無關。作為一種通用的模式，Lambda架構可以應用于不同的業務領域。
3.2 Lambda 架構簡史
Nathan Marz創造了Lambda Achitecture（LA）這個術語，用來描述一種通用的、可擴充的、容錯的資料處理模式。他在BackType和Twitter上收集了大量關于大資料技術的專業知識。該模式是一種概念：通過使用兩個重要元件來處理海量資料，這兩個元件分别是批處理層和快速處理層。Nathan把他的發現和經驗概括為Lambda架構，該架構需要滿足一些重要的架構設計原則，例如：
- 線性可擴充原則：它應該支援水準擴充（scale out）而不是垂直擴充（scale up），并且應該适用于不同類型的用例。
- 容錯原則：它能夠承擔彈性較大的工作負載，還應能保護系統，免于受硬體故障、軟體故障以及人為錯誤的影響。
- Backtype：讀取和更新。
- 可擴充原則：易于管理，易于擴充，易于添加新特性和資料元素。
在網址
http://lambda-architecture.net/上有很多詳細的文檔。随着大資料的出現和企業對實時分析和數字化轉型的關注，這一架構模式變得愈發重要。不過，為什麼這一模式被命名為Lambda（符号λ）尚無明确的說法。
然而，我們一直認為這個希臘字母與這一模式相關聯是因為資料來自兩個地方。批量資料和快速的流式資料代表Lambda符号的彎曲部分，然後通過服務層（線段與曲線部分合并）合并，如圖3-1所示。
圖3-1 Lambda符号
3.3 Lambda架構的原則
Nathan Marz在《Big Data：Principles and best practices of scalable realtime data systems》一書中詳細地介紹了Lambda架構模式。他提出來的架構模式主要基于以下3個原則，其中部分原則已經在上一節簡要介紹過：
- 容錯原則
- 硬體
- 軟體
- 人為
- 不可變資料（immutable data）原則
- 重新計算（re-computation）原則
下面将詳細說明每一個原則。
3.3.1 容錯原則
Lambda架構模式中包括了容錯能力，即處理硬體錯誤、軟體錯誤或人工引起的錯誤的能力。大資料應用對容錯有特殊的要求，而該模式迎合了大資料的要求，能保證系統不受資料丢失或資料損壞的影響。如果達不到這一要求，在大多數案例中，系統在遇到故障時是不可恢複的。是以該原則非常重要。
人工引起的錯誤是一種常見的錯誤。典型的就是日常操作中觸發的操作性錯誤。另外一些常見的錯誤是引入生産系統的bug，在系統長期運作以後會引發各種問題。是以系統需要經過精心設計，解決這些問題。
3.3.2 不可變資料原則
從各個源系統導入的資料應該按它們的原始資料格式來存儲。更加重要的是，這些資料本質上是不可改變的。由于資料不可改變，那麼就不會增加因人工而導緻的錯誤，也在某種程度上減少了資料的丢失與損壞。該原則允許選擇和插入，但是不允許更新和删除。為了保障資料處理速度和性能，資料是以非規範化範式來存儲的。資料不可變性使系統變得簡潔，更易于管理。
3.3.3 重新計算原則
由于資料湖中的原始資料一直處于可通路的狀态，系統始終可以通過對原始資料進行重新計算來滿足新的需求。此外，因為将資料綁定到特定模式會給重新計算帶來問題，是以資料更傾向于無模式（schema-less）的存儲。并且，将資料綁定到特定模式還會帶來開發和維護方面的開銷。
在以Lambda架構模式實作資料湖時，我們将看到這些原則是如何實作的。
3.4 Lambda架構的元件
本書前面已經提及Lambda架構的各種元件，閱讀這些章節之後，讀者肯定對它們有所了解了。本節及後續小節将會詳細介紹Lambda架構的各種元件。這裡的介紹竭力避免涉及任何具體的技術，因為當讨論至具體的功能子產品時，隻要能滿足模式的要求，就可以使用市面上任何合适的技術架構。了解每個功能子產品及其擔負的主要功能是非常有必要的，隻有深刻了解這些，才能更有效地閱讀後續章節。在資料湖背景中，Lambda架構的元件隻構成了其中的一個功能子產品，即Lambda層。下面将帶領讀者逐一了解Lambda層的各個子產品。Lambda層的主要子產品如下：
- 批處理層
- 快速處理層
- 服務層
Lambda架構的示意圖如圖3-2所示，其中顯示了該模式中的重要功能子產品。
圖3-2 Lambda架構中的元件
正如讀者從圖3-2中清晰地看到的那樣，新到達的資料被同時發送到批處理層和快速處理層。批處理層持續地對每個時間間隔内的批量資料重新計算并生成視圖。快速處理層同時也建立相應的實時視圖/快速視圖（speed view）。而服務層則對外部查詢的處理做了精心編排，查詢會同時被分發到批處理層及快速處理層，然後對結果進行合并，最後将查詢結果傳回給請求端。
一旦批處理視圖被建立，則該視圖不再考慮之後到達的新資料，這些新資料被用于建構新的實時視圖。舊的批處理視圖會一直儲存和存檔，何時被抛棄則依賴應用案例和技術實作。
處理大資料的新方法是按照圖3-3所示的資料流水線的方式，其中資料是從真實來源以最原始的格式擷取的。然後，我們基于原始資料建立适當的視圖來适配業務需求；同時根據需要來使用這些視圖。Lambda架構的核心工作是通過批處理層和快速處理層産生适當的視圖，然後服務層登場，充當使用者查詢與視圖之間的橋梁。
圖3-3 大資料流水線
3.4.1 批處理層
批處理層盡可能地按資料最原始的格式來存儲資料。由于在存儲的過程中不存在遺漏或轉換，是以，可以在不同的階段從不同的次元衍生出許多不同的用例。在批處理層中，主資料以不可變狀态存儲，可以被通路也可以被用于各種分析。因為資料是不可變的，更改和删除是被禁止的操作。資料總是被附加上一個時間戳，以便在需要某些資料時，可以用版本最新的時間戳查詢以擷取最新記錄。删除操作也是禁止的，因為很多分析都依賴這些被删除記錄的細節。
在原始資料上執行查詢會消耗大量的處理時間。為了避免因查詢細節處理導緻的延遲，系統按照一種周期性方式來處理資料，視圖經過調校盡量接近所需結果的生成和存儲格式，這種視圖稱為批處理視圖（batch view）。當批處理視圖需要重新生成時（上一次批處理之後，又有新資料進入了），那麼舊的批處理視圖會被抛棄掉。前面提到過，容錯能力是Lambda架構的核心原則之一。批處理視圖的每次重新生成，盡管是非常耗時的，也要能應對各種可能錯誤，保持系統的魯棒性。有多種不同的資料處理方法可以縮減處理時間，相比之下傳統的批處理一般要消耗幾個小時或者幾天的時間。如圖3-4所示即為Lambda架構的批處理層示意。
圖3-4 Lambda架構——批處理層
批處理層的持久化存儲需要适應大資料量，同時應該支援大規模的随機讀取。然而，它不需要支援随機寫入，因為資料是按給定的頻率批量加載的。
對于單一客戶視圖用例，圖3-5顯示了如何通過從客戶的主資料集生成所謂的批處理視圖（中間視圖）來實作批處理層。
圖3-5 單 一客戶視圖——批處理層
對于單一客戶視圖的用例，客戶資料流入批處理層，并在批處理層中維護主資料集；然後以設定的批處理時間間隔來建立批處理視圖。在需要時，服務層會查詢這些視圖，與快速視圖合并，并将結果發送給使用者。
3.4.2 快速處理層
快速處理層也稱為實時層，是為了滿足實時分析的需要。批處理層以指定的時間間隔運作，而在一個批處理運作完成和另一個批處理開始之間，業務使用者仍然希望對資料進行分析。快速處理層負責合并批處理視圖和實時資料。現在，批處理視窗可以減小，但是由于批量處理大量資料，批處理層的處理通常較為耗時，但業務不能因等待批處理層的延遲而滞後。為了實作近實時資料分析，增量資料以低延遲的方式進入快速處理層。一旦批處理層某次執行完畢，并覆寫了快速處理層中的資料，那麼實時視圖就會被抛棄，然後系統進入下一輪處理。
使用者送出查詢時，會同時向批處理層和快速處理層進行查詢，然後将結果合并，并以使用者期望的方式将查詢結果發送給使用者。
為了實作容錯性和能夠從錯誤中恢複，批處理層和快速處理層在任何時刻都可以重新計算（從原始資料恢複批處理層），復原（恢複到批處理層的前一個狀态）或重新整理（為快速處理層重新生成視圖）。
快速處理層有幾個非常重要的概念，為了實作該層的基本目标，必須了解它們：
- 增量計算（incremental computation）：使用現有的實時視圖和新增資料來建立新的實時視圖。如前文所述，這樣做是為了減少時間開銷，使得資料可以接近實時地分析。
-
最終一緻性（eventual consistency）：某些實時計算任務非常複雜，而且很耗時。此時系統應該追求快速得到問題的近似解（接近正确答案）。之後在某個時間點（通常不會延遲很久），結果變得完全正确。
快速處理層的存儲需要支援随機讀取和寫入，以滿足增量更新的需要。快速處理層确實允許資料快速變化，但與批處理層處理的大量資料（時間跨度為數月或數年）相比，快速處理層處理的資料集非常小（比如每次處理一天的資料）。
按照上一節所述的通用方法，這裡還建立了一個所謂的快速視圖（中間視圖）來滿足要求，如圖3-6所示。
圖3-6 Lambda架構——快速處理層
就單一客戶視圖而言，快速處理層的實作方式如圖3-7所示。
圖3-7 單一客戶視圖——快速處理層
當新資料流入快速處理層，新增的資料在這裡被處理并建構出合适的快速視圖。當服務層有需求時，快速視圖會與批處理視圖合并，然後結果被傳回給使用者。
1. CAP 定理
前面我們确實探讨了一些非常重要的方面（比如最終一緻性，下面将深入探讨） ，也簡要介紹了其他方面。在更詳細地解釋最終一緻性之前，需要解釋一個非常重要的定理——CAP定理（見圖3-8）。
圖3-8 CAP定理
CAP（Consistency，Availability，Partition Tolerance，即一緻性、可用性、分區容錯性）定理，也因計算機科學家Eric Brewer而稱為布魯爾定理，指出在分布式系統中三者（一緻性、可用性、分區容錯性）不能同時滿足。
——維基百科
在3個特性中，分布式系統在資料分塊時隻能滿足C（一緻性）或A（可用性）其中之一。分布式系統必然會出現網絡故障，在這種情況下，隻能接受網絡分區。表3-1中會簡要說明這3個重要方面。
**
在資料湖背景中，Lambda架構的實作也采用了CAP定理。通常在這樣的環境中，可用性與一緻性難以兼顧。基于這方面的原因，資料的一緻性最終會得以實作，不過通常情況下，資料是近似一緻的。這就是所謂的最終一緻性。我們将在接下來的部分中詳細介紹這方面的内容。
傳統的滿足ACID（Atomicity，Consistency，Isolation，Durability，即原子性、一緻性、隔離性、持久性）要求的存儲系統，比如RDBMS，選擇了一緻性和可用性。而NoSQL存儲系統，由于它們的特征更适合資料湖，遵循了BASE（Basically Available，Soft State，Eventual Consistency，即基本可用、軟狀态、最終一緻性）思想，并選擇了可用性而不是一緻性。
2.最終一緻性
最終一緻性是分布式計算中使用的一緻性模型，用來實作高可用性，基本保證如果對給定資料項不做任何更新，則最終對該資料項的所有通路都将傳回最後更新的值。
至此，讀者可以清楚地了解該保證背後的意義，即一緻性與可用性之間的較量。
分布式系統中的資料期望最終保持一緻，并随時保持可用狀态。對于資料湖來說，保證可用性比保證一緻性更重要，但這完全取決于用例。我們不能向最終使用者展示或使用不良資料，因為這會對公司品牌産生巨大沖擊。是以，用例需要經過仔細的驗證，讀者需要将這一條作為資料湖實踐的通用原則。
在資料湖（Lambda層）背景中，即使快速處理層受損（資料丢失或資料損壞），最終批處理層和服務層也将糾正這些錯誤，并通過服務層正常響應查詢并傳回結果。Lambda架構中的快速處理層隻會将資料保留一段時間，這樣批處理層和服務層可以重新開始處理資料并確定一緻性，一旦完成，快速處理層的視圖将被丢棄。
3.4.3 服務層
服務層的核心任務是響應查詢，将批處理層和快速處理層建立的視圖展示給使用者或其他系統。
除此之外，這一層還有很多精細的工作需要進行。快速處理層需要一直關注批處理層，以觀察是否完成了必要的批處理操作。這樣一來，在批處理視圖中進行批處理操作後，需要立即更新批處理層的存儲。緊接着，目前的快速處理層視圖将被丢棄，這是一種簿記行為，用以保持快速處理層存儲大小在控制範圍内。
觀察圖3-9，可以看到批處理層和服務層是如何工作的。
圖3-9 Lambda架構——服務層
當查詢到達服務層時，服務層分别向批處理層和快速處理層分發查詢。查詢執行時會檢視記錄的時間戳，并根據提供的參數擷取結果。一旦從這兩層獲得查詢結果，服務層合并這些記錄并使用各種業務邏輯進行計算，然後以系統或使用者需要的格式産生最終輸出。基于資料品質的因素，批處理層更加可靠（每個批處理操作完成後會進行下一輪重新計算），如果發生沖突，批處理層的視圖會覆寫快速處理層的視圖。
3.5 Lambda架構的完整工作原理
圖3-10中顯示了Lambda 架構的完整工作原理。
正如前文中簡要描述的那樣，主資料集在批處理層中進行維護和管理。新資料到達時，會被同時分派到批處理層和快速處理層。一旦資料到達批處理層，按照正常批處理時間間隔，每次都從頭開始重新計算并生成批處理視圖。類似地，隻要新資料到達快速處理層，快速處理層就會使用新資料生成快速視圖。在查詢到達服務層時，它會合并快速視圖和批處理視圖來生成适當的查詢結果。
生成批處理視圖後，快速視圖将被丢棄，除非有新資料抵達，否則隻需要查詢批處理視圖，因為此時批處理層中擁有所有的資料。
表3-2中列出了Lambda 架構中批處理層、快速處理層和服務層的作用及特點。
圖3-10 Lambda 架構的完整工作機制
表3-2 批處理層、快速處理層、服務層的作用及特點
3.6 Lambda架構的優勢
因為Lambda架構有很多優勢，是以我們選擇使用它來為企業建構資料湖。Lambda架構的典型優勢如下：
- 資料以原始格式存儲。是以，隻需要建立新的批處理視圖和快速視圖，就可以随時将新的算法、分析方法或者業務用例應用于資料湖。傳統資料倉庫最大的優點之一是資料會被清洗和存儲。正因為這一點，新的用例需要更改資料模式，這通常很耗費時間和精力。
- Lambda架構的重要原則中包括了重新計算，這有助于糾正錯誤，而不會有太大的額外開銷。随着越來越多的資料進入資料湖，資料丢失和損壞的代價難以承受。因為可以重新計算，是以可以在任何時候重算、復原或重新整理資料來糾正這些錯誤。
- Lambda架構将不同的職能劃分為定義明确、邊界清晰的功能子產品/層。這樣各層就可以使用不同的技術，并且可以采用不同的方法來優化這些功能，同時對其他層沒有任何影響。這些層中使用的技術，包括存儲技術，都可以随時替換為更好的解決方案，而不會有太多的麻煩。
- Lambda架構是一個可插拔的架構。當需要添加一個新的源資料類型或者已經接入已有類型源系統時，該架構可以接入這些源系統而無須做太多改變。
3.7 Lambda架構的劣勢
選擇Lambda架構來建構企業級資料湖，如果在某些方面沒有考慮充分，确實會引入一些該架構的先天劣勢。下面列舉部分劣勢：
- 由于包含幾個不同的層，Lambda架構通常被認為很複雜。必須經過充分的思考和操作以及付出一定的代價來保持各層之間的資料同步。
- 由于批處理層和快速處理層都是分布式的，且實作機制截然不同，維護和支援起來相當困難。
- 要建構基于Lambda架構的資料湖，必須掌握大量的技術。招聘掌握這些技術的人并非易事。
- 用開源的技術來實作Lambda架構并部署在雲環境中并不容易。為了避免這種情況，使用雲計算技術可以很好地實作Lambda架構，但是這樣做，企業等于是把自己和某個雲計算供應商綁定到一起，這被認為是一種先天的不足。
- 盡管這種架構模式已經存在了相當長的一段時間，所用到的這些工具仍處于快速發展和演化中，還不夠成熟。不過，随着雲計算的加速發展和創新，很快就會出現成熟的解決方案和工具。
- 目前，持續內建（CI）/持續傳遞（CD）已經是一種平常的要求。跟該領域的其他工具類似，持續內建/持續傳遞的工具也不成熟，是以很難支援太多自動化操作。
- 系統假設可能需要大量的硬體元件。從技術上講，可以使用低端硬體元件，但是對于企業級使用者來說，供應商通常會提供高端産品，這是企業和供應商之間長期以來約定成俗的供應模式。
- 相同的工作要實作兩次（在批處理層和快速處理層），這也是Lambda架構模式一直被诟病的一點。
3.8 Lambda架構技術概覽
如同前文簡要介紹的那樣，Lambda架構是有定義良好的原則的模式，而且是與技術無關的。具體到各個元件/層，我們可以引入任何技術來完成所需工作。
随着各種雲計算供應商的出現，甚至可以在雲環境中獲得現成的元件（許多是依賴雲環境的），更甚者，這些元件已經實作了Lambda架構。在本書中，我們将建立一個實際的資料湖，其中Lambda模式隻包含一個層，叫作Lambda層。
由于有非常多的技術可供選擇，後面每章中技術架構的選擇會讓人感覺比較主觀。在每層中選擇一種新技術時，我們都會給出選擇的理由，同時也對其他架構保持開放。我們還将簡略介紹類似技術架構，以便在需要時讀者可以自行進行替換。話雖如此，但實際上我們使用標明的技術架構來實作資料湖。本書的第二部分将詳細介紹每一項技術，然後在第三部分中，這些技術會被配套使用，用于建構資料湖。
3.9 應用Lambda
企業級資料湖是Lambda架構模式的應用案例之一。本書将更為詳細地讨論這個話題。事實上，也有其他用例應用該模式，本節也會嘗試盡量涵蓋這些案例。
3.9.1 企業級日志分析
該模式的一個非常常見的用例是日志的擷取及分析。ELK（Elasticsearch，Logstash，Kibana）技術棧在該領域比較領先，但是Lambda模式也可以很好地勝任該任務。日志可以是傳統的應用程式日志，也可以是各種軟體或硬體元件生成的各種日志。當需要企業級的日志管理和分析能力時，Lambda模式的确是一個不錯的選擇。這些日志的量很大，生成速度也很快。同時，這些日志都是不可變的，而且确實需要提供指令以便分析師（應用程式開發人員和安全資料科學家可以利用這些資料來發現安全威脅）使用這些日志。
使用Lambda層中重要的層（接下來的内容中将詳細介紹批處理層和快速處理層）來校驗這些實時日志，同時也可以幫助了解過去的日志，以提供實時的洞察力。研發團隊可以根據分析結果采取主動的行為。例如，應用程式的開發人員可以發現程式錯誤，而安全分析人員可以評估安全方面的威脅。
除了用日志分析來檢測某些異常情況之處，還可以使用這些資料來做分析和審計。例如，在網站營運的場景中，Google Analytics的資料會導入資料湖中，并用來發現一些趨勢，這将有助于改善網站營運狀況。
3.9.2 擷取和分析傳感器資料
随着物聯網（Internet of Things，IoT）應用的日益增加，企業使用的傳感器也越來越多。這些日漸增多的傳感器産生了海量的資料，要從中提取出有用的資訊卻非常棘手。使用具有Lambda層的資料湖可以為使用者提供一個可擴充的解決方案，以便對這些海量的傳感器資料進行實時分析。
3.9.3 電子郵件平台實時統計
對企業來說，電子郵件平台現在起着非常重要的作用。因擁有大量來自業務應用和社交平台的資料，電子郵件營銷（E-Mail marketing）平台的作用也舉足輕重。很多電子郵件平台都可以跟蹤每一封郵件的狀态，比如打開、連結點選等。利用這些海量的跟蹤資料，将其作為實時統計資料提煉出來，會有助于營銷團隊更好地選擇目标客戶并提供差異化的郵件内容。目前，主流電子郵件平台已經具備了對内容進行A/B測試的功能，這部分測試資料非常重要，營銷團隊可以根據它更好地準備營銷郵件的内容。
3.9.4 實時賽事分析
很多比賽中可以利用曆史的批處理視圖和目前比賽的實時資料向觀衆呈現多元度的統計和分析。
批處理層可以持續進行批量資料處理，準備好各種批處理視圖，将這些視圖與目前的比賽結合起來，可以推測和展示目前比賽中運動員取得的成績。以闆球為例，在比賽進行時，球員可能取得不同的成績。比如在測試中取得了1000分，這個成績就可以在比賽時呈現給觀衆。
3.9.5 推薦引擎
各種商業推薦引擎同時使用了來自各種業務應用的曆史資料及目前的實時資料，大多數時候是終端使用者在網站上的行為資料。
3.9.6 安全威脅分析
日志可以從各種硬體和軟體的元件中（包括業務應用）收集，把這些日志與過去的資料集進行對比可以用來分析安全方面的威脅。例如，根據分析的情況，可以采取不同的認證機制。比如說，可以把認證機制加強到雙因子認證；如果在幾分鐘内反複收到來自某地的請求，就可阻塞這些請求并送出給人工審查，以決定是否授權執行目前事務。
3.9.7 多管道使用者行為分析
Lambda架構也可以用來進行多管道使用者行為分析。比如分析使用者的購物行為、過去的消費情況、社交行為等，然後用這些資料來進行精準營銷。同時，基于對各種A/B測試的結果進行分析，營銷團隊就能采取恰當的方式來投放廣告郵件。
3.10 Lambda架構運作範例
Lambda架構已經在業界取得很多成功的應用，下面是其中一些案例：
- Twitter：例如采用改良版的Lambda架構對推文進行情感分析。
- Groupon：多類企業應用。
- Crashlytics：使用Lambda架構的批處理層和快速處理層進行有效的移動端資料分析，産生有意義的分析結論。
- Stack Overflow：一個知名的問答論壇，擁有龐大的使用者社群和豐富的活動。Lambda架構被用來建立一個向登入使用者推薦問題的闆塊。還有很多其他的資料分析，比如用批處理視圖來分析投票資料。
- Flickr Magic View：修訂版的Lambda架構通過結合批量計算和實時計算來建立一個神奇的視圖（可參考code.flickr.com）。
3.11 Kappa架構
在本書中使用Lambda架構來建構資料湖的一個主要層（即Lambda層）。然而，讀者也需要了解另一個簡化版的Lambda架構，這個被熱議的架構叫作Kappa架構。它和Lambda架構有着或多或少的相似之處，隻是出于簡化考慮，去掉了批處理層，隻保留了快速處理層。其主要思想是避免從頭開始進行批處理層計算，嘗試把這些計算完全放在實時計算或快速處理層。如前文所述，Lambda架構的一個缺點是必須編碼并運作同樣的邏輯兩次，但Kappa架構避免了這個問題。
一圖勝千言，圖3-11中将Kappa架構和Lambda架構放在一起進行比較，讀者可以清楚地看到在Kappa架構中唯一缺失的部分是非常重要的批處理層。
圖3-11 Kappa架構（左）與Lambda架構（右）比較
我們認為，即使非常複雜，Lambda架構仍然是建構資料湖的必經之路。同時也希望通過圖3-11為讀者提供另一個視角，讓讀者能夠深入到實作方案中去，這就是為什麼要簡單地介紹Kappa架構。
Lambda架構中存在一個批量處理層是有原因的，為了解決這方面的問題，Kappa引入了新的技術架構，這些技術架構能夠對大量資料進行相關處理。我們認為，在Kappa架構中，Lambda架構中的批量處理層和快速處理層被融合在了一起。實際上，我們也可以在Lambda架構中使用這些新技術，并仍然保持層次分離和責任清晰劃分。
3.12 總結
在本章中，詳細介紹了Lambda架構。在本書的資料湖實作方案中，Lambda層（Lambda架構的一種實作）是不可或缺的一部分。
本章隻介紹了理論層面的Lambda架構，并未涉及具體技術。希望讀者能明白，在該模式中，任何技術都能用來實作該架構各個層的功能。下一章開始介紹各種技術以及這些技術的适用場景。
本章前幾節對Lambda架構進行了簡要介紹，後幾節詳細介紹了構成Lambda架構的多個功能子產品/層。同時，還闡述了該模式的優缺點，并全面而詳盡地描述了這個模式。
希望讀者現在已經對資料、資料湖和Lambda架構的背景知識有了充分的了解。讀者在下一章将會了解如何為企業實作資料湖。