五個篇章講明白如何從0到1搭建大資料平臺

大家好，我是一哥，整理了一下之前寫的搭建大資料平臺的5個篇章，請大家收藏

01

如何從0到1搭建大資料平臺

大資料時代這個詞被提出已有10年了吧，越來越多的企業已經完成了大資料平臺的搭建。隨著移動網際網路和物聯網的爆發，大資料價值在越來越多的場景中被挖掘，隨著大家都在使用歐冠大資料，大資料平臺的搭建門檻也越來越低。藉助開源的力量，任何有基礎研發能力的組織完全可以搭建自己的大資料平臺。但是對於沒有了解過大資料平臺、資料倉儲、資料探勘概念的同學可能還是無法順利完成搭建，因為你去百度查的時候會發現太多的東西，和架構，你不知道如何去選擇。今天給大家分享下大資料平臺是怎麼玩的。

00 架構總覽

通常大資料平臺的架構如上，從外部採集資料到資料處理，資料顯現，應用等模組。

01 資料採集

使用者訪問我們的產品會產生大量的行為日誌，因此我們需要特定的日誌採集系統來採集並輸送這些日誌。Flume是目前常用的開源選擇，Flume是Cloudera提供的一個高可用的，高可靠的，分散式的海量日誌採集、聚合和傳輸的系統，Flume支援在日誌系統中定製各類資料傳送方，用於收集資料；同時，Flume提供對資料進行簡單處理，並寫到各種資料接受方的能力。

02 資料儲存

無論上層採用何種的大規模資料計算引擎，底層的資料儲存系統基本還是以HDFS為主。HDFS（Hadoop Distributed File System）是Hadoop專案的核心子專案，是分散式計算中資料儲存管理的基礎。具備高容錯性、高可靠、高吞吐等特點。

HDFS儲存的是一個個的文字，而我們在做分析統計時，結構化會方便需要。因此，在HDFS的基礎上，會使用Hive來將資料檔案對映為結構化的表結構，以便後續對資料進行類SQL的查詢和管理。

03 資料處理

資料處理就是我們常說的ETL。在這部分，我們需要三樣東西：計算引擎、排程系統、後設資料管理。

對於大規模的非實時資料計算來講，目前一樣採用Hive和spark引擎。Hive是基於MapReduce的架構，穩定可靠，但是計算速度較慢；Spark則是基於記憶體型的計算，一般認為比MapReduce的速度快很多，但是其對記憶體效能的要求較高，且存在記憶體溢位的風險。Spark同時相容hive資料來源。從穩定的角度考慮，一般建議以Hive作為日常ETL的主要計算引擎，特別是對於一些實時要求不高的資料。Spark等其他引擎根據場景搭配使用。

實時計算引擎方面，目前大體經過了三代，依次是：storm、spark streaming、Flink。Flink已被阿里收購，大廠一直在推，社群活躍度很好，國內也有很多資源。

排程系統上，建議採用輕量級的Azkaban，Azkaban是由Linkedin開源的一個批次工作流任務排程器。

一般需要自己開發一套後設資料管理系統，用來規劃資料倉儲和ETL流程中的後設資料。後設資料分為業務後設資料和技術後設資料。

• 業務後設資料，主要用於支撐資料服務平臺Web UI上面的各種業務條件選項，比如，常用的有如下一些：移動裝置機型、品牌、運營商、網路、價格範圍、裝置物理特性、應用名稱等。這些後設資料，有些來自於基礎資料部門提供的標準庫，比如品牌、價格範圍等，可以從對應的資料表中同步或直接讀取；而有些具有時間含義的後設資料，需要每天透過ETL處理生成，比如應用資訊。為支撐應用計算使用，被儲存在MySQL資料庫中；而對於填充頁面上對應的條件選擇的資料，則使用Redis儲存，每天/月會根據MySQL中的資料進行加工處理，生成易於快速查詢的鍵值對類資料，儲存到Redis中。

