《離線和實時巨量資料開發實戰》（二）巨量資料平臺架構 & 技術概覽

前言

接著上一章 構建巨量資料開發知識體系圖譜，本次繼續分享邦中老師的《離線和實時巨量資料開發實戰》讀書筆記 。到底什麼樣的平臺才能算是巨量資料平臺呢？帶著這個問題，我們開始今天的內容 ( •̀ ω •́ )✧

什麼是資料平臺呢？或者更時髦點，什麼是巨量資料平臺呢？目前業界並沒有對資料平臺的精確定義，但通常所說的資料平臺主要包含以下三部分：

• 資料相關的工具、產品和技術：比如批次資料採集傳輸的 Sqoop 、離線資料處理 Hadoop 和 Hive 、實時流處理的 Storm、Spark 以及資料分析的 R 等；
• 資料資產：不僅包含公司業務本身產生和沉澱的資料，還包括公司運作產生的數（如財務、行政），以及從外界購買、交換或者爬蟲等而來的資料等；
• 資料管理：有了資料工具，也有了資料資產，但是還必須對它們進行管理才能讓資料產生最大價值並最小化風險，因此資料平臺通常還包括資料管理的相關概念和技術，如資料倉儲、資料建模、資料品質、資料規範、資料安全和後設資料管理等。

上面是對資料平臺邏輯範疇上的一個劃分，實際上資料平臺從資料處理的時效性角度，通常還是分為 離線資料平臺 和 實時資料平臺。

1. 離線資料平臺通常以天為典型的資料處理週期，資料延遲也是以天為單位。離線資料平臺的資料應用主要以「看」為主，就目前業界的資料現狀來看，離線資料平臺還是資料平臺的主戰場。

2. 但是隨著巨量資料應用的日益深入以及人工智慧浪潮的興起，產品的智慧化趨勢越來越明顯，資料的實時化、線上化也對資料平臺的實時性提出了越來越高的要求，從剛開始分鐘級別延遲到目前的秒級甚至毫秒級延遲，實時資料平臺越來越得到重視，挑戰也越越大，當然也變得越來越主流，隨著 Spark、Flink、Beam 技術的發展，未來有一天也許將會顛覆離線資料平臺的技術和架構。

接下來就是介紹資料平臺，出於邏輯清晰以及技術相關性考慮，將主要從 離線資料平臺、實時資料平臺以及資料管理 三個方面來對資料平臺相關的概念和技術進行介紹。

一、離線資料平臺的架構、技術和設計

對於公司的管理者、一線業務人員來說，經常需要回答的問題是：當前和過去 個季度或者一個月的銷售趨勢如何？哪些商品熱銷？哪些商品銷售不佳？哪些客戶在買我們的產品？管理者和業務人員需要不停地監控這些業務指標，並有針對性地根據這些指標調整業務策略和打法，如此反覆，形成閉環，這就是資料化運營的基本思路。

而這類分析和「看」的需求正是離線資料平臺所擅長的，這類分析性的需求，資料的時效性並不是強需求，當天的資料有了也好，即使沒有，影響也不大，離線的資料技術和工具已經發展很多年了，開源的解決方案和商業性的解決方案也有很多，已經能夠很成熟地解決此類問題。

離線資料平臺是構建公司和企業資料平臺的根本和基礎，也是目前資料平臺的主戰場。

1.1 離線資料平臺的整體架構

離線資料平臺通常和 Hadoop Hive 、資料倉儲、 ETL 、維度建模、 資料公共層等聯絡在一起。

Hadoop 出現之前，資料倉儲的主要處理技術是商業化資料庫，比如微軟的 SQL Server、甲骨文的 Oracle、 IBM DB2 等。隨著巨量資料的興起以及資料量的持續爆炸和指數級別增長，Hadoop 以及 MapReduce、Hive 等巨量資料處理技術才得到越來越廣泛的應用和接受。

1.2 資料倉儲技術

1. OLTP 和 OLAP

資料倉儲是隨著資料分析的需求逐漸發展起來的，最初的資料分析和報表都是基於業務系統的資料庫完成的，也就是 OLTP 資料庫，如商業性的 Oracle 、MS SQL Server 和開源的MySQL 等關聯式資料庫。

