大數(shù)據(jù)架構平臺搭建指南及數(shù)據(jù)倉庫演進

一、大數(shù)據(jù)架構平臺搭建指南
雖然大數(shù)據(jù)平臺組件很多，但是對于沒有參與建設過大數(shù)據(jù)平臺的朋友來說，當前眾多的大數(shù)據(jù)組件和平臺架構容易讓人眼花繚亂。

本文首先介紹了大數(shù)據(jù)架構平臺的組件架構，便于了解大數(shù)據(jù)平臺的全貌，然后分別介紹數(shù)據(jù)集成、存儲與計算、分布式調度、查詢分析等方面的觀點。

01. 大數(shù)據(jù)平臺架構

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

02.數(shù)據(jù)集成
1. 日志同步

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

專家觀點：

日志同步系統(tǒng)雖然本身比較成熟，但在平時工作中也屬于重點，一是因為需要同步的數(shù)據(jù)量比較大，二是要保證日志輸出的持續(xù)性，有緩存機制最大限度保障不丟日志，始終保持平穩(wěn)的運行狀態(tài)。

2. 數(shù)據(jù)抽取工具

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

專家觀點：

數(shù)據(jù)集成非常重要，因為跟業(yè)務方相關的第一個環(huán)節(jié)就是數(shù)據(jù)集成，數(shù)據(jù)集成如果出現(xiàn)問題比如速度慢、丟數(shù)據(jù)等，都會影響到業(yè)務方數(shù)據(jù)的使用，也會影響業(yè)務方對大數(shù)據(jù)平臺的信任度。

3. 數(shù)據(jù)傳輸隊列

數(shù)據(jù)傳輸有三種：

Kafka：流式傳輸
RabbitMQ：隊列傳輸
Pulsar：流式傳輸+隊列傳輸
專家觀點：

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

03. 數(shù)據(jù)處理：數(shù)據(jù)存儲、計算
1. 數(shù)據(jù)存儲：HDFS

HDFS 特點：橫向擴展，數(shù)據(jù)容錯性高。

專家觀點：

對于 HDFS 來說，優(yōu)化是一個很重要的事情，因為 HDFS 的集群規(guī)模比較大，又要穩(wěn)定，又要持續(xù)不斷的應對業(yè)務挑戰(zhàn)，優(yōu)化這一塊還是很重要的。如果集群負載大時，訪問延遲，會影響集群整體使用效率。
HDFS 的優(yōu)化趨勢包括：架構改進、讀寫分離、讀寫優(yōu)化等。
雖然 HDFS 是分布式文件系統(tǒng)，但在實際場景中，由于 NameNode 的單點和小文件過多導致的壓力過大問題，其管理的數(shù)據(jù)節(jié)點是有限的。分布式文件系統(tǒng)的新趨勢類似 JuiceFS 的架構，采用「數(shù)據(jù)」與「元數(shù)據(jù)」分離存儲的架構，從而實現(xiàn)文件系統(tǒng)的分布式設計，利用元數(shù)據(jù)緩存極大提升整體文件系統(tǒng)的性能，同時兼容大數(shù)據(jù)和云原生場景的應用。

2. 數(shù)據(jù)計算

（1）離線計算引擎

在眾多的計算引擎中，MapReduce、Hive、Spark 等通常用于離線處理，即批計算。Storm、Spark Steaming 等處理實時計算的場景較多，即流計算。不得不說的是，F(xiàn)link 既可以用于流計算，也可以用于批計算。

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

Spark 是非常高效的批處理工具，成熟，穩(wěn)定，比 Hive 快很多，并且還能實現(xiàn)近實時的數(shù)據(jù)處理能力。Spark 功能全，架構新，基于 RDD，計算過程中優(yōu)先利用內(nèi)存，并優(yōu)化中間的計算步驟。

專家觀點：

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

（2）實時計算引擎優(yōu)缺點及適用場景

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

專家觀點：

● Flink的優(yōu)點是：可以實時的進行計算，在處理流計算這個方向上是最好的組件，而且?guī)缀蹩梢蕴娲鼘崟r的業(yè)務場景。
● 缺點是對離線處理會略顯不足，不太適合處理大批量的離線數(shù)據(jù)集。
● Flink的優(yōu)化方向很多：a. Flink在流處理穩(wěn)定性上，雖然已經(jīng)做到極細粒度，但是遇到阻塞時，會存在丟失數(shù)據(jù)的問題。需要加強穩(wěn)定性。b. 實時性的提升：實時的優(yōu)化是無底洞，業(yè)務需求能到秒級別、毫秒級別，怎么能讓Flink在業(yè)務場景用的好，提升速度的同時，保持數(shù)據(jù)一致性，是Flink面臨的挑戰(zhàn)。

04. 數(shù)據(jù)調度
1. 常用任務調度系統(tǒng)

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

專家觀點：

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

2. 資源調度系統(tǒng)

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

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

05. 大數(shù)據(jù)查詢
1. 大數(shù)據(jù)查詢引擎

常用的OLAP引擎對比：


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

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

專家對查詢引擎優(yōu)化的觀點：

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

2. 大數(shù)據(jù)查詢優(yōu)化工具

大數(shù)據(jù)查詢優(yōu)化工具包括 Alluxio、JuiceFS 和 JindoFS。

專家觀點：

Alluxio：