• 技術後設資料，主要包括資料倉儲中的模型說明、血緣關係、變更記錄、需求來源、模型欄位資訊等，詳細的可以檢視資料分析師應該瞭解的資料倉儲(3)

  

04 資料流轉

透過上面一張圖瞭解資料採集，資料處理，到資料展現的資料流轉。通常我們在實際工作中，從資料來源到分析報告或系統應用的過程中，主要包括資料採集同步、資料倉儲儲存、ETL、統計分析、寫入上層應用資料庫進行指標展示。這是最基礎的一條線，現在還有基於資料倉儲進行的資料分析挖掘工作，會基於機器學習和深度學習對已有模型資料進一步挖掘分析，形成更深層的資料應用產品。

05 資料應用

俗話說的好，“酒香也怕巷子深”。資料應用前面我們做了那麼多工作為了什麼，對於企業來說，我們做的每一件事情都需要體現出價值，而此時的資料應用就是大資料的價值體現。資料應用包括輔助經營分析的一些報表指標，商城上基於使用者畫像的個性化推送，還有各種資料分析報告等等。

02

資料採集系統

01 “大”資料

海量的資料

當你需要搭建大資料平臺的時候一定是傳統的關係型資料庫無法滿足業務的儲存計算要求了，所以首先我們面臨的是海量的資料。

複雜的資料

複雜資料的概念和理想資料完全相反。所有資料集都有一定的複雜性，但有一些天生更難處理。通常這些複雜資料集沒有定義結構(沒有行列結構)，經常變化，資料質量很差。比如更新的網頁日誌，json資料，xml資料等。

高速的資料

高速資料通常被認為是實時的或是準實時的資料流。資料流本質上是在生成後就發給處理器的資料包，比如物聯網的穿戴裝置，製造業的感測器，車聯網的終端晶片等等。處理實時資料流有很多挑戰，包括在採集時不丟失資料、處理資料流中的重複記錄、資料如何實時寫入磁碟儲存、以及如何進行實時分析。

02 採集工具

日誌採集

我們業務平臺每天都會有大量使用者訪問，會產生大量的訪問日誌資料，比如電商系統的瀏覽，加入購物車，下訂單，付款等一系列流程我們都可以透過埋點獲取到使用者的訪問路徑以及訪問時長這些資料；再比智慧穿戴裝置，實時都會採集我們的血壓、脈搏、心率等資料實時上報到雲端。透過分析這些日誌資訊，我們可以得到出很多業務價值。透過對這些日誌資訊進行日誌採集、收集，然後進行資料分析，挖掘公司業務平臺日誌資料中的潛在價值。為公司決策和公司後臺伺服器平臺效能評估提高可靠的資料保證。系統日誌採集系統做的事情就是收集日誌資料提供離線和線上的實時分析使用。目前常用的開源日誌收集系統有Flume、Logstash、Filebeat。可以根據自己公司的技術棧儲備或者元件的優缺點選擇合適的日誌採集系統，目前瞭解到的Flume使用的比較多。各個採集工具的對比如下：

具體元件的相關配置可以參考之前的文章《日誌收集元件—Flume、Logstash、Filebeat對比》

資料庫抽取

企業一般都會會使用傳統的關係型資料庫MySQL或Oracle等來儲存業務系統資料。每時每刻產生的業務資料，以資料庫一行記錄的形式被直接寫入到資料庫中儲存。

大資料分析一般是基於歷史海量資料，多維度分析，我們不能直接在原始的業務資料庫上直接操作，因為分析的一些複雜SQL查詢會明顯的影響業務資料庫的效率，導致業務系統不可用。所以我們通常透過資料庫採集系統直接與企業業務後臺資料庫伺服器結合，在業務不那麼繁忙的凌晨，抽取我們想要的資料到分析資料庫或者到HDFS上，最後有大資料處理系統對這些資料進行清洗、組合進行資料分析。

常用資料庫抽取工具：

• 阿里開源軟體：DataX

       DataX 是一個異構資料來源離線同步工具，致力於實現包括關係型資料庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構資料來源之間穩定高效的資料同步功能。開源的DataX貌似只能單機部署。