OLTP 的全稱是 Online Transaction Processing ，顧名思義， OLTP 資料庫主要用來進行事務處理，比如新增一個訂單、修改一個訂單、查詢一個訂單和作廢一個訂單等。 OLTP據庫最核心的需求是單條記錄的高效快速處理，索引技術、分庫分表等最根本的訴求就是解決此問題。

• 而這個和資料分析的需求是天然相反的，資料分析通常需要存取大量的資料，單條資料的分析沒有任何意，資料分析不僅需要存取大量的資料，還要對其進行頻繁的統計和查詢，很快資料庫管理員發現這些統計分析請求佔用了大量資料庫的資源，已經嚴重到影響生產系統的效能。
• 於是隔離這些資料分析請求到單獨的備庫或者完全複製一個新的資料庫供資料分析人員使用是自然而然的選擇。

解決了對生產庫的影響問題後， OLTP 資料庫管理員很快發現備庫和複製庫還是不能滿足資料分析人員的需求，尤其是在效能方面。大量的資料存取通常需要全表掃描，頻繁而且通常又是並行地全表掃描會造 OLTP 資料庫響應異常緩慢甚至宕機，必須有新的理論支撐和技術突破才能夠滿足這些分析請求。

於是 OLAP 資料庫應運而生，它是專門的分析型資料庫 ，是為了滿足分析人員的統計分析需求而發展起來的。

• OLAP 資料庫本身就能夠處理和統計大量的資料，而且不像 OLTP 資料庫需要考慮資料的增刪改查和並行鎖控制等 。OLAP 資料一般只需要處理資料查詢請求，資料都是批次匯入的，因此通過列儲存、列壓縮和點陣圖索引等技術可以大大加快響應請求的速度。

2. 分析型資料庫

分析型資料庫面對的主要是分析師和業務分析人員對巨量資料集的統計和聚合操作，其架構、設計和原理和傳統資料庫產品（ OLTP 資料庫）截然不同 。通常來說，資料倉儲產品一定是分散式的，但是其和 OLTP 資料庫的分散式要解決的問題有著明顯的不同。 OLTP 資料庫的分散式（如分庫分表等技術）主要是為了解決海量單條資料請求的 壓力，其主要目的是把所有使用者請求均勻分佈到每個節點上，而 OLTP 的分散式是將使用者單次對巨量資料集的請求任務分配到各個節點上獨立計算然後再進行彙總返回給使用者。

此外， OLAP 資料庫一般採用列式儲存，而 OLTP 通常採用行式儲存。

• 所謂列式儲存就是將表的每列一列一列地儲存在一起，而不是像行儲存一樣按行把所有欄位儲存在一起。
• 對於資料庫表來說，列的型別是固定的，所以列儲存可以很容易採用高壓縮比的演演算法進行壓縮和解壓縮，磁碟的 I/O 會大大減少 。
• 列儲存非常適合巨量資料量統計查詢的應用場景因為分析統計常常是針對某列或某些列的，列儲存的資料庫產品只需讀出對應列並處理即可，而不是讀出整個表的所有行進行處理。

3. Hadoop 資料倉儲

隨著隨著這些年 Hadoop 的完善和 Hadoop 生態系統的崛起， 短短几年間 ，基於 Hadoop 資料倉儲已經完全佔據了主賽道，尤其是在網際網路公司內，基於 Hadoop 的資料倉儲基本是標配。

Hadoop 的內在技術基因決定了基於 Hadoop 的資料倉儲方案（目前主要是 Hive 非常容易擴充套件（可以很容易地增加節點，把資料處理能力從 GB、TB 擴充套件 PB 甚至 EB ），成本也非常低廉（不用商業昂貴的伺服器和儲存，只需要普通的硬體即可， Hadoop 框架會進行容錯處理），這兩點也是 Hadoop 在網際網路公司內日益流行的關鍵因素。

• 基於 Hadoop 的資料倉儲解決方案，尤其是 Hive ，面臨最大的挑戰是資料查詢延遲（Hive 的延遲一般是在分鐘級，取決於 Hive SQL 的複雜度和要處理的工作量，很多時候甚至需要執行幾個小時 。當然 ，對於簡單的以及小資料量的 Hive SQL ，也可能幾秒鐘就返回結果）。