數(shù)據(jù)編排最為強大，市面上常見的存儲系統(tǒng)、云存儲服務均可以直接接入，也可以自行實現(xiàn)相關 api 以接入其他自研存儲系統(tǒng)，可以說 Alluxio 最為通用，既可用于云存儲服務的緩存接入或數(shù)據(jù)編排，也可作為傳統(tǒng) HDFS 的多集群數(shù)據(jù)編排。

JuiceFS：

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

● JuiceFS 也有不錯的數(shù)據(jù)編排特性，元數(shù)據(jù)存儲的方式比 Alluxio 更多元，主要用于云存儲場景。

JindoFS：

● 局限于阿里云 oss 場景的分布式存儲系統(tǒng)；

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

● 但場景局限于 oss 內(nèi)。

二、數(shù)據(jù)倉庫演進
01. 標準化
1. 數(shù)據(jù)治理

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


例如上圖所示，企業(yè)發(fā)展初期，因為業(yè)務模式不穩(wěn)定，多個業(yè)務線都有獨立研發(fā)的技術棧，到后期就會出現(xiàn)標準不統(tǒng)一、重復計算、模型依賴關系混亂的問題。


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

也可以從數(shù)據(jù)建模的角度來理解這個問題。數(shù)據(jù)建模是數(shù)倉建設的核心環(huán)節(jié)之一，包括自上而下（范式建模，Inmon模式）和自下而上（維度建模，Kimball模式）兩種建模方式。

范式建模主要在電信、金融、政務、工業(yè)等傳統(tǒng)行業(yè)用的比較多，而互聯(lián)網(wǎng)由于業(yè)務變化很快，初期需要更加靈活的分布式?jīng)Q策結構，因此維度建模會更加合適，但也因此基于Kimball模式建模的后期會出現(xiàn)數(shù)據(jù)孤島問題和治理需求。不過，專家表示，維度建模在前期若有指導思想或方法論的話，或許能提前避免這個問題。

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

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

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


上圖展示了一個數(shù)倉開發(fā)的工作流程，包括模型檢索、模型創(chuàng)建、ETL開發(fā)、作業(yè)發(fā)布、監(jiān)控報警等全流程的標準化、自動化都是DataOPs關心的問題。

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

實際上，中小企業(yè)通常只限于搭建數(shù)據(jù)倉庫，很多中小企業(yè)聲稱的數(shù)據(jù)中臺其實也是局限于某個業(yè)務的數(shù)據(jù)倉庫，不是真正的數(shù)據(jù)中臺。

真正的數(shù)據(jù)中臺主要在大企業(yè)，其中每個部門都擁有一個數(shù)倉體系，那么每個部門相當于一個小型公司。而在業(yè)務發(fā)展中后期會出現(xiàn)數(shù)據(jù)一致性、數(shù)據(jù)標準等方面的困難，因而就產(chǎn)生數(shù)據(jù)治理和建設中臺的需求。這也意味著，數(shù)據(jù)治理通常只在大企業(yè)中有足夠的需求。

2. 流批一體

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

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

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

另外，流批一體能夠實現(xiàn)狀態(tài)復用，很多時候這是有必要的，因為離線計算在取數(shù)的時候，經(jīng)常會遇到數(shù)據(jù)有效期不足的問題，而復用實時計算的結果就能很好地解決這個問題。

總體而言，流批一體架構的好處是解決流批不統(tǒng)一帶來的數(shù)據(jù)不一致、開發(fā)成本、使用成本、運維成本問題。

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


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


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


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

盡管如此，目前在業(yè)界，無論是流批一體還是數(shù)據(jù)湖，其技術發(fā)展都還存在很大挑戰(zhàn)。據(jù)專家反饋，業(yè)界的方案基本都局限于部分場景，距離通用方案還很遙遠。

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

02. 實時處理
1. 實時查詢

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

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

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

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

但嚴格來說，對于大企業(yè)而言，一般不存在選型的概念。專家表示，因為大企業(yè)一般都有成熟的大數(shù)據(jù)平臺，里面包括了采集、模型設計等模塊，經(jīng)過優(yōu)化和協(xié)同，這些組件都已經(jīng)封裝成了一套完整的體系。

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

2. 流式ETL

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

數(shù)倉ETL通常面臨的核心挑戰(zhàn)是高效實施，也就是如何用最低資源產(chǎn)出最多成果，另一個是數(shù)據(jù)質量。

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

03. 整體衡量
專家表示，對數(shù)據(jù)模型的優(yōu)劣判斷（比如數(shù)據(jù)的業(yè)務覆蓋率、數(shù)據(jù)的業(yè)務使用率等），目前行業(yè)內(nèi)還缺乏統(tǒng)一的、成熟的衡量指標。而數(shù)據(jù)模型是數(shù)倉的核心，其優(yōu)劣判斷關系到數(shù)倉整體能力的判斷，重要性很高。

04. 總結
通過以上分析可知，除了標準化、模塊化、實時處理、整體衡量等發(fā)展特點以外，數(shù)據(jù)倉庫也還面臨許多整體層面的挑戰(zhàn)，包括解決方案通用性、整體衡量標準等。

目前業(yè)界正在投入數(shù)據(jù)編織、DataOPs等方向，使得數(shù)據(jù)倉庫在標準化、模塊化等方面走的更遠，并實現(xiàn)更強的通用性，從而實至名歸地演化成數(shù)據(jù)中臺、數(shù)據(jù)湖等架構，適應數(shù)據(jù)智能業(yè)務不斷增長的規(guī)?；⒍鄻踊?、產(chǎn)品化需求。


作者： 大數(shù)據(jù)球球


歡迎關注微信公眾號 ：大數(shù)據(jù)球球