• Apache開源軟體：Sqoop

       Sqoop(發音:skup)是一款開源的工具，主要用於在HADOOP(Hive)與傳統的資料庫(mysql、postgresql...)間進行資料的傳遞，可以將一個關係型資料庫(例如 : MySQL ,Oracle ,Postgres等)中的資料導進到Hadoop的HDFS中，也可以將HDFS的資料導進到關係型資料庫中。可以叢集化部署。

爬蟲爬取

有很多外部資料，比如天氣、IP地址等資料，我們通常會爬取相應的網站資料儲存。目前常用的爬蟲工具是Scrapy，它是一個爬蟲框架，提供給開發人員便利的爬蟲API介面。開發人員只需要關心爬蟲API介面的實現，不需要關心具體框架怎麼爬取資料。Scrapy框架大大降低了開發人員開發速率，開發人員可以很快的完成一個爬蟲系統的開發。

03 資料儲存

HDFS

2003年，Google釋出論文GFS，啟發Apache Nutch開發了HDFS。2004年，Google 又釋出了論文《MapReduce: Simplified Data Processing on Large Clusters》，Doug Cutting等人實現計算框架MapReduce ，並與HDFS結合來更好的支援該框架。2006年專案從Butch搜尋引擎中獨立出來，成為了現在的Hadoop。

GFS隱藏了底層的負載均衡，切片備份等細節，使複雜性透明化，並提供統一的檔案系統介面。其成本低，容錯高，高吞吐，適合超大資料集應用場景。

• HDFS原理:橫向擴充套件，增加“資料節點”就能增加容量。

• 增加協調部門，“命名節點”維護後設資料，負責檔案系統的名稱空間，控

• 外部訪問，將資料塊對映到資料節點。還會備份後設資料從命名節點，它只與命名節點通訊。

• 資料在多個資料節點備份。

通常關係型資料庫儲存的都是結構化的資料，我們抽取後會直接放到HDFS上作為離線分析的資料來源。

HBase

在實際應用中，我們有很多資料可能不需要複雜的分析，只需要我們能儲存，並且提供快速查詢的功能。HBase在HDFS基礎上提供了Bigtable的能力; 並且基於列的模式進行儲存。列儲存設計的優勢是減少不必要的欄位佔用儲存，同時查詢的時候也可以只對查詢的指定列有IO操作。HBase可以儲存海量的資料，並且可以根據rowkey提供快速的查詢效能，是非常好的明細資料儲存方案，比如電商的訂單資料就可以放入HBase提供高效的查詢。

當然還有其他的儲存引擎，比如ES適合文字搜尋查詢等。

04 總結

瞭解了上面的技術棧後，在實際資料接入中，你還會面臨各種問題，比如如何考慮確保資料一致性，保障資料不能丟失，資料採集儲存的效率，不能產生資料積壓等，這些都需要對每個元件進行研究，適配適合你自己業務系統的引數，用最少的資源，達到最好的結果。

03

排程系統

目前大資料平臺經常會用來跑一些批任務，跑批處理當然就離不開定時任務。比如定時抽取業務資料庫的資料，定時跑hive/spark任務，定時推送日報、月報指標資料。任務排程系統已經儼然成為了大資料處理平臺不可或缺的一部分，可以說是ETL任務的靈魂。   

01 原始任務排程

記得第一次參與大資料平臺從無到有的搭建，最開始任務排程就是用的Crontab，分時日月周，各種任務指令碼配置在一臺主機上。Crontab 使用非常方便，配置也很簡單。剛開始任務很少，用著還可以，每天起床巡檢一下日誌。隨著任務越來越多，出現了任務不能在原來計劃的時間完成，出現了上級任務跑完前，後面依賴的任務已經起來了，這時候沒有資料，任務就會報錯，或者兩個任務並行跑了，出現了錯誤的結果。排查任務錯誤原因越來麻煩，各種任務的依賴關係越來越複雜，最後排查任務問題就行從一團亂麻中，一根一根梳理出每天麻繩。crontab雖然簡單，穩定，但是隨著任務的增加和依賴關係越來越複雜，已經完全不能滿足我們的需求了，這時候就需要建設自己的排程系統了。