但是巨量資料和雲端計算是未來，未來的業務系統也都會執行在雲端，不管是私有云、公有云或者混合雲。雲端也決定了未來的架構肯定是分散式的，能夠近似線性擴充套件的，基於此，作者認為基於 Hadoop 和類 Hadoop 的資料倉儲解決方案未來將會成為主流和標配，不管是對於網際網路公司來說，還是傳統企業來說。

1.3 資料倉儲建模技術

從資料倉儲概念誕生以來，在資料倉儲領域，存在兩種得到廣泛認可的方法來構建資料倉儲。這兩派的代表人物分別是 Bill Inmon 和 Ralph Kimball, Bill Inmon 被稱為「資料倉儲之父」，而 Ralph Kimball 被稱為「商業智慧之父」。

從這兩種觀點誕生以來，圍繞「哪種架構最佳」的爭論一致沒有休止，人們各抒己見，但是一直無法形成統的結論，就像「哪種程式語言是最佳的程式語言」一樣，這可以稱為資料倉儲領域的「宗教戰爭」 。

1. Ralph Kimball 建模方法論

Kimball 對資料倉儲的理論貢獻都與維度設計和建模有關。維度建模將客觀世界分為度量和上下文。

• 度量是由機構的業務過程以及支援它們的源系統來捕捉的，常以數值形式（如訂單金額、庫存數量等） 出現，維度建模理論稱它為事實；
• 事實由大量文字形式的上下文包圍著，而且這些上下文常被直觀地分割成多個獨立的邏輯塊，維度建模稱之為維，維描述了度量的5個W (When、Where、What、Who、Why ）資訊，比如什麼時間下單、何種方式下單、買的什麼、客戶是誰等。

利用維度建模理論建模的 Kimball 資料倉儲常以星形架構來呈現，在星形架構中間的是事實表，事實表周圍的則是各個角度的維度表。

在維度建模中，由於星形模式緊貼業務過程，非常直觀和符合業務人員的視角，因此被廣泛和大量使用，星形模式也是 Kimball 對資料倉儲建模的一大貢獻。

Kimball 對資料倉儲建模理論的第二大貢獻是基於維度的 「匯流排體系架構」 。實際專案中，企業的業務過程通常是多樣性和複雜的，存在於多個業務主題，匯流排體系架構和一致性維度一起保證了多個主題的事實表和維度表能夠最終整合在一起，提供一致和唯
一的口徑給業務人員。

採用 Kimball 建模理論的資料倉儲體系架構如圖所示：

可以看出， Kimball 維度建模的主題以星形架構為主，主題和主題之間則用一致性維度和企業匯流排體系架構來保證資料倉儲的整合和一致性。

2. Bill Inmon 建模方法論

在資料倉儲領域， Bill Inmon 是第一個提出來 OLAP 和資料倉儲概念的人，所以被稱為資料倉儲之父」 。Bill Inmon 撰寫了大量介紹其資料倉儲方法的文章，他認為資料倉儲是 「在企業管理和決策中面向主題的、整合的、與時間相關的、不可修改的資料集合」。

與其他資料庫應用不同的是，資料倉儲更像一種過程，對分佈在企業內部各處的業務資料的整合加工和分析的過程，而不是一種可以購買的產品，這就是他所說的「企業資訊化工廠」。

Inmon 的企業資訊化工廠包括源頭系統、準備區、 ETL 、企業資料倉儲、資料市集等，而企業資料倉儲是企業資訊化工廠的樞紐。不同於 Kimball， Inmon 認為企業資料倉儲應為原子資料的整合倉庫，應該用 第三正規化 和 ER 理論而非維度建模的事實表和維度表來建模。

Inmon 的企業資訊化工廠涉及了「資料市集」的概念，所謂「集市」，就是部門級的資料倉儲。 對於資料市集來說， Inmon 主張從企業資料倉儲中提取所需要的資料，從而保證資料的一致性 這樣帶來的問題是必須先有企業資料倉儲才可能開始建立部門級的資料市集，這是 Inmon 資料倉儲架構和 Kimball 資料倉儲架構的第二個主要不同。同時， Inmon 也認為應該用 Kimball 的維度建模理論來構建資料市集。

3. 資料倉儲建模實踐

從上述對兩者資料架構的介紹可以看出， Inmon 的方法是一種由上而下（ top-down ）的資料倉儲構建方法，其主張首先要對企業資料倉儲進行總體規劃，並將不同的 OLTP 資料集中到面向主題、整合的、不易失的和時間變化的企業資料倉儲中。資料市集應該是資料倉儲的子集，每個資料市集都是為獨立部門專門設計的。

Kimball 方法則相反，其是自下向上的（ down-top )。 Kimball 認為資料倉儲是一系列資料市集的集合，企業可以通過一致性的維度表和「企業匯流排架構」來遞增式整合各個資料市集， 從而構建整個企業的資料倉儲。

