第2章資料湖概念概覽
資料湖概念的誕生，源自企業面臨的一些挑戰，如資料應該以何種方式處理和存儲。最開始，企業對種類龐雜的應用程式的管理都經曆了一個比較自然的演化周期。最開始的時候，每個應用程式會産生、存儲大量資料，而這些資料并不能被其他應用程式使用，這種狀況導緻資料孤島的産生。随後資料集市應運而生，應用程式産生的資料存儲在一個集中式的資料倉庫中，可根據需要導出相關資料傳輸給企業内需要該資料的部門或個人。然而資料集市隻解決了部分問題。剩餘問題，包括資料管理、資料所有權與通路控制等都亟須解決，因為企業尋求獲得更高的使用有效資料的能力。為了解決前面提及的各種問題，企業有很強烈的訴求搭建自己的資料湖，資料湖不但能存儲傳統類型資料，也能存儲任意其他類型資料，并且能在它們之上做進一步的處理與分析，産生最終輸出供各類程式消費。在本章中，将介紹資料湖的一些主要方面，幫助讀者了解為什麼它對企業非常重要。
2.1 什麼是資料湖
如果需要給資料湖下一個定義，可以定義為這樣：資料湖是一個存儲企業的各種各樣原始資料的大型倉庫，其中的資料可供存取、處理、分析及傳輸。
資料湖從企業的多個資料源擷取原始資料，并且針對不同的目的，同一份原始資料還可能有多種滿足特定内部模型格式的資料副本。是以，資料湖中被處理的資料可能是任意類型的資訊，從結構化資料到完全非結構化資料。企業對資料湖寄予厚望，希望它能幫助使用者快速擷取有用資訊，并能将這些資訊用于資料分析和機器學習算法，以獲得與企業運作相關的洞察力。
資料湖與企業的關系
資料湖能給企業帶來多種能力，例如，能實作資料的集中式管理，在此之上，企業能挖掘出很多之前所不具備的能力。另外，資料湖結合先進的資料科學與機器學習技術，能幫助企業建構更多優化後的營運模型，也能為企業提供其他能力，如預測分析、推薦模型等，這些模型能刺激企業能力的後續增長。
企業資料中隐藏着多種能力，然而，在重要資料能夠被具備商業資料洞察力的人使用之前，人們無法利用它們來改善企業的商業表現。
2.2 資料湖如何幫助企業
長期以來，企業一直試圖找到一個統一的模型來表示企業中所有實體。這個任務有極大的挑戰性，原因有很多，下面列舉了其中的一部分：
- 一個實體在企業中可能有多種表示形式，是以可能不存在某個完備的模型來統一表示實體。
- 不同的企業應用程式可能會基于特定的商業目标來處理實體，這意味着處理實體時會采用或排斥某些企業流程。
- 不同應用程式可能會對每個實體采用不同的通路模式及存儲結構。
這些問題已困擾企業多年，并阻礙了業務處理、服務定義及術語命名等事務的标準化。
從資料湖的角度來看，我們正在以另外一種方式來看待這個問題。使用資料湖，隐式實作了一個較好的統一資料模型，而不用擔心對業務程式産生實質性影響。這些業務程式則是解決具體業務問題的“專家”。資料湖基于從實體所有者相關的所有系統中捕獲的全量資料來盡可能“豐滿”地表示實體。
因為在實體表示方面更優且更完備，資料湖确實給企業資料處理與管理帶來了巨大的幫助，使得企業具備更多關于企業增長方面的洞察力，幫助企業達成其商業目标。值得一提的是，Martin Fowler寫過一篇很有意思的文章，在這篇文章中，他對企業資料湖的一些關鍵方面做了簡明扼要的闡述，可參考下面這個連結：
https://martinfowler.com/bliki/DataLake.html。
資料湖的優點
企業會在其多個業務系統中産生海量資料，随着企業體量增大，企業也需要更智能地處理這些橫跨多個系統的資料。
一種最基本的政策是采用一個單獨的領域模型，它能精準地描述資料并能代表對總體業務最有價值的那部分資料。這些資料指的是前面提到的企業資料。
對企業資料進行了良好定義的企業當然也有一些管理資料的方法，是以企業資料定義的更改能保持一緻性，企業内部也很清楚系統是如何共享這些資訊的。
在這種案例中，系統被分為資料擁有者（data owner）及資料消費者（data consumer）。對于企業資料來說，需要有對應的擁有者，擁有者定義了資料如何被其他消費系統擷取，消費系統扮演着消費者的角色。
一旦企業有了對資料和系統的明晰定義，就可以通過該機制利用大量的企業資訊。該機制的一種常見實作政策是通過建構企業級資料湖來提供統一的企業資料模型，在該機制中，資料湖負責捕獲資料、處理資料、分析資料，以及為消費者系統提供資料服務。資料湖能從以下方面幫助到企業：
- 實作資料治理（data governance）與資料世系。
- 通過應用機器學習與人工智能技術實作商業智能。
- 預測分析，如領域特定的推薦引擎。
- 資訊追蹤與一緻性保障。
- 根據對曆史的分析生成新的資料次元。
- 有一個集中式的能存儲所有企業資料的資料中心，有利于實作一個針對資料傳輸優化的資料服務。
- 幫助組織或企業做出更多靈活的關于企業增長的決策。
在本節中，我們讨論資料湖應該具備哪些能力。本章後續部分将會讨論和評述資料湖是如何工作的，以及應該如何去了解其工作機制。
2.3 資料湖是如何工作的
為了準确了解資料湖能給企業帶來哪些好處，了解資料湖的工作機制以及建構功能齊全的資料湖需要哪些元件就顯得尤為重要了。在一頭紮進資料湖架構細節之前，不妨先來了解資料湖背景中的資料生命周期。
在一個較高的層面來看，資料湖中資料生命周期如圖2-1所示。
上述生命周期也可稱為資料在資料湖中的多個不同階段。每個階段所需的資料和分析方法也有所不同。資料處理與分析既可按批量（batch）方式處理，也可以按近實時（near-real-time）方式處理。資料湖的實作需要同時支援這兩種處理方式，因為不同的處理方式服務于不同的場景。處理方式（批處理或近實時處理）的選擇也依賴資料處理或分析任務的計算量，因為很多複雜計算不可能在近實時處理模式中完成，而在一些案例中，則不能接受較長的處理周期。
同樣，存儲系統的選擇還依賴于資料通路的要求。例如，如果希望存儲資料時便于通過SQL查詢通路資料，則選擇的存儲系統必須支援SQL接口。如果資料通路要求提供資料視圖，則涉及将資料存儲為對應的形式，即資料可以作為視圖對外提供，并提供便捷的可管理性和可通路性。最近出現的一個日漸重要的趨勢是通過服務（service）來提供資料，它涉及在輕量級服務層上對外公開資料。每個對外公開的服務必須準确地描述服務功能并對外提供資料。此模式還支援基于服務的資料內建，這樣其他系統可以消費資料服務提供的資料。
圖2-1 資料湖的生命周期
當資料從采集點流入資料湖時，它的中繼資料被捕獲，并根據其生命周期中的資料敏感度從資料可追溯性、資料世系和資料安全等方面進行管理。
資料世系被定義為資料的生命周期，包括資料的起源以及資料是如何随時間移動的。它描述了資料在各種處理過程中發生了哪些變化，有助于提供資料分析流水線的可見性，并簡化了錯誤溯源。
可追溯性是通過辨別記錄來驗證資料項的曆史、位置或應用的能力。
——維基百科
2.4 資料湖與資料倉庫的差別
很多時候，資料湖被認為與資料倉庫是等同的。實際上資料湖與資料倉庫代表着企業想達成的不同目标。表2-1中顯示了兩者的關鍵差別。
從表2-1來看，資料湖與資料倉庫的差别很明顯。然而，在企業中兩者的作用是互補的，不應認為資料湖的出現是為了取代資料倉庫，畢竟兩者的作用是截然不同的。
2.5 資料湖的建構方法
不同的組織有不同的偏好，是以它們建構資料湖的方式也不一樣。建構方法與業務、處理流程及現存系統等因素有關。
簡單的資料湖實作幾乎等價于定義一個中心資料源，所有的系統都可以使用這個中心資料源來滿足所有的資料需求。雖然這種方法可能很簡單，也很劃算，但它可能不是一個非常實用的方法，原因如下：
- 隻有當這些組織重新開始建構其資訊系統時，這種方法才可行。
- 這種方法解決不了與現存系統相關的問題。
- 即使組織決定用這種方法建構資料湖，也缺乏明确的責任和關注點隔離（responsibility and separation of concerns）。
- 這樣的系統通常嘗試一次性完成所有的工作，但是最終會随着資料事務、分析和處理需求的增加而分崩離析。
更好的建構資料湖的政策是将企業及其資訊系統作為一個整體來看待，對資料擁有關系進行分類，定義統一的企業模型。這種方法雖然可能存在流程相關的挑戰，并且可能需要花費更多的精力來對系統元素進行定義，但是它仍然能夠提供所需的靈活性、控制和清晰的資料定義以及企業中不同系統實體之間的關注點隔離。這樣的資料湖也可以有獨立的機制來捕獲、處理、分析資料，并為消費者應用程式提供資料服務。
2.6 Lambda架構驅動的資料湖
正如我們在前面讨論的那樣，有多種處理資料的方式，它們可以被大緻地分為批處理和實時資料處理。雖然可能有這樣的場景，隻用其中一種處理方式就提供了所需的結果，但也有可能同時需要來自批處理和實時資料處理元件處理後産生的資料。這使我們遇到了将批處理結果與實時處理結果合并的問題。這個問題可由Lambda架構模式解決，細節将會在下一章中進行讨論。這裡讨論的是最原始的由Lambda架構驅動的資料湖理念。
Lambda架構作為一種模式，提供了在大型資料集上執行高度可伸縮和高性能分布式計算的方法，并且最終為批處理和近實時處理提供了一緻的資料。Lambda架構定義了能應對企業中各種資料負載的可水準擴充架構的實作方法與手段，并且具有較低的延遲預期。
圖2-2顯示了資料湖中的功能子產品。
圖2-2 資料湖中的功能子產品
Lambda架構模式的實作方式是将整個架構劃分為多個功能子產品/層（layer）。每一層都将在本章的後續部分中進行簡略介紹。
2.6.1 資料攝取層——攝取資料用于處理和存儲
快速的資料攝取層（data ingestion layer）是Lambda架構模式中的關鍵層之一。這一層需要控制将資料快速傳遞到Lambda架構的工作模型中。該層的關鍵功能如下所列：
- 該層必須具有高度可擴充性，滿足各種需求，能夠根據不同的負載情況進行伸縮。
- 該層必須具有容錯（fault tolerant）能力，提供系統可靠性和故障轉移（fail-over）能力。
- 該層必須支援多線程及多事件處理。
- 該層必須能夠快速地将所攝取資料的結構轉換為目标資料格式，這是Lambda架構處理層所要求的。
- 該層必須確定所傳遞的所有資料都以最純粹的形式供下一步處理。
2.6.2 批處理層——批量處理已提取資料
批處理層（batch layer）是Lambda架構中對已提取資料進行批量處理的層，以確定系統資源的最佳利用，同時也可将長時間運作的操作應用于資料，以確定輸出資料的高品質。輸出資料也稱為模型資料（modeled data）。将原始資料轉換為模型資料是批處理層的主要職責，其中，模型資料中蘊含了Lambda架構中服務層（serving layer）向外提供資料的資料模型。該層主要職責如下所列：
- 該層必須能在已攝取的原始資料之上執行資料清理、資料處理、資料模組化算法。
- 該層必須提供重新執行（replay/rerun）某些操作的機制，以實作故障恢複。
- 該層必須支援在已攝取的原始資料之上執行機器學習算法或資料科學處理，以産生高品質的模型資料。
- 該層可能需要執行一些其他操作，以期通過移除重複資料、檢測錯誤資料和提供資料世系視圖來提高模型資料的整體品質。
2.6.3 快速處理層——近實時資料處理
快速處理層（speed layer）将對從資料攝取層接收的資料執行近實時處理。由于處理預期接近實時，是以這些資料的處理需要快速、高效，為高并發場景提供支援和相應的精心設計，并且最終産生滿足一緻性要求的輸出結果。很多因素可以影響快速處理層的特性，這些将在本書的後面部分詳細讨論。簡單來說，該層應包含以下功能：
- 必須支援在特定資料流之上的快速操作。
- 必須能生成滿足近實時處理需求的資料模型。所有需要長時間運作的處理必須被委托給批處理模式。
- 必須有快速通路能力和存儲層的支援，這樣就不會因為處理能力而導緻事件的堆積。
- 必須與資料攝取層的批處理過程分離。
- 必須産生一個輸出模型，該模型（從某種程度上來說）可以與批處理産生的資料集合并，進一步提供增強型的企業資料。
2.6.4 資料存儲層——存儲所有資料
在Lambda架構模式中，資料存儲層（data storage layer）非常引人注目，因為該層定義了整個解決方案對傳入事件/資料流的反應。由架構常識可知，一個系統的速度最多與處理鍊中最慢的子系統一樣快，是以，如果存儲層不夠快，由近實時處理層執行的操作将會變得很慢，進而阻礙了該架構達到近實時的效果。
在Lambda的總體架構中，針對已攝取的資料有兩種主動操作：批處理和近實時處理。批處理和近實時處理的資料需求差别很大。例如，在大多數情況下，批處理模式需要執行串行讀和串行寫操作，此時使用Hadoop存儲層就足夠了，但是如果我們考慮近實時處理，需要快速查找和快速寫入，那麼Hadoop存儲層可能是不合适的（見表2-2）。為了支援近實時處理，需要資料層支援某些類型的索引資料存儲。
表2-2 Hadoop存儲層對批處理和近實時處理模式的适用情況
Lambda架構的典型功能如下所列：
- 同時支援串行讀寫及随機讀寫。
- 針對使用者的使用情況，提供合适的層次性的解決方案。
- 支援以批量模式或近實時模式處理海量資料。
- 以靈活、可擴充的方式支援多種資料結構的存儲。
2.6.5 服務層——資料傳遞與導出
Lambda架構也強調了為消費者程式提供資料傳輸服務的重要性。衆所周知，資料可以以多種方式在系統間傳遞。其中最重要的一種方式是通過服務（service）傳遞。在資料湖背景中，這些服務被稱為資料服務（data service），因為它們的主要功能是傳輸資料。
另外一種傳輸資料的方式是資料導出（export）。資料最終可導出為多種格式，如消息、檔案、資料備份等，導出的資料供其他系統消費。
資料傳輸/服務主要關注的是如何将資料轉換為預期的格式。這種格式可以強制約定為資料契約（data contract），資料服務在對外提供服務時遵循該約定。然而，在執行資料傳輸操作時，合并批量處理及近實時處理産生的資料非常重要，因為這兩類資料中都可能包含與組織機構相關的關鍵資訊。資料服務層必須保證資料與資料契約（與消費者程式約定）的一緻性。
從較高的層次來看，資料服務層應滿足下列特性：
- 支援多種機制為消費者程式提供資料服務。
- 每種支援資料服務的機制，必須與消費者程式的資料契約相容。
- 支援批量處理及近實時處理資料視圖的合并。
- 為消費者程式提供可擴充、快速響應的資料服務。
因為資料服務層的核心職責是向資料湖以外的消費者提供資料服務，出于增強資料表現的考慮，該層可能會選擇性地進行資料合并。
以上是Lambda架構的主要功能子產品，其他向Lambda架構灌入資料供其處理的功能子產品，如資料擷取層（data acquisition layer）、消息層（messaging layer）及資料攝取層（data ingestion layer）等将在本章後續小節中讨論。
2.6.6 資料擷取層——從源系統擷取資料
企業中資料格式多種多樣，可大緻分為結構化資料、半結構化資料和非結構化資料。
結構化資料的常見例子包括關系資料庫、XML/JSON、系統間傳遞的消息等。企業也非常青睐半結構化資料，尤其是E-Mail、聊天記錄、文檔等。非結構化資料的典型例子包括圖檔、視訊、原始文本、音頻檔案等。
對于這些類型的資料，部分資料可能無法對其定義模式（schema）。需要将資料轉換為有意義的資訊時，模式是非常重要的。為結構化資料定義模式的方法非常直接，但是無法為半結構化資料或非結構化資料定義模式。
資料擷取層的一個關鍵作用是将資料轉換為在資料湖中可進行後續處理的消息。是以資料擷取層必須非常靈活，能适應多種資料模式。同時，它也必須支援快速的連接配接機制，無縫地推送所有轉換過的資料消息到資料湖中去。
資料擷取層在資料擷取端由多路連接配接（multi-connector）元件構成，然後将資料推送到特定的目的地。在資料湖的例子中，目的地指的是消息層，如圖2-3所示。
圖2-3 資料擷取元件
很多技術架構可以用于建構能支援多種源系統的低延遲的資料擷取層。對于每種源系統類型，資料擷取層的連接配接都需要根據所依賴的底層架構進行特殊配置。資料擷取層會對已擷取的資料做少量轉換，其目的是最小化傳輸延遲。這裡的資料轉換指的是将已擷取的資料轉換為消息或事件，它們可以發送給消息層。
如果消息層無法到達（由于網絡中斷或消息層處于停機期間），則資料擷取層還必須提供所需的安全性保障和故障恢複機制。
為了確定該層的安全性，它應該能夠支援本地持久化的消息緩沖，這樣，如果需要，并且當消息層再次可用時，消息可以從本地緩沖區中恢複。該子產品還應該支援故障轉移，如果其中一個資料擷取程序失敗，另一個程序将無縫接管，如圖2-4所示。
圖2-4 資料擷取層元件設計
2.6.7 消息層——資料傳輸的保障
消息層其實就是資料湖架構裡的消息中間件（Message Oriented Middleware，MOM），該層的主要作用是讓資料湖各層元件之間解耦，同時保證消息傳遞的安全性。
為了確定消息能被正确傳輸到目的地，消息将會被持久化到某種儲存設備中去。被選用的儲存設備需要與消息處理需求比對（結合消息大小及數量等因素）。更進一步來看，不論是讀操作還是寫操作，消息中間件都是按隊列（queue）方式來處理的，隊列天然适合處理串行存取，機械硬碟足以應付此類I/O操作。對于那些需要每秒處理百萬級的消息的大型應用程式來說，SSD能提供更好的I/O性能。
消息層元件必須能對消息隊列進行入隊列和出隊列操作，如圖2-5所示。對于大多數消息處理架構來說，入隊列和出隊列操作對應的是消息釋出與消息消費。每個消息處理架構都提供了一系列庫函數，用于與消息隊列的資源連接配接（如topic/queue）。
圖2-5 消息隊列
任意消息中間件都支援兩類與隊列通信的方式以及topic消息結構，如下所列：
- 隊列通常用于點對點（point-to-point）通信，每個消息應該隻被某個消費者消費一次。
- topic概念經常出現于釋出/訂閱機制中，在這裡，一個消息被釋出一次，但是被多個訂閱者（消費者）消費。一條消息會被多次消費，但是每個消費者消費一次。在消息系統内部，topic基于隊列來建構；消息引擎（message engine）對這些隊列進行差異化管理，以實作一個釋出/訂閱機制。
隊列與topic都可以根據需要配置為持久化或非持久化。出于保障資料釋出安全的目的，強烈建議将隊列配置為持久化，這樣消息将不會丢失。
從較高的層次來看，消息中間件可以抽象為由消息代理（message broker）、消息存儲、topic/queue等元件組成的架構或引擎。
圖2-6中描述了消息中間件架構中的各種元件。請記住，圖2-6給出的是一種較高層次的抽象，屏蔽了很多細節。這些元件稍後将在第7章中詳細介紹。
圖2-6 消息中間件架構
2.6.8 探索資料攝取層
資料攝取層負責消費消息層中的消息，對消息做适當的轉換，從中提取所期望的資訊，然後傳輸給Lambda層供其處理。資料攝取層的輸出必須與期望的資料存儲或處理格式一緻。該層也必須保證消息以一緻性的方式消費掉，即沒有消息丢失并且每條消息至少被消費一次。
資料攝取層被期望能支援多個消費者/線程來并行消費消息。每個消費者必須是無狀态的，并且能快速處理流式資料。從消息層導出的多個資料流中的資料會源源不斷地湧入Lambda層。資料攝取層必須確定消息消費速度不低于消息生成速度，這樣消息/事件處理就不會有延遲。較慢的處理速度會導緻消息層中消息的堆積，會對系統處理消息/事件的近實時特性造成傷害。該層應支援快速消費政策，在必要時恢複因消息堆積而導緻的系統故障。
是以，該層有一個隐含的要求，即這一層需要一直保持近實時性，具有最小延遲，這樣消息層就不會堆積任何消息。為了保障近實時性，該層必須有能力持續地消費消息/事件，及對故障進行恢複。
消息消費者扮演了向Lambda層遞送消息供其處理的關鍵角色，如圖2-7所示，是以消息消費者的内部元件與資料擷取層非常相似，差别在于消息消費者知道從消息層（源）擷取的消息及發送至Lambda層（目的地）的消息的格式。消息的消費行為可能是以微批量（micro-batches）方式來處理，這樣能實作資源的最優利用，使系統效率更高。
圖2-7 消息消費者
消息消費者可能需要同時将輸出流推送到Lambda層的批處理層及快速處理層。
2.6.9 探索Lambda層
前面提到過，Lambda層由兩個子產品組成：批處理層及近實時處理層（即快速處理層）。
1.批處理層
批處理是處理海量資料的最傳統方法之一，處理任務通常是長時間執行的。随着近期的各種大資料技術的誕生，批處理越來越高效，極大地縮減了處理時間。
一般來說，批處理對要消費的資料及要産生的輸出結果非常了解。較早的時候，批處理的處理顆粒度很大，可能會在一次執行中處理整個資料集，也會用到多線程技術，并且提供了特殊的機制用來處理失效場景，以及執行一些操作流程來維護生産環境中的批處理作業。
Hadoop，作為一種大資料技術，因為其能滿足批處理的各種要求而成為首選架構，它支援建構高效可擴充的批處理任務，這是傳統批處理技術所無法比拟的。Hadoop中有兩大元件是執行批處理所需的，主要是并行處理及分布式存儲元件。Hadoop批處理已經被證明性能遠優于傳統批處理，原因如下：
1）使用經過優化的MapReduce範式的處理流程，執行速度很快。
2）順序存儲（sequential storage）有利于快速地順序讀/寫。
3）存儲備份機制（replicated storage）保證了資料的高可用性。
4）批處理任務執行期優先處理由作業排程器（job scheduler）管理的離得較近的資料。
基于Hadoop的批處理，由于具備了上面所述的這些能力，相較于傳統批處理技術有巨大的改進。這裡的分布式資料存儲及并行處理由底層的Hadoop架構處理，Mapper與Reducer任務更關注特定的資料處理。
MapReduce處理範式并不是什麼新概念，相反，它從大型機時代就已經出現在各種應用中了。該範式基于資料劃分與規則，最早源自傳統的多線程模型。其主要機制是将批處理分割為多個子任務，然後對這些處理任務的結果進行合并，最終産生整體輸出，如圖2-8所示。這樣的話，多個任務并行執行且互相獨立，各自處理各自的資料塊（partition）。這樣處理確定資料至少被處理一次，子任務的處理結果會被合并，并且結果已經去重了。由于Hadoop架構的内置功能，批處理的執行已經被證明是高度優化過的了，這使得Hadoop能處理主流的批處理問題。有了Hadoop及MapReduce，從資料進行中推導出商業智能（business intelligence）成為可能，此外也可以內建更複雜的資料科學（data science）、機器學習（machine learning）方法，用于滿足各種基于批處理的分析需求。然而這又會引發另外一個問題，我們如何滿足實時資料處理的需求？
圖2-8 MapReduce範式——批處理
有一種政策可以滿足近實時資料處理的需求，那就是使用多種架構。設計這些架構就是為了解決近實時資料處理問題。Lambda架構提供了多種機制使得可以在快速處理層中使用這些架構。
早期人們嘗試通過觸發頻繁的批處理操作來實作近實時處理，然而這種方式永遠無法到達近實時處理的預期。
2.快速處理層
快速處理層在Lambda架構中扮演近實時處理層的角色，在這裡，消息/資料被快速攝取和處理，然後儲存到存儲層。
快速處理層主要滿足資料近實時可用的要求，架構需要確定資料處理、存儲、讀取能達到近實時的預期。
為了保證近實時性，資料處理層、存儲層、服務層必須保持對等的處理速度，這樣才不至于在某個環節卡住。
已經存在一些流式處理的技術，較早的如Flume，它可以與HDFS互動，部分解決了這個問題。然而，Flume處理的是日志類型的資料，這些日志沒經過進一步處理就直接存儲到HDFS裡了。資料的最終處理是在批進行中進行的，是以它本質上不是近實時的。
讀者不難了解，依賴Hadoop的批處理，很難達到近實時處理的預期，是以需要一些另外的架構用于實作近實時處理，這些架構構成了Lambda架構的快速處理層。
最開始，這些架構是孤立的，它們沒有與Hadoop生态系統很好地內建；随着應用的普及及功能的完備，顯然這些架構需要與Hadoop生态系統內建以達到簡化資料操作與管理的目标。圖2-9顯示了準實時處理流水線（pipcline）。
![9.png]
(
https://ucc.alicdn.com/pic/developer-ecology/66b380890d1f4f479df1cb6602f25d54.png)圖2-9 準實時處理流水線
這些架構的實作機制都與Hadoop類似，都遵循MapReduce範式。隻不過它們在實作上針對近實時處理做了特殊優化。每個架構都有自己的流式資料處理及資源管理方式。它們中的大多數都建構在快速的記憶體消息傳輸功能之上，這是近實時進行中的一種有效的元件解耦方式，能将處理延遲時間降至最低。
實時處理通常依賴鍵/值（key/value）和索引類型的資料，是以需要一個強大的快速資料處理層，這樣對鍵/值及索引類型資料的處理不至于對系統的實時性造成傷害。在這裡，某些NoSQL技術扮演了重要的角色，在本章及後續章節中将會陸續介紹它們。
3.服務層
服務層在Lambda架構中扮演着向消費者提供資料的角色。服務層應支援各種資料傳輸協定。從消費者視角來看，這些協定可以分為資料推送和資料拉取兩大類。
服務層必須能從資料湖的資料存儲層消費資料，并且通過與消費者程式事先約定好的接口傳輸資料。
-
資料推送
任意向資料湖之外推送資料的機制被稱為資料推送（data push）機制。有多種資料推送機制，下面列舉了最常見的幾種：
- 資料導出（data export）：服務層必須提供資料導出所需的工具、控制及管理政策，為消費者應用程式導出與期望格式一緻的資料。該層的部分功能與ETL類似，然而不同之處在于它主要是受消費者應用需求和使用方式驅動。在底層，可能是通過由服務層排程的批處理任務來對資料湖中的資料進行抽取、轉換、加載等操作，最後将結果資料加載到目的地。服務層的此類功能可能使用了一些嵌入系統中的ETL工具來執行ETL處理。
- 資料釋出（data publish）：服務層也可以通過釋出資料到消費者應用程式訂閱的topic/queue的形式來向外推送資料。這種資料推送方式其實是點對點（point-to-point）的資料推送，遵循釋出（publish）/訂閱（subscribe）模型。因為這些向外推送的資料必須是可以釋出的消息，是以消息越小越好，以便于提高系統性能。
-
資料拉取
任意支援資料消費者從資料湖向外拉取資料的機制被稱為資料拉取（data pull）機制。下面我們來讨論幾種最常見的資料拉取機制：
- 服務（service）：資料傳輸最流行的機制之一是資料服務。這包括在資料湖上建構Web服務（REST / SOAP），這樣可以通過服務将資料暴露給消費者應用程式。這對于通過HTTP傳輸的相對較少資料的消費行為來說，很容易滿足其近實時要求。這也源于将資料作為服務的概念，在這裡，所有資料在服務中已經準備好且為可用狀态。服務請求和響應的定義必須簡潔明了，以便于能保持足夠的通用性以滿足多個消費者的需求。這也隐式意味着必須對資料通路進行高度優化，以保證具有随機通路能力、秒級以内的響應時間及可對大資料集進行處理。這些服務更适用于隻讀資料服務，而不是可更新的資料服務。
-
資料視圖（data view）：資料湖也可能實作為基于資料視圖的資料傳輸機制，各種應用程式可以連接配接到這些視圖，然後拉取資料。這種服務資料的機制已經非常普遍，因為它結合了簡單、易于維護和通路等優點。一旦資料通過資料視圖對外公開，任何獲得授權的消費者應用程式都可以通過标準驅動程式直接連接配接到這些資料視圖，以及執行任何允許的資料處理。這些視圖通常是物化視圖（materialized view）以保障執行性能，并且隔離對性能有影響的查詢，限定它們隻能在特定的表上執行。然而，物化視圖也需要進行重新整理，可以以增量或徹底重建的方式進行，這個過程被稱為重新整理周期（refresh cycle）。如果要在一個重新整理周期裡徹底重建物化視圖，則需要有對應的控制機制，以保障重新整理周期中的操作對資料服務沒有影響。傳統的做法是使用同義詞（synonym）；在最近的一些技術中是通過資料集副本來實作同樣的效果。
4.資料存儲層
Lambda架構中的資料存儲層必須提供靈活的通路機制，同時也應該對系統進行高度優化以滿足批處理及近實時處理的需求。換句話說，存儲層必須同時支援資料的順序通路和随機通路。在典型的Lambda架構中，以下功能層級直接依賴資料存儲層。
-
批處理層
從資料通路的角度來看，批處理過程需要對資料進行順序通路，并且存儲層應針對此類操作進行優化。Hadoop是一種按塊（block）讀取和寫入資料的技術，每個塊都包含了序列資料中的一部分。甚至Hadoop中的塊級通路都是按順序進行的，以確定任何批處理在磁盤上的操作速度都足夠快，即使是在旋轉式的機械磁盤（普通硬體）上。
-
快速處理層
快速處理層需要以近實時的方式對其收到的資料消息進行操作，是以它必須能随機通路存儲系統快速檢索所需的資訊，以及将處理後的資料快速寫入存儲系統。
-
服務層
服務層執行多種操作，它們對磁盤的順序和随機通路都有需要，這依賴資料傳輸本身的特性。例如，如果需要在大資料集上執行資料導出，服務層通常會觸發一個批處理程序來導出所需資料，此時主要依賴順序資料通路。如果資料傳輸以資料服務的形式進行，所需的磁盤通路必須支援随機資料通路，以確定資料服務的響應時間長度低于預期。圖2-10給出了資料通路模式示意。
圖2-10 資料通路模式
是以，從資料通路的角度來看，資料湖中的資料可分為兩大類：非索引資料（non-indexed data）和-索引資料（indexed data）。
- 非索引資料：一般來說，原始資料進入資料湖中，會順序、分塊存儲。這些資料塊也構成了資料處理的機關。因為非索引資料是順序存儲的，是以它适用于批處理，并且輸出資料也是順序存儲的。非索引資料是順序資料，是以它對基于關鍵字的檢索的支援非常有限（隻有少量存儲格式支援這種檢索）。有些資料存儲還支援某些級别的索引和分區（partitioning），以便能以最快速度定位到資料所在的位置。此類資料通常用于批處理，其目的是提高批處理的處理速度，将批處理程序遷移到資料附近，使得待處理資料的移動最小化，充分利用本地資料。這是Hadoop生态系統中MapReduce過程處理速度很快的關鍵原因之一。
- 索引資料：在維護資料湖中索引資料這個背景中，我們試圖尋找能随機尋址和通路資料的解決方案。在支援随機資料的存儲和通路模式方面，底層硬體扮演了一個至關重要的角色。正如前面内容曾經提到過的那樣，SSD非常适合這種場景。但是SSD也有它本身的問題，如成本、故障頻率、資料容量、耗電量等方面的問題，這些問題又常常迫使企業不得不考慮使用機械硬碟。在這種背景下，需要對期望達到的I/O速率進行權衡。同時，實施者也可以考慮分級存儲，例如，将高I/O資料或事務資料索引存儲在SSD中，其他資料存儲在機械硬碟中。
現今幾乎所有資料索引架構都同時支援SSD和機械硬碟。這裡介紹幾種該領域領先的資料索引架構，它們在大資料技術及Lambda架構這些背景中得到了廣泛的應用，分别是Solr和Elastic（Elasticsearch）。這兩個架構都基于Lucene引擎，Lucene是一種開源的全文索引引擎，Solr與Elastic的核心索引及檢索能力均來自Lucene，它們也都各自實作了一些額外的索引及檢索功能。這兩個架構都能保證在海量資料集上亞秒級響應，适用于快速處理層的快速資料檢索和持久化。Elastic與Solr都支援資料索引及快速檢索。
-
基于存儲的分類：當存儲系統的差異更多的與通路模式相關時，資料存儲可以根據存儲機制來分類，如圖2-11所示。
5.關系資料存儲
此類資料存儲系統是過去幾十年最流行的，關系資料是結構化資料，代表了實體（entity）間的關系。關系資料存儲（relational data store）系統多年之前就非常成熟了，在企業間被廣泛使用。直到幾年前，這些資料存儲系統還用于建構每個企業的主存儲層，幾乎所有的企業資料都儲存在關系資料存儲系統中，因為它們提供了一種非常合理的組織和管理資料的方式。
6.分布式資料存儲
雖然關系資料存儲系統在處理關系資料庫方面非常有效，但人們很快就意識到它們可能不适合處理其他類型資料的存儲。其他類型的資料包括半結構化和非結構化資料。保持關系資料存儲的可擴充性使之能适應海量資料的存儲與通路涉及複雜的處理和實踐。這些挑戰已由最近出現的一系列的分布式資料存儲（distributed data store）（以分布式檔案系統方式實作）和NoSQL（Not only SQL）解決。Hadoop已經成為現今最流行的分布式檔案系統，雖然已經有一些NoSQL資料存儲存在了，它們中的每一種隻解決了一類特定問題。所有NoSQL資料庫在分布式資料管理實作上基于類似的理念，不過它們可以進一步分為以下幾類，如圖2-12所示。
圖2-11 資料存儲
圖2-12 NoSQL資料存儲分類
圖2-12中顯示的每一類都解決了特定的資料通路及管理問題。
例如，鍵/值存儲最适合處理時鐘或機器資料，而可通路性需求則可以通過基于key的通路來完成。同樣地，列式存儲（columnar store）提供了非規範化（denormalized）的存儲機制，其中資料存儲為列或列族，而不是行，列式存儲适用于讀操作為主的場景，預計将加大對寫操作為主的場景的支援。文檔存儲（document store）主要适用于将整個文檔按key存儲的場景。這些文檔通常是JSON格式的，這些存儲系統也可以存儲JSON檔案，并提供了JSON友好的查詢引擎對外提供查詢服務。當需要海量資料集上實作亞秒級查詢，且以查詢操作為主時，索引存儲（index store）是首選。
上面介紹的每種資料存儲都有大量的相關出版物，因為它們都具有大量獨有的特性，适用于企業中海量資料處理和管理的各種場景。就資料湖而言，我們将在後面的章節中挑選若幹種資料存儲系統來展示資料存儲層的多個側面。在第5章中将介紹HBase，在第10章中，将會介紹Elasticsearch如何作為NoSQL在資料湖中使用。
2.7 總結
在本章中，從較高的層次逐個介紹了資料湖及Lambda架構的組成部分，為本書後續章節的學習奠定了基礎。之後将深入技術細節，介紹如何實作資料湖及Lambda架構。本章介紹了資料湖相關概念，以及某些關于資料擷取層、消息層、資料攝取層以及Lambda架構層（快速處理層及批處理層）的進階概念。我們同時也在某種程度上讨論了資料存儲及随機通路與随機通路之間的差異。