02 排程系統

排程系統，關注的首要重點是在正確的時間點啟動正確的作業，確保作業按照正確的依賴關係及時準確的執行。資源的利用率通常不是第一關注要點，業務流程的正確性才是最重要的。（但是到隨著業務的發展，ETL任務越來越多，你會發現經常有任務因為資源問題沒有按時啟動！）

實際排程中，多個任務單元之間往往有著強依賴關係，上游任務執行併成功，下游任務才可以執行。比如上游任務1結束後拿到結果，下游任務2、任務3需結合任務1的結果才能執行，因此下游任務的開始一定是在上游任務成功執行拿到結果之後才可以開始。而為了保證資料處理結果的準確性，就必須要求這些任務按照上下游依賴關係有序、高效的執行，最終確保能按時正常生成業務指標。

一款成熟易用，便於管理和維護的作業排程系統，需要和大量的周邊元件對接，要處理或使用到包括：血緣管理，許可權控制，負載流控，監控報警，質量分析等各種服務或事務。

03 排程系統分類

排程系統一般分為兩類：定時分片類作業排程系統和DAG工作流類作業排程系統

定時分片類作業排程系統

這種功能定位的作業排程系統，其最早的需要來源和出發點往往是做一個分散式的Crontab。

核心：

• 將一個大的任務拆成多個小任務分配到不同的伺服器上執行， 難點在於要做到不漏，不重，保證負載平衡，節點崩潰時自動進行任務遷移等。

• 保證任務觸發的強實時和可靠性

所以，負載均衡，彈性擴容，狀態同步和失效轉移通常是這類排程系統在架構設計時重點考慮的特性。

DGA工作流排程系統

這一類系統的方向，重點定位於任務的排程依賴關係的正確處理，分片執行的邏輯通常不是系統關注的核心，或者不是系統核心流程的關鍵組成部分。

核心：

• 足夠豐富和靈活的依賴觸發機制：比如時間觸發任務，依賴觸發任務，混合觸發任務

• 作業的計劃，變更和執行流水的管理和同步

• 任務的優先順序管理，業務隔離，許可權管理等

• 各種特殊流程的處理，比如暫停任務，重刷歷史資料，人工標註失敗／成功，臨時任務和週期任務的協同等

• 完備的監控報警通知機制

04 幾個排程系統

Airflow

Apache Airflow是一種功能強大的工具，可作為任務的有向無環圖（DAG）編排、任務排程和任務監控的工作流工具。Airflow在DAG中管理作業之間的執行依賴，並可以處理作業失敗，重試和警報。開發人員可以編寫Python程式碼以將資料轉換為工作流中的操作。

主要有如下幾種元件構成：

• web server: 主要包括工作流配置，監控，管理等操作

• scheduler: 工作流排程程式，觸發工作流執行，狀態更新等操作

• 訊息佇列：存放任務執行命令和任務執行狀態報告

• worker: 執行任務和彙報狀態

• mysql: 存放工作流，任務後設資料資訊

具體執行流程：

1. scheduler掃描dag檔案存入資料庫，判斷是否觸發執行

2. 到達觸發執行時間的dag,生成dag_run，task_instance 存入資料庫

3. 傳送執行任務命令到訊息佇列

4. worker從佇列獲取任務執行命令執行任務

5. worker彙報任務執行狀態到訊息佇列

6. schduler獲取任務執行狀態，並做下一步操作

7. schduler根據狀態更新資料庫

Kettle

將各個任務操作元件拖放到工作區，kettle支援各種常見的資料轉換。此外，使用者可以將Python，Java，JavaScript和SQL中的自定義指令碼拖放到畫布上。kettle可以接受許多檔案型別作為輸入，還可以透過JDBC，ODBC連線到40多個資料庫，作為源或目標。社群版本是免費的，但提供的功能比付費版本少。

XXL-JOB

