大數據架構平臺搭建指南及數據倉庫演進

一、大數據架構平臺搭建指南

雖然大數據平臺組件很多，但是對於沒有參與建設過大數據平臺的朋友來說，當前衆多的大數據組件和平臺架構容易讓人眼花繚亂。

本文首先介紹了大數據架構平臺的組件架構，便於瞭解大數據平臺的全貌，然後分別介紹數據集成、存儲與計算、分佈式調度、查詢分析等方面的觀點。

01. 大數據平臺架構

從圖上可以看出，大數據架構平臺分爲：數據集成、存儲與計算、分佈式調度、查詢分析等核心模塊。我們就沿着這個架構圖，來剖析大數據平臺的核心技術。

02. 數據集成

1. 日誌同步

開源日誌收集系統有 Sqoop、Flume、Logstash、Filebeat、Vector 等，其中 Flume 在雲原生場景用的多，Vector 是一個很高效的日誌同步工具，剛開源不久。

專家觀點：

日誌同步系統雖然本身比較成熟，但在平時工作中也屬於重點，一是因爲需要同步的數據量比較大，二是要保證日誌輸出的持續性，有緩存機制最大限度保障不丟日誌，始終保持平穩的運行狀態。

2. 數據抽取工具

大數據分析不能直接在原始的業務數據庫上直接操作，所以需要抽取想要的數據到分析數據庫或者分佈式存儲系統（例如 HDFS），常見數據抽取工具包括：DataX、BitSail 等。DataxundefinedDataX 是阿里開源的一個異構數據源離線同步工具，致力於實現包括關係型數據庫（MySQL、Oracle 等）、HDFS、Hive、ODPS、HBase、FTP 等各種異構數據源之間穩定高效的數據同步功能。BitSail 項目是頭條剛開源的，基於 Flink 開發，在自己內部業務應用廣泛。BitSail 支持多種異構數據源間的數據同步，並提供離線、實時、全量、增量場景下的全域數據集成解決方案。

專家觀點：

數據集成非常重要，因爲跟業務方相關的第一個環節就是數據集成，數據集成如果出現問題比如速度慢、丟數據等，都會影響到業務方數據的使用，也會影響業務方對大數據平臺的信任度。

3. 數據傳輸隊列

數據傳輸有三種：

• Kafka：流式傳輸

• RabbitMQ：隊列傳輸

• Pulsar：流式傳輸 + 隊列傳輸

專家觀點：

Kafka 是 Hadoop 組件全家桶，名氣更大，但是易用性還是差一點。
Pulsar 跟 Kafka 很像，不過架構比 Kafka 更先進，屬於後起之秀。

03. 數據處理：數據存儲、計算

1. 數據存儲：HDFS

HDFS 特點：橫向擴展，數據容錯性高。

專家觀點：

對於 HDFS 來說，優化是一個很重要的事情，因爲 HDFS 的集羣規模比較大，又要穩定，又要持續不斷的應對業務挑戰，優化這一塊還是很重要的。如果集羣負載大時，訪問延遲，會影響集羣整體使用效率。
HDFS 的優化趨勢包括：架構改進、讀寫分離、讀寫優化等。
雖然 HDFS 是分佈式文件系統，但在實際場景中，由於 NameNode 的單點和小文件過多導致的壓力過大問題，其管理的數據節點是有限的。分佈式文件系統的新趨勢類似 JuiceFS 的架構，採用「數據」與「元數據」分離存儲的架構，從而實現文件系統的分佈式設計，利用元數據緩存極大提升整體文件系統的性能，同時兼容大數據和雲原生場景的應用。

2. 數據計算

（1）離線計算引擎

在衆多的計算引擎中，MapReduce、Hive、Spark 等通常用於離線處理，即批計算。Storm、Spark Steaming 等處理實時計算的場景較多，即流計算。不得不說的是，Flink 既可以用於流計算，也可以用於批計算。

其中 Hive 的用途很廣，也很可靠，底層基於 MapReduce 的封裝，屬於 Hadoop 全家桶組件之一，缺點是隻能實現離線批處理。

Spark 是非常高效的批處理工具，成熟，穩定，比 Hive 快很多，並且還能實現近實時的數據處理能力。Spark 功能全，架構新，基於 RDD，計算過程中優先利用內存，並優化中間的計算步驟。