一句話總結它們的區別：

Kimball : let people build what they want when they want it, we will
integrate them it all when and if we need to.

Inmon: don’t do anything until you have designed everything.

Inmon 的方法部署和開發週期較長，但是容易維護而且高度整合；而 Kimball 的方法可以迅速響應業務需求，快速構建一個資料倉儲，但是後期整合和維護較為麻煩。兩者沒有絕對的對與錯，只有不同階段和不同場景下的利弊權衡。

4. 資料倉儲邏輯架構設計

離線資料倉儲通常基於維度建模理論來構建，但是除此之外，離線資料倉儲通常還會從邏輯上進行分層。資料倉儲的邏輯分層也是業界的最佳實踐。

離線資料倉儲的邏輯分層主要是出於如下考慮：

隔離性：使用者使用的應該是資料團隊精心加工後的資料，而不是來自於業務系統的原始資料。這樣做的好處之一是，使用者使用的是精心準備過的、規範的 、乾淨的從業務視角的資料，非常容易理解和使用；好處之二是， 如果上游業務系統發生更甚至重構（比如表結構、欄位 業務含義等），資料團隊會負責處理所有這些變化最小化對下游使用者的影響。

效能和可維護性：專業的人做專業的事，資料分層使得資料的加工基本都在資料團隊，從而相同的業務邏輯不用重複執行，節省了相應的儲存和計算開銷，畢竟巨量資料也不是沒有代價的。此外，資料的分層也使得資料倉儲的維護變得清晰和便捷，每層只負責各自的任務，某層的資料加工出現問題，只需修復該層即可。

規範性：對於一個公司和組織來說，資料的口徑非常重要，大家談論一個指標的時候，必須基於一個明確的、公認的口徑，此外表、欄位以及指標等也必須進行規範。

資料倉儲一般分為如下幾層：