XXL-JOB是一個分散式任務排程平臺，其核心設計目標是開發迅速、學習簡單、輕量級、易擴充套件。將排程行為抽象形成“排程中心”公共平臺，而平臺自身並不承擔業務邏輯，“排程中心”負責發起排程請求；將任務抽象成分散的JobHandler，交由“執行器”統一管理，“執行器”負責接收排程請求並執行對應的JobHandler中業務邏輯；因此，“排程”和“任務”兩部分可以相互解耦，提高系統整體穩定性和擴充套件性。（後來才知道XXL是作者名字拼音首字母縮寫）

排程系統開源工具有很多，可以結合自己公司人員的熟悉程度和需求選擇合適的進行改進。

海豚排程

Apache DolphinScheduler是一個分散式去中心化，易擴充套件的視覺化DAG工作流任務排程平臺。致力於解決資料處理流程中錯綜複雜的依賴關係，使排程系統在資料處理流程中開箱即用。

• 高可靠性

  去中心化的多Master和多Worker服務對等架構, 避免單Master壓力過大，另外採用任務緩衝佇列來避免過載

• 簡單易用

  DAG監控介面，所有流程定義都是視覺化，透過拖拽任務完成定製DAG，透過API方式與第三方系統整合, 一鍵部署

• 豐富的使用場景

  支援多租戶，支援暫停恢復操作. 緊密貼合大資料生態，提供Spark, Hive, M/R, Python, Sub_process, Shell等近20種任務型別

• 高擴充套件性

  支援自定義任務型別，排程器使用分散式排程，排程能力隨叢集線性增長，Master和Worker支援動態上下線

05 如何自己開發一個排程系統

排程平臺其實需要解決三個問題：任務編排、任務執行和任務監控。

• 任務編排，採用呼叫外部編排服務的方式，主要考慮的是編排需要根據業務的一些屬性進行實現，所以將易變的業務部分從作業排程平臺分離出去。如果後續有對編排邏輯進行調整和修改，都無需操作業務作業排程平臺。

• 任務排隊，支援多佇列排隊配置，後期根據不同型別的開發人員可以配置不同的佇列和資源，比如面向不同的開發人員需要有不同的服務佇列，面向不同的任務也需要有不同的佇列優先順序支援。透過佇列來隔離排程，能夠更好地滿足具有不同需求的使用者。不同佇列的資源不同，合理的利用資源，達到業務價值最大化。

• 任務調度，是對任務、以及屬於該任務的一組子任務進行排程，為了簡單可控起見，每個任務經過編排後會得到一組有序的任務列表，然後對每個任務進行排程。這裡面，稍有點複雜的是，任務裡還有子任務，子任務是一些處理元件，比如欄位轉換、資料抽取，子任務需要在上層任務中引用實現排程。任務是排程執行的基本單位。被排程執行的任務會傳送到訊息佇列中，然後等待任務協調計算平臺消費並執行任務，這時排程平臺只需要等待任務執行完成的結果訊息到達，然後對作業和任務的狀態進行更新，根據實際狀態確定下一次排程的任務。

排程平臺設計中還需要注意以下幾項：

1. 排程執行的任務需要進行超時處理，比如某個任務由於開發人員設計不合理導致執行時間過長，可以設定任務最大的執行時長，超過最大時長的任務需要及時kill掉，以免佔用大量資源，影響正常的任務執行。

2. 控制同時能夠被排程的作業的數量，叢集資源是有限的，我們需要控制任務的併發量，後期任務上千上萬後我們要及時調整任務的啟動時間，避免同時啟動大量的任務，減少排程資源和計算資源壓力；

3. 作業優先順序控制，每個業務都有一定的重要級別，我們要有限保障最重要的業務優先執行，優先給與排程資源分配。在任務積壓時候，先執行優先順序高的任務，保障業務影響最小化。

06 總結與展望