專家觀點：

● Spark + 數據湖是未來的發展方向。
● 離線的場景很豐富，但是缺乏處理的非常好的統一的計算引擎，hive 和 spark 都無法做到，所以這一塊未來還有很大的發揮空間。

（2）實時計算引擎優缺點及適用場景

實時計算引擎大體經過了三代，依次是：storm、spark streaming、Flink。其中 storm 和 spark streaming 現在用的很少，大部分公司都在用 Flink。

專家觀點：

● Flink 的優點是：可以實時的進行計算，在處理流計算這個方向上是最好的組件，而且幾乎可以替代近實時的業務場景。
● 缺點是對離線處理會略顯不足，不太適合處理大批量的離線數據集。
● Flink 的優化方向很多：a. Flink 在流處理穩定性上，雖然已經做到極細粒度，但是遇到阻塞時，會存在丟失數據的問題。需要加強穩定性。b. 實時性的提升：實時的優化是無底洞，業務需求能到秒級別、毫秒級別，怎麼能讓 Flink 在業務場景用的好，提升速度的同時，保持數據一致性，是 Flink 面臨的挑戰。

04. 數據調度

1. 常用任務調度系統

提到常用的任務調度系統，大家都會想到非常多，包括但不限於：Crontab、Apache Airflow、Oozie、Azkaban、Kettle、XXL-JOB、Apache DolphinScheduler、SeaTunnel 等，五花八門。

專家觀點：

● Apache DolphinScheduler（海豚調度）更專注於大數據場景，調度功能不復雜，但是足夠把任務管理起來。並且它是中文的，這一點對於中文用戶較友好。
● Apache Airflow 國外用的多。

2. 資源調度系統

資源調度系統主要包括 Yarn 和 Azkaban。Yarn 用的廣泛，上層很多組件都要支持，所以很受歡迎，對其優化很多。

Azkaban 是資源調度的小衆分支，用的人不多。

05. 大數據查詢

1. 大數據查詢引擎

常用的 OLAP 引擎對比：

專家觀點： 專家之一曾經用 Presto 和 StarRocks 做過對比 Impala 的性能測試，結論如下：

● 結果上看 StarRocks 的性能確實很強大，速度最快，但三者對比提升相同量級的性能需要更多的 CPU、內存資源等；
● Impala 在開啓各項優化之後，效果是可以接近 StarRocks 的；
● Presto 性能一般，而且發現跑部分 TPC-DS 測試時，調用 HMS API 的頻率偶爾很高，曾經把 HMS 搞掛過。但是 Presto 的易用性感覺最好，差不多就是開箱即用，配置很簡單。支持多源數據（多 Catalog）的接入，但是隨着數據湖對底層數倉存儲層的統一加上各個。其他高效分析引擎對數據湖的支持，這塊的優勢也會被逐步抹平。

專家對查詢引擎優化的觀點：

查詢引擎優化在大數據平臺架構只算一環，不算難點，但確實很重要。整個大數據生態的上下游優化應該是逐步協同進行的，查詢引擎上游的數據是需要下功夫治理的，不然 Impala 遇到比如小文件問題是很拖累性能的；查詢引擎下游需要一個合適的平臺作爲數據的展示窗口，比如 BI 工具，或用協議比較通用的客戶端，像支持 MySQL 協議的 SR 和 Doris 這些，如果下游沒法做比較好的數據展示，查詢引擎再牛也沒法讓大家用起來。

2. 大數據查詢優化工具

大數據查詢優化工具包括 Alluxio、JuiceFS 和 JindoFS。

專家觀點：

Alluxio：

數據編排最爲強大，市面上常見的存儲系統、雲存儲服務均可以直接接入，也可以自行實現相關 api 以接入其他自研存儲系統，可以說 Alluxio 最爲通用，既可用於雲存儲服務的緩存接入或數據編排，也可作爲傳統 HDFS 的多集羣數據編排。

JuiceFS：

● 提供了和 Alluxio 非常相似的功能，如元數據與數據分離的存儲、數據編排、與 Hadoop API 兼容、Fuse 等特性；

