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

前言

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

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

• 資料相關的工具、產品和技術：比如批量資料采集傳輸的 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 等，我們需要對這些反面保持一定的關注并積極擁抱這些技術，

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

我是云祁，我們下期再見，