ETL 開發是資料工程師必備的技能之一，在資料倉儲、BI等場景中起到重要的作用。但很多從業者連 ETL 對應的英文是什麼都不瞭解，更不要談對 ETL 的深入解析，這無疑是非常不稱職的。做ETL 你可以用任何的程式語言來完成開發，無論是 shell、python、java 甚至資料庫的儲存過程，只要它最終是讓資料完成抽取（E）、轉化（T）、載入（L）的效果即可。由於ETL是極為複雜的過程，而手寫程式不易管理，所以越來越多的視覺化排程編排工具出現了。

排程系統作為大資料平臺的核心部分之一，牽扯的業務邏輯比較複雜，場景不同，也許需求就會差別很多，所以，有自研能力的公司都會選擇市面上開源系統二次開發或者完全自研一套排程系統，已滿足自身ETL任務排程需求。

不管是哪種工具，只要具備高效執行、穩定可靠、易於維護特點，都是一款好工具。

04

計算儲存系統

大資料計算平臺目前主要都是圍繞著hadoop生態發展的，運用HDFS作為資料儲存，計算框架分為批處理、流處理。

01 傳統的計算平臺

我們都知道，沒有大資料之前，我們計算平臺基本是依賴資料庫，大資料量的計算基本依賴Oracle資料庫。Oracle很強大，支撐了很多年銀行、電信業務資料的計算儲存。Oracle多以集中式架構為主，最大特點就是將所有的資料都集中在一個資料庫中，依靠大型高階裝置來提供高處理能力和擴充套件性。集中式資料庫的擴充套件性主要採用向上擴充套件的方式，透過增加CPU，記憶體，磁碟等方式提高處理能力。這種集中式資料庫的架構，使得資料庫成為了整個系統的瓶頸，已經越來越不適應海量資料對計算能力的巨大需求。同時傳統資料庫架構對高階裝置的依賴，無疑將直接導致系統成本的大幅度增加，甚至可能會導致系統被主機和硬體廠商所“綁架”，不得不持續增加投入成本。

02 Hadoop的崛起

隨著網際網路行業的發展，特別是移動網際網路的快速發展，傳統資料庫面臨著海量資料的儲存成本、有限的擴充套件能力等問題。新的計算框架MapReduce出現了，新的儲存編碼方式HDFS出現了，二者合起來，我們一般稱之為Hadoop。

Hadoop很快憑藉其高可靠性、高擴充套件性、成本低、高效計算等優勢在各個領域得到了廣泛應用。

03 Hive的應用

Hive最初是Facebook開源的，我們來看看Hive的特點：

• Hive是一個構建於Hadoop頂層的資料倉儲工具，可以查詢和管理PB級別的分散式資料。

• 支援類SQL語音。

• 可以看作為使用者程式設計介面，本身不儲存和處理資料

• 依賴HDFS作為儲存

我們看到Hive支援類SQL語法，我們可以很容易的把傳統關係型資料庫建立的資料倉儲任務遷移到Hadoop平臺上。

Hive的架構：

我們可以看到hive提供了多種連線方式：JDBC、ODBC、Thrift。

那麼我們以前使用Oracle的儲存過程怎麼遷移到Hive中呢？用過Hive的同學可能都知道，Hive是沒有想Oracle那樣的遊標迴圈呀，所以我們必須藉助其他語言來配合hive一起完成資料倉儲的ETL過程。比如這個專案：PyHive()

藉助Python，我們可以很好的彌補Hive在複雜處理的一些缺陷，同時也能更好的開發ETL任務。

所以，透過Hive我們就可以搭建起一套大資料計算平臺。

04 Spark的應用

Hive在剛開始使用過程中很好用，對大資料量的處理確實比以前傳統資料庫要好，但是隨著業務的增長，公司越來越多的資料工程師反饋查詢慢，同時業務側也紛紛提出，我們的資料能不能早點出，不要老是等到早上8點才重新整理。我們需要更強大的計算引擎，Spark使用了十分之一的計算資源，獲得了比Hadoop快3倍的速度，Spark為什麼這麼快呢？

我們來看看Spark的特點：

• 速度快，使用DGA（有向無環圖）。

• 支援記憶體計算。

• 低延遲、高容錯。