● JuiceFS 也有不錯的數據編排特性，元數據存儲的方式比 Alluxio 更多元，主要用於雲存儲場景。

JindoFS：

● 侷限於阿里雲 oss 場景的分佈式存儲系統；

● 支持與 Alluxio 非常相似的功能，也能提供內存級的緩存加速；

● 但場景侷限於 oss 內。

二、數據倉庫演進

01. 標準化

1. 數據治理

數據倉庫的標準化主要指的是數據治理。數據治理是數倉落地應用的核心問題，在近年受到越來越多的關注，其根本上是爲了解決數據倉庫煙囪式開發帶來的資源浪費等問題。

例如上圖所示，企業發展初期，因爲業務模式不穩定，多個業務線都有獨立研發的技術棧，到後期就會出現標準不統一、重複計算、模型依賴關係混亂的問題。

而經過標準統一、底層邏輯屏蔽和不同粒度的彙總，各個業務線的技術棧得以統一，就能大大簡化模型計算鏈路、降低成本、提高速度。

也可以從數據建模的角度來理解這個問題。數據建模是數倉建設的核心環節之一，包括自上而下（範式建模，Inmon 模式）和自下而上（維度建模，Kimball 模式）兩種建模方式。

範式建模主要在電信、金融、政務、工業等傳統行業用的比較多，而互聯網由於業務變化很快，初期需要更加靈活的分佈式決策結構，因此維度建模會更加合適，但也因此基於 Kimball 模式建模的後期會出現數據孤島問題和治理需求。不過，專家表示，維度建模在前期若有指導思想或方法論的話，或許能提前避免這個問題。

在業界，數倉治理最核心的工作是改善數據質量，數據的完整性、一致性等指標都會影響最終的數據決策的好壞，這對於整個行業都是一個挑戰。因爲數據質量僅僅通過簡單的唯一性校驗、波動性校驗等手段是很難排查出業務波動的根本原因的。

而除了人爲制定規則以外，如今也有不少企業正在嘗試引入 AI 算法對質量監控進行預測，目前技術上尚未成熟，但 AI 的潛力值得期待。

DataOPs 是近期比較熱的概念，很大程度上也是圍繞數據質量的工作，但其本質和數據治理相差不遠，關注數據生產的標準化、流程化、自動化、智能化，也就是將越來越多大數據技術環節中的人工工作自動化，也會開始結合 AI 技術，涉及開發和運維過程。

上圖展示了一個數倉開發的工作流程，包括模型檢索、模型創建、ETL 開發、作業發佈、監控報警等全流程的標準化、自動化都是 DataOPs 關心的問題。

提到標準化和數據治理，又不得不提到數據中臺。目前業界對於數據中臺都有不同的解釋，有專家對 DataFun 表示，數據倉庫和數據中臺其實是相對的概念。

實際上，中小企業通常只限於搭建數據倉庫，很多中小企業聲稱的數據中臺其實也是侷限於某個業務的數據倉庫，不是真正的數據中臺。

真正的數據中臺主要在大企業，其中每個部門都擁有一個數倉體系，那麼每個部門相當於一個小型公司。而在業務發展中後期會出現數據一致性、數據標準等方面的困難，因而就產生數據治理和建設中臺的需求。這也意味着，數據治理通常只在大企業中有足夠的需求。

2. 流批一體

數據治理在標準化方面的一大特點是將並行的業務線進行合併。實際上，這種合併統一的趨勢不僅存在於業務邏輯和數據層面，其根本上還存在於存儲、計算、處理等底層邏輯中。存儲、計算、處理的兩種基本的開發模式是離線計算和實時計算，因此數倉標準化的另一個方向是流批一體。

流批一體除了解決多條技術棧之間的標準不統一之外，還有一大好處就在於成本層面。在發展到一定階段的時候，離線數倉通常已經無法滿足業務需求了。而實時數倉對於下游的成本比較高，普惠性不足。

根據一些分析結果，批計算的成本和數據體量大致呈線性關係，而流計算的成本卻隨着數據體量的增長而呈指數級增長，背後原因包括隨機 IO、存算不分離、寫放大等。因而實時計算一般不直接面向業務，更多面向算法或數據工具。