ODS 層： 資料倉儲源頭系統的資料表通常會原封不動地儲存一份，這稱為 ODS ( Operation Data Store ）層， ODS 層也經常會被稱為準備區（ staging area ），它們是後續資料倉儲層（即基於 Kimball 維度建模生成的事實表和維度表層，以及基於這些事實表和明細表加工的彙總層資料）加工資料的來源，同時 ODS 層也儲存著歷史的增量數量或者全量資料。

OWD 和 DWS 層： 資料倉儲明細層（ Data Warehouse Detail, D WD ）和資料倉儲彙總層（ Data Warehouse Summary, DWS ）是資料平臺的主體內容。 DWD 和 DWS 的資料是 ODS 層資料經過 ETL 清洗、轉換、載入生成的，而且它們通常都是基於 Kimball 的維度建模理論來構建的，並通過一致性維度和資料匯流排來保證各個子主題的維度一致性。

ADS 層： 應用層主要是各個業務方或者部門基於 DWD 和 DWS 建立的資料
集市（ Data Mart ，以下簡稱 DM ），資料市集 DM 是相對於 DWD / DWS 的資料倉儲（ Data Warehouse ，以下簡稱 DW ）來說的。 一般來說，應用層的資料來源於 DW層，但原則上不允許直接存取 ODS 層的。此外，相比 DW 層，應用層只包含部門或者業務方自己關心的明細層和彙總層資料。

採用上述 ODS 層→ DW 層→應用層的資料倉儲邏輯分層架構如圖所示：

二、實時資料平臺的架構、技術和設計

離線資料平臺產出資料的週期一般是天，也就是說，今天看到的是昨天的資料，對於大部分的分析和「看」資料的場景來說，這種 T+1 的離線資料可以滿足業務分析的需求，但是隨著業務運營日漸精細化，對資料的時效性要求越來越高，越來越多的業務場景需要馬上看到業務效果，尤其是在業務促銷活動等（典型的如雙 11 大促、 618 大促等）場景下。

更重要的是，隨著人工智慧浪潮的興起，實時的資料已經不是最好，而是必須。資料也不僅僅在分析和「看」，而是和演演算法一起成為生產業務系統的一部分。

2.1 實時資料平臺的整體架構

實時資料平臺的支撐技術主要包含四個方面：實時資料採集（如 Flume ），訊息中間（如 Kafka ）、流計算框架（如 Strom 、Spark、 Flink、 Beam 等），以及實時資料儲存（如列族儲存的 HBase）。 目前主流的實時資料平臺也都是基於這四個方面相關的技術搭建的。

實時資料平臺首先要保證資料來源的實時性。資料來源通常可以分為兩類：資料庫和紀錄檔檔案。對於前者，業界的最佳實踐並不是直接存取資料庫抽取資料，而是會直接採集資料庫變更紀錄檔。

對於 MySQL 來說就是 binlog ，它是 MySQL 的資料庫變更紀錄檔，包括資料變化前和變化的狀態。

資料採集工具（如 Flume ）採集的 binlog 事件，其產生速度和頻率通常取決於源頭系統。它和下游的實時資料處理工具（比如 Storm、Spark、Flink 等流計算框架和平臺）處理資料的速度通常是不匹配的。另外，實時資料處理通常還會有從某歷史時間點重新啟動以及個實時任務都要使用同一源頭資料的需求，因此通常還會引人訊息中介軟體來作為緩衝，從而達到實時資料採集和處理的適配。

實時資料儲存根據下游資料使用的不同方式通常放在不同的資料儲存內，對於資料在服務（即資料使用方傳入某個業務 ID ，然後獲取到所有此 ID 的相關欄位），通常放在 HBase ；對於實時資料大屏，通常放在某種關聯式資料庫（如 MySQL ）內，有時為了提高能並減輕對底層資料庫的壓力，還會使用快取資料庫（如 Redis ）等。

2.2 流計算技術

流計算的開始流行和被大家所接受始於 2011 年左右誕生的 Storm ，Stοrm 作為「實時的Hadoop 」迅速被大家所知並接受。

那麼，什麼是流計算呢？它和離線批次處理又有哪些區別呢？不同於離線批次處理（如 Hadoop Map Reduce ），流計算有著下面典型的特徵：

無邊界：流計算的資料來源頭是源源不斷的，就像河水一樣不停地流過來，相應地，流計算任務也需要始終執行。

觸發：不同於 Hadoop 離線任務是定時排程觸發，流計算任務的每次計算是由源頭資料觸發的 。觸發是流計算一個非常重要的概念，在某些業務場景下，觸發訊息的邏輯比較複雜，對流計算挑戰很大。

延遲：很顯然，流計算必須能夠高效地、迅速地處理資料。 不同於離線 Hadoop 任務至少以分鐘甚至小時計的處理延遲，流計算的延遲通常在秒甚至毫秒級，分鐘級別的延遲只在有些特殊情況下才被接受。

歷史資料：Hadoop 離線任務如果發現歷史某天的資料有問題，通常很容易修復問題而且重執行任務，但是對於流計算任務來說基本不可能或者代價非常大，因為首先實時流訊息通常不會儲存很久（一般幾天）， 而且儲存歷史的完全現場基本不可能，所以實時流計算一般只能從問題發現的時刻修復資料，歷史資料是無法通過流式方式來補的。

從根源上講，流計算的實現機制目前有兩種處理方式：一種是模仿離線的批次處理方式，也就是採用微批次處理（即 mini batch)。微批次處理帶來了吞吐量的提升，但是相應的資料延遲也會增大，基本在秒級和分鐘級，典型的技術是 Spark Streaming 。另一種是原生的訊息資料，即處理單位是單條資料，早期原生的流計算技術延遲低（一般在幾十毫秒），但是資料吞吐量有限，典型的是原生的 Storm 框架，但是隨著 Flink 等技術的產生和發展， 吞吐量也不再是問題。

2.3 主要流計算開源框架

三、資料管理

對於一個公司和組織來說，僅有資料的技術是不夠的，還必須對資料進行管理。資料管理的範疇很廣，但是具體主要包含資料探查、資料整合、資料品質、後設資料管理和資料遮蔽等資料管理技術 。