Spark提供了存計算，可以將計算結果存放到記憶體中，我們都知道MR是將資料儲存在磁碟，對磁碟讀寫，勢必會增加IO操作，計算時間過長。之前我也做過一個Hive和Spark的一個執行效率的對比，當時使用的是Spark1.6，資料是千萬級別的表。

還是可以看出Spark比Hive快了很多，現在Spark2.0以後，會更快了。而且，Spark同樣提供的有JDBC、ODBC 、Thrift連線方式。

我們可以從Hive環境直接遷移到Spark環境，提高執行效率。

05 MPP的應用

用了Spark還是不夠快，每次查詢提交任務後，都得等著任務啟動然後看著任務執行進度一直等著。

MPP（Massively Parallel Processing）是指多個處理器（或獨立的計算機）並行處理一組協同計算。為了保證各節點的獨立計算能力，MPP資料庫通常採用ShareNothing架構。比較有代表性大家熟知的比如：GPDB、Vertica。

MPP具備以下特點：

• 低成本的硬體、和Hadoop一樣，使用x86架構的PC就可以

• 資料儲存採用不同的壓縮演算法，減少使用空間，提高IO效能

• 資料載入高效，並行載入、資料載入的速度取決於頻寬

• 易擴充套件，容易對叢集節點進行增減

• 列儲存，很多MPP支援列儲存架構，能夠更高效的訪問需要的資料

• 支援標準SQL，MPP比SparkSQL、HiveSQL對標準SQL支援的更好

從以上MPP的特點和上面我們介紹的Hadoop的特點，會發現MPP更適合資料自助分析、即席查詢等場景、能夠使資料人員快速獲取資料結果。

06 搭建自己的計算平臺

開源的計算引擎這麼多、我們如何選擇合適的計算引擎搭建平臺呢？

下面分多個場景來和大家探討下：

小公司、無大資料平臺

真正的從無到有搭建大資料平臺，開發人員較少。可以直接使用CDH搭建起來你的大資料平臺，選用Hive作為資料倉儲的計算引擎。為什麼這樣選擇呢？很多小公司沒有足夠的資金支撐大資料平臺的建設，那麼就會選擇相對來說的比較穩定的開源元件，Hive發展了很多年，和磁碟的互動MR計算架構中的任務很少會出錯。Hive對SQL支援的很好，開發人員很容易上手，而且維護成本很低。

小公司、大資料平臺升級

已經有過一段時間使用Hive作為計算引擎後，工程師們對大資料平臺已經有一定的瞭解和知識積累，對Hadoop的運維能力也提升了，隨著開發人員反饋Hive比較慢，領導也考慮升級平臺，這時候就可以引入Spark了。上面我們也說了Spark是基於記憶體運算的，記憶體始終是沒有磁碟穩定，Spark任務很多時候會因為資源設定不合理而報錯。而SparkSQL和可以直接共享Hive的metestore，直接從Hive遷移到Spark上很自然，工作流很小。同時Spark還提供了Streaming功能，可以滿足公司逐漸發展遇到的實時資料問題，再也不用擔心以前hive沒半小時執行一次任務，任務還偶爾出現執行不完的場景了。

大公司

很多傳統行業的大公司一直依賴傳統關係型資料庫來處理資料，花了很多錢購置硬體和服務。現在要“降本增效”，必然會對IT部門下手。大公司有錢，就可以招聘到專業的工程師，他們有過建設大資料平臺的經驗，在計算選型上可以根據自己的技術棧選擇合適的計算引擎。

另外，可以買一些MPP資料庫的服務，比如GreenPlum商業版、Vertica。商業版的很穩定，幾乎不會碰到棘手的問題，平時只管使用就行了，大大提高的運維、開發效率。對比下來會發現比以前使用傳統的關係型資料庫省了不少錢。

07 總結

基於多個計算引擎搭建大資料平臺是目前的現狀，針對不同的企業和團隊選擇適合自己的，同一個公司不同的業務也可以選擇不同的計算引擎。不考慮商業方案，就要根據自己的技術掌握情況，選擇自己精通的並且適合業務的。考慮商業方案的可以選擇商業的MPP，給開發和業務人員提供更好的環境和體驗。