另外，流批一體能夠實現狀態複用，很多時候這是有必要的，因爲離線計算在取數的時候，經常會遇到數據有效期不足的問題，而複用實時計算的結果就能很好地解決這個問題。

總體而言，流批一體架構的好處是解決流批不統一帶來的數據不一致、開發成本、使用成本、運維成本問題。

人們一般默認流批一體的解決方案是 Kappa 架構，採用 Kafka 和 Flink 也就是消息隊列和實時計算引擎的組合。

但 Kappa 架構嚴重依賴消息隊列的順序處理，而在順序存儲上進行 OLAP 分析是比較困難的。

因此在業界，許多企業開始探索通過數據湖方案實現流批一體，比如 Iceberg 支持讀寫分離，又支持併發讀、增量讀、小文件合併，還可以支持秒級到分鐘級的延遲，因此可以實現近實時數據接入。

同時，Iceberg 底層依賴列式存儲，用於替換 Kafka 後就可以對 OLAP 分析進行基本的優化，在中間層直接用 Flink 執行批式計算或流式計算。最後，再結合 Alluxio 的緩存能力，就可以對近實時的數據湖架構進一步加速。

儘管如此，目前在業界，無論是流批一體還是數據湖，其技術發展都還存在很大挑戰。據專家反饋，業界的方案基本都侷限於部分場景，距離通用方案還很遙遠。

流批一體的含義包含了多個層次，首先是存儲流批一體，其次是計算流批一體，最後是處理結果的流批一體，也就是讓同一段代碼在分別做批處理和流處理時，得到的結果是一致的，而這通常也是最難的。

02. 實時處理

1. 實時查詢

流批一體技術的需求自然來源於實時計算的發展。如今越來越多的服務面向 ToC 用戶，實時性需求越來越強，這些業務包括了風控事件處理，搜廣推的實時特徵計算，以及指標監控等等，實時數倉的開發也愈發受到企業的重視和投入。

目前而言，業界最關心的數據倉庫核心性能指標是查詢的實時性。性能指標設置對於業務成長非常重要，背後的考慮因素有兩個，一個是性能本身會導致數據產出的延遲，另一個是性能差一般也代表着資源消耗大。

提高數據處理實時性的解決方案類型主要有兩種，包括：數據和業務邏輯優化（主要指數據治理）、底層計算引擎優化。

其中，底層計算引擎的優化也是大企業比較常用的方法，常用的選型包括 Spark、Flink、Blink 等。

但嚴格來說，對於大企業而言，一般不存在選型的概念。專家表示，因爲大企業一般都有成熟的大數據平臺，裏面包括了採集、模型設計等模塊，經過優化和協同，這些組件都已經封裝成了一套完整的體系。

但對於中小企業來說，他們一般很難抉擇如何做具體的選型，一般都是考慮模仿大企業的架構，或者直接購買大企業的平臺產品。

2. 流式 ETL

除了查詢以外，數倉中另一個消耗資源較大的流程是 ETL。在業界，數倉比較常用的 ETL 模式是增量 ETL 和全量 ETL。

數倉 ETL 通常面臨的核心挑戰是高效實施，也就是如何用最低資源產出最多成果，另一個是數據質量。

除了增量 ETL、全量 ETL 之外，還有一種 ETL 的模式是流式 ETL，自然也是源於實時計算的業務需求，據專家介紹，目前在業界的成熟度還比較低。

03. 整體衡量

專家表示，對數據模型的優劣判斷（比如數據的業務覆蓋率、數據的業務使用率等），目前行業內還缺乏統一的、成熟的衡量指標。而數據模型是數倉的核心，其優劣判斷關係到數倉整體能力的判斷，重要性很高。

04. 總結

通過以上分析可知，除了標準化、模塊化、實時處理、整體衡量等發展特點以外，數據倉庫也還面臨許多整體層面的挑戰，包括解決方案通用性、整體衡量標準等。

目前業界正在投入數據編織、DataOPs 等方向，使得數據倉庫在標準化、模塊化等方面走的更遠，並實現更強的通用性，從而實至名歸地演化成數據中臺、數據湖等架構，適應數據智能業務不斷增長的規模化、多樣化、產品化需求。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8PORcvla0FUpSQJX7KB2lQ