3.1 資料探查

資料探查，顧名思義，就是對資料的內容本身和關聯關係等進行分析，包括但不限於需要的資料是否有、都有哪些欄位、欄位含義是否規範明確以及欄位的分佈和品質如何等。資料探查常用的分析技術手段包括主外來鍵、欄位型別、欄位長度、 null 值佔比、列舉值分佈、最小值、最大值、平均值等。

資料探查分為戰略性的和戰術性的。

• 戰略性的資料探查是指在使用資料之前首先對資料來源進行輕量級的資料分析，確定其是否可用，資料穩定性如何，以決定是否可以納入資料平臺使用。戰略性的資料探查是構建資料平臺前首先要進行的任務，不合格的資料來源頭必須儘快剔除，如果到了後期才發現資料來源頭不合格，將會對資料平臺的構建造成重大影響。
• 戰術性的資料探查則指用技術手段對資料進行詳盡的分析，發現儘可能多的資料品質問題並反饋給業務人員或者通知源頭系統進行改進。

3.2 資料整合

資料倉儲的資料整合也叫 ETL （抽取： extract 、轉換： transform 、載入： load ），是資料平臺構建的核心，也是資料平臺構建過程中花費時間最多、花費精力最多的階段 。

ETL 泛指將資料從資料來源頭抽取、經過清洗、轉換、關聯等轉換，並最終按照預先設計的資料模型將資料載入到資料倉儲的過程。

對資料平臺使用者和業務人員來說，他們通常並不知道也不關心所使用的資料（如訂單） 源頭有幾個，都在哪些資料庫裡、欄位定義是否一致（如訂單系統 1 代表下單成功，0 代表下單失敗，而系統2用 sucess 代表下單成功、用 fail 代表下單失敗）、相關的資料表有哪些（如訂單顧客的畫像資訊、商品的類目），資料使用者希望最終看到的是一個匯規的、規範，包含所有相關訂單資訊的寬表，這個寬表包含了所有能夠使用的訂單資訊，而這些所有後臺的抽取、清洗、轉換和關聯以及最終的彙總、關聯等複雜過程都由 ETL 來完成，這也是資料倉儲能夠給資料使用者帶來的重要價值之一。

3.3 資料品質

資料品質主要從以下四個方面來衡量：

完整性：完整性是指資料資訊是否存在缺失的狀況，資料缺失的情況可能是整個資料記錄缺失，也可能是資料中某個欄位資訊的記錄缺失。不完整的資料所能借鑑的價值就會大大降低，也是資料品質最為基礎的一項評估標準。

一致性：：一致性是指資料是否遵循了統 的規範，資料集合是否保持了統一的格式。資料品質的一致性主要體現在資料記錄的規範和資料是否符合邏輯，比如IP 地址一定是由4個 0 ~ 255 的數位加上「.」組成的。

準確性：準確性是指資料記錄的資訊是否存在異常或錯誤，是否符合業務預期。

及時性：及時性是指資料的產出時間是否及時 準時，符合預期。

3.4 資料遮蔽

資料倉儲儲存了企業的所有資料，其中有些資料是非常敏感的，比如使用者的信用卡資訊、身份證資訊等 。這些資訊如果洩露，將會給企業或者公司帶來災難性的後果；但是這些資訊如果完全排除，又會對開發測試和分析統計等帶來影響。

資料遮蔽（ data masking ）就是關於對資料如何進行不可逆的處理，使得處理後的資料既能被開發測試和分析統計使用，又不會洩露任何資訊的過程。常用的辦法如：加密、替換、刪除／加擾 等。

四、小結

今天主要介紹了資料平臺的內容範疇，我們分別從離線和實時兩方面學習資料平臺的架構、主要概念和技術。

離線資料平臺是目前資料平臺的主戰場，相關的概念技術（如資料倉儲、維度建模、邏輯分層、 Hadoop 和 Hive 等）都比較成熟並已廣泛應用於各個公司。

實時資料平臺隨著資料時效性和人工智慧的興起，越來越得到重視並被放在戰略地位，實時資料平臺的有關技術也在不停地發展和完善，如 Storm 、Flink 和 Beam 等，我們需要對這些反面保持一定的關注並積極擁抱這些技術。

生命不是要超越別人，而是要超越自己。

我是雲祁，我們下期再見。