05

自助分析系統

01 什麼是自助分析平臺

自助分析平臺是構建在大資料平臺之上的，依託於大資料平臺的資料研發能力，透過統一的資料服務，實現對資料查詢、分析的統一管理，為企業業務分析提供高效的資料決策支援，同時也避免資料工程師陷入繁雜的提數需求中。自助分析平臺是有計算機基礎的業務人員能夠快速上手的前端產品，既要有大資料的處理效能，有需要有簡單好用的視覺化分析能力，只有讓業務人員能夠快速掌握使用方法，和公司的業務結合起來，自助分析平臺才有價值。其實，一直以來，各大公司的資料分析平臺都只有一個目標——幹掉Excel。

02 自助分析平臺該有哪些模組

上面已經介紹了，自助分析平臺是用來查詢資料，探索資料的，需要具備Excel已有的功能，還要比Excel做的更好。

• 支援多資料來源接入

自助分析平臺要能夠支援多種資料來源、不同資料型別檔案的接入，能夠讓資料工程師和業務人員快速的把資料匯入到自助分析平臺中。需要支援傳統的關係型資料庫、Hive、檔案匯入（Excel、CSV、TXT等）。

• 多維度分析

能夠對匯入的資料進行快速查詢、過濾、聚合、排序、關聯等動態操作。比如業務人員已經有一些使用者基本資訊，它能夠透過匯入使用者名稱，透過使用者名稱關聯到對應的使用者分析資料。並能夠對不同型別的使用者進行分組聚合操作。以上所有的操作需要實現拖拽式，不需要讓業務人員寫一行程式碼。

• 豐富的視覺化

需要支援常用的視覺化圖形，如餅狀圖、環圖、同軸曲線圖、柱狀圖、散點圖等，使用者需要繫結自己匯入或者透過平臺清洗好的資料，既可以快速的生產對應的分析圖表，製作視覺化報告。

• 許可權管控

自助分析平臺是對公司所有的業務人員使用的，需要有對應的許可權管控。比如A使用者製作的資料圖表，B使用者是不能夠檢視的，只有A賦權給B後才能檢視。自助分析平臺中的資料也要進行許可權管控，比如敏感資料不能開放所有使用者，下載資料需要有流程審批等等。

• 高效能

資料分析查詢要快、自助分析要快、視覺化要快。很多自助分析平臺最終變成了資料下載平臺，其中很大一部分原因就是不夠快，雖說大資料了比Excel快多了，但是實際業務探索中，很多時候資料量就是百萬以內的，要是還沒有Excel快的話，人家為什麼要用你的平臺呢？所以，不管是資料量大，還是資料量小，都要快！在技術上是否要考慮大資料量和中小資料量使用不能的查詢計算引擎呢？

03 自助分析平臺架構

• 自助分析引擎

對於超大資料量的複雜查詢分析，我們可以使用Spark提交任務的方式來實現自助分析。對於中小資料量的資料我們使用MPP資料庫實現快速查詢。

• 視覺化

我們可以使用echarts支撐多種型別圖表展示，或者使用superset等開源自助分析專案進行展示。

• 許可權

為做到相互隔離和資料安全，後臺管控系統透過條件限制控制資料的授權，對手機號、身份證號、郵箱等敏感資訊管控端採用加密演算法防止資料洩露。

04 總結

實際中業務人員和IT團隊對於自助分析平臺的搭建都有自己的想法，也想透過資料來給公司去做一些事情，所以在建立自助分析平臺時，可以和業務人員不斷的溝通，先定一些主題資料，做成果展示，和業務人員以及領導分享，讓其參與評價和建議，不斷最佳化和改善，當相關人員都有參與感時，自助分析平臺才會持久發展。

最後，還是要提醒一下，自助分析平臺的目的是“幹掉Excel”，讓所有的分析結果儲存線上上，千萬不要讓其淪為資料下載平臺。