百分點萬億級大資料平臺的建設實踐

從網際網路、移動網際網路到物聯網，資料量之巨大已突破想象邊界。與此同時，實時資料分析的需求日益增長，那麼，當資料量達到億級、百億級甚至萬億級規模，實時資料分析如何來做？尤其在To B/G來說，大多數企業和政府客戶區別於網際網路企業，自身不具備技術團隊，缺乏技術運維能力，因此在搭建本地化萬億級大資料平臺時，如何交付更為標準化、透明化設計的產品成為最大挑戰。

嘉賓：百分點研發總監、大資料平臺技術負責人趙群

在中國第十屆資料庫大會DTCC 2019上，百分點研發總監、大資料平臺技術負責人趙群分享了《萬億級大資料平臺的建設實踐》的主題演講，以國家級大資料平臺建設實踐，剖析百分點從0到1，在探索落地超大規模實時資料分析典型架構的實戰經驗。

眾所周知，當大資料平臺在應對超大規模流量之時，除了要面對超大規模資料量引起的儲存及效能遇到的挑戰外，維護整體平臺的穩定性和可靠性變的更為重要。舉例來說，在出現硬體故障、高峰流量甚至異常流量的情況下，平臺內部元件之間問題就會層層傳匯出現蝴蝶效應，最終導致系統崩潰。因此，萬億級大資料平臺在搭建中首先要在設計理念上進行突破。

百分點採用了服務透明化、管理精細化的設計理念，透過將每個元件的儲存、處理、查詢能力標準量化，保證穩定可控。具體來說，每個元件容量都會經過設計，支援線性擴容，且元件的能力指標和當前的狀態可以進行視覺化展現，同時基於標準值建立預警機制和對應處理措施，另外集合百分點大資料平臺對服務和資料提供精細化的管理。

比如，趙群介紹，以設計Kafka能力為例，將整體分為四個階段：1.在正常設計狀態下的讀寫正常階段； 2.在流量加在階段，受限流影響會存在積壓延時，這個階段需要考慮擴容； 3.讀寫爭搶階段，為保障“寫”入“讀”的能力就會下降，這個時候必須擴容；4.超流量階段，就會出現服務異常情況。也就是說，在整個大資料平臺部署中根據叢集大小和標準值，在監控中心配置相應的預警線，才能在四個階段實現元件能力的透明可量化和監控管理精細化。

窺斑見豹，對於萬億級實時資料分析面臨的一些問題和挑戰，也要從整體上進行規劃。趙群表示，一般來說，在對大資料平臺進行規劃之前，需要把平臺分為五個維度：一是資料儲存；二是實時處理；三是離線處理；四是資料查詢；五是系統運維。並且，當進行一個專案或者業務評估的時候，為了聚焦技術挑戰點，百分點會把專案上的業務性挑戰轉換為技術需求，基於這五個維度進行應對和實現。

以百分點國家級大資料平臺建設為例，五個維度的技術挑戰如下：

 一是兩地雙中心。

由於大資料平臺是兩地雙中心，因此除了將跨資料中心的資料同步之外，還要從業務層面實現跨資料中心的透明訪問。即，使用者不用關心資料儲存在哪一個IDC，就可以直接進行跨中心的資料查詢和分析。

 二是資料儲存。

平臺主要面對來自兩類資料儲存的挑戰：一是結構分析資料，結構化日誌型資料日增處理量 100TB+，支撐寫入超過200W/s的吞吐量；二是檔案儲存方面的資料，為2TB/天的處理量。除了中心處理資料目標要達到2000億+/天之外，業務方還提了一個需求，要求資料從接入訊息通道到業務可以查詢的延時小於30秒。可以發現，在實時處理方面平臺要應對巨大的挑戰。

基於如此大的資料量，還特別需要考慮熔斷及限流方案來確保整體服務的穩定，包括實時處理時的延時、峰值的處理能力，甚至是在一些異常流量的情況下都需要保證大資料平臺是穩定的、業務平臺是可靠的。

 三是離線處理。

在離線處理方面，同樣由於資料量的巨大，離線統計的任務也會消耗大量資源。但在保障很多離線處理任務正常進行的同時，不能影響即席查詢和寫入的效能和效率。

 四是資料查詢。

在資料查詢方面，一是業務系統對海量資料的低延時且複雜的即席查詢需求、跨資料中心的查詢能力，以及業務系統在呼叫查詢時需要實時反饋結果。二是結合之前跨中心的透明訪問，需要資料中心的查詢和分析對業務系統是完全透明的，同時也要滿足效能和延時性的要求。

 五是系統運維。

面對系統運維經常會出現一些硬體和網路的故障，需要保證在發生重點故障時及時地發現問題，保障系統在出現如裝置當機、磁碟損壞等常見故障情況下系統的可靠性和穩定性。

面對萬億級大資料平臺的這些挑戰，百分點基於全新的架構設計理念搭建了以Kafka、Spark Streaming、ClickHouse、HBase、Ceph和ES為基礎的大資料平臺，不僅驗證了設計理念的可行性，在整個過程中，百分點還沉澱了很多有價值的評測報告，涉及查詢評測、PageCache影響、Raid5資料恢復、橫向擴充套件影響評測和寫入穩定性等。

現在，這個平臺正承載著萬億級資料的儲存、處理和應用，能夠支援線上2000+億/天、峰值500+萬/秒的資料處理，且在實時性、穩定性、異構儲存能力方面同樣表現優異，在本地化部署萬億級大資料平臺方面引領行業前沿。

那麼，這個超大規模實時資料分析架構具體是如何實現的？

如上圖所示，百分點將整個平臺分為兩層：大資料技術平臺層和資料資產管理平臺。

圖：趙群 在 DTCC2019 大會分享現場

一是大資料技術平臺。

在雲端計算、大資料、人工智慧等技術融合的時代，開源已變得無處不在，對於許多大企業來說，開源大資料分析已經成為日常業務中一個必不可少的組成部分。因此，在這一層百分點採用了比較常見的開源元件，包括三個方面：資料接入層、資料處理層，以及資料查詢與儲存。.其中，透過資料接入層的各式元件接入資料後，在資料處理方面分為離線計算、實時處理、機器學習處理3類處理方式。資料儲存與查詢層包括列式Hbase、全文搜尋Elastic Search、Kylin、ClickHouse等，這些元件都會根據客戶的業務需求，選擇合適的元件來支援即席查詢或全文搜尋、OLAP分析。

二是資料資產管理平臺。

百分點基於底層元件建立了視覺化、互動式開發的SaaS開發平臺。資料治理負責對大資料技術平臺內各類資料提供資料生命週期的管理：包括資料標準、後設資料管理、資料質量、資料生命週期管理等，在整個資料資產管理平臺中提供基礎的資料管理支撐。資料資產管理整體包含四個部分：資料管理、資料加工、資料產品加工與管理和資料服務。其中，資料工廠包括離線和實時部分，與上文介紹的底層元件資料處理分類一一對應；百分點機器學習平臺基於演算法模型的管理形成整體的機器學習平臺，除了常用的Spark Mlib、R、Python等機器學習演算法，也融合了TensorFlow、Caffe、PyTorch等深度學習框架；百分點還透過資料工廠、機器學習平臺和標籤知識圖譜平臺進行資料處理形成資料集、標籤、知識圖譜、模型等資料產品；整個平臺的資料資產形成的各類資料產品，還可以透過資料服務的方式對外支撐業務應用。

回看整個架構，從業務角度理解，實際就是目前業內火熱討論的資料中臺概念。百分點在最近幾年一直在落地資料中臺，隨著在重點行業的深耕，基於資料中臺之上逐漸沉澱了行業的業務中臺，更貼近客戶的業務場景，有效實現業務價值。

針對超大規模實時資料分析平臺的關鍵挑戰，百分點基於這個典型架構基礎，在分解技術需求後，以ClickHouse為平臺核心儲存，實現了跨資料中心的萬億級資料的查詢與分析；Kafka為訊息通道，來實現資料路由，資料緩衝、承擔峰值壓力；應用SparkStreaming實時資料處理，並進行處理能力控制、資源控制和資料限流；ElasticSearch支援跨資料中心的全文搜尋；同時，基於HBase + Ceph封裝了百分點自研的OSS服務，來支撐線上高併發、高吞吐量的檔案儲存。

為了應對整個專案的關鍵挑戰，百分點在核心元件架構選型中做了很多技術實踐。以核心儲存元件為例：

針對業務場景需求：1.超大規模的單表查詢/分析。2.有一定的併發要求，透過多個業務系統做查詢/分析。3.實時性要求。

拆解成技術需求如下： 1.PB級儲存。2.高效能查詢/分析能力。3.低延時。4.需要考慮一定的壓縮比。 5.系統支援跨中心查詢。

在選型上，百分點基於ClickHouse、Presto和HAWQ進行了寫入、儲存等多維度的評測，並且針對實際業務場景，在同樣的資料集下挑選4類典型SQL，每個引擎根據測試維度選擇最優的儲存格式。

從查詢的對比測試結果來看，ClickHouse呈現出了數量級的優勢： 1.基於查詢/分析的效能，在單表的場景下ClickHouse完全佔有優勢。2.由於查詢效能的優異，在併發響應上同樣表現出色。3.實時寫入方面，ClickHouse評測寫入場景最高已經達到單節點60Wrow/s，此時的寫入仍非常穩定，這是由於 ClickHouse自身的分散式設計是一種邏輯上的拓撲，水平擴充套件非常容易。

在選擇ClickHouse作為大資料平臺核心儲存選擇後，百分點繼而對ClickHouse進行了整體設計，主要包括以下幾點：

1．雙中心ClickHouse叢集。百分點透過配置檔案將兩個資料中心的CLickHouse配置成跨中心的分散式表，雖然實際查詢和分析是基於兩個中心的資料做匯聚，但對業務系統訪問而言是完全透明的，呈現給業務人員的就是一張表。在實際測試場景中，這種配置方式對查詢會造成大約1/4~1/3的效能損耗，對於毫米級的響應速度來說，這個影響是完全可以接受的。

2．禁止分散式寫入。透過在客戶端控制寫入ClickHouse本地表，實現客戶端負載均衡。這是因為，ClickHouse本身提供了分散式表的寫入方式，但關係到對ClickHouse自身的穩定性評估，在平臺內部是絕對禁止使用的。

3．最佳化引數設定。ClickHouse副本是透過ZooKeeper來管理後設資料的，在使用中總會遇到穩定性問題，比如變成只讀、不可寫或者資料不一致等問題。關於是否使用複製集(Replication)，很多社群朋友在使用時大都很謹慎，有些公司甚至因為不穩定都沒有配置副本。對此，建議最佳化一些引數設定，針對ZooKeeper管理的節點/表情況進行一定的控制，同時配合穩定寫入，這樣在使用複製集(Replication)時候就可以保證穩定性，同時還解決了在部分節點出現問題時資料的完整性和可靠性問題。

最佳實踐之引數配置

在實踐中，百分點已經最佳化了一些引數，沉澱出了非常穩定的引數配置，並且在大會上進行了公佈，涉及查詢導致程式奔潰問題、使用Replications時與ZooKeeper通訊引起的叢集狀態異常等常見問題。

4．基於Nginx實現負載均衡，同時控制查詢入口機器。實際上，分散式表的配置只需要在幾個入口機器進行相關配置就可以，也可以使用LBS元件。同時針對熱資料做查詢預熱，將日誌表分析出來近期或者最近幾天的客戶經常採用的SQL進行分析，在資料資產管理平臺裡面，透過資料工廠將其變成離線排程的任務並主動快取。這樣一來，針對熱資料場景的查詢會走PageCache快取，效能上也將得到數量級的提升。

5．收集Nginx中的所有查詢日誌並分析，基於Grafana進行視覺化展現。一方面，這對蒐集和最佳化線上的查詢語句特別重要，因此在平臺上線後，百分點會針對長尾的查詢進行分析。另一方面，系統對於低效或者不標準的SQL寫法的反饋，也會推動業務系統進行SQL最佳化。

一個不能忽視的關鍵問題是，如何保障多中心核心儲存ClickHouse的穩定？

對此，百分點定義了危險區域和安全區域。趙群介紹，根據寫入及業務情況查詢的併發情況定，百分點得到這樣一個關係：比如以10W/s提交（包括併發提交情況），可以支撐90併發數的查詢，當超過這個數的時候，節點就會出現不穩定情況。

關於如何評估節點穩定性，首先要結合ClickHouse的特性，因其在每次提交都會生成一個Part，後臺會有非同步任務進行Part合併，當Part數量預設超過150個的時候，ClickHouse會進行強制寫入延時，當Part數量超過300的時候直接就拋異常了。因此，針對這種特性需要實現寫入part和part合併的相對均衡，也就是說保持分割槽中Part數量是一個相對穩定的值，不能隨著時間增加而增加，如果不這樣做，時間積累到一定程度肯定會現出問題。進一步說，Part的穩定代表著經過估算的提交頻率的穩定。這是什麼意思呢？簡單來說，一個本地表每分鐘提交的頻率是固定的，變化的只是批次提交的資料量。比如，本地表每分鐘提交20次，每次最多提交30W。這樣即使出現業務高峰期，Part數量也是不變的，變化的只是單個part中的資料量。這也是一種流量控制，透過這樣就可以很好地評估ClickHouse叢集的設計寫入和查詢能力。

以此類推，基於這個理念百分點應用SparkStreaming同樣實現了處理能力評估和流量控制能力。

以一個例子來說明服務能力透明化的整體思路：假設寫入節點為100，SparkStreaming的時間視窗是3秒，每個Executor處理能力是3W/s，每分鐘就會生成20個Part。如果需要300W的處理能力，就可以配置Executor的數量為100。每分鐘生成2000個Part，平均到一個節點是20個Part。這樣一來，就可以保障提交頻率和資料量的穩定，即使流量壓力加大，也能直接加大時間視窗（比如加到6秒），這樣Part的數量就會減少一半。

值得注意的是，萬億級大資料平臺進行整體處理能力評估時，一定是要遵循硬體利用率的最大化，細化到每一個任務資源配額，還要基於資源配額的元件處理能力設計值。為了保證資料的可靠性，在選擇磁碟Raid時，強力推薦試用Raid5，同時針對Raid5方式做熱備份，這樣當一塊硬碟壞了之時就會自動替代，並不會引起一些問題。不過在實際專案中，經過多個維度的測試後發現，Raid在提升查詢能力方面十分有限。

最後，為了資料平臺的持續運維與監控設計和實現，百分點擁抱開源，基於Ambari、Zabblx和Grafana做了一套視覺化監控體系。

具體來說，透過Ambari進行大資料基礎元件的安裝並進行相關監控；Zabblx負責服務、網路、硬體相關的情況，雖然傳統但實際應用中非常高效；同時結合Zabbix和Ambari Metric監控資訊接入到Grafana中做更最佳化的展現；對於採集不到的資訊，透過Exporter放到Prometheus中進行監控。實際上，ClickHouse本身有一些支援的外掛來做監控，為了進一步使元件服務透明化，百分點還增加了很多服務能力方面的監控，並根據能力配置相應的警戒線，比如會監控ClickHouse當天的資料分佈情況，寫入吞吐、查詢併發、處理延時等。

百分點認為，面對如此巨大的資料量，在萬億級大資料平臺建設中架構是重中之重，架構設計的好壞直接關係到平臺整體是否可以穩定執行。

百分點國家級大資料建設實踐，在專案規劃、問題分解、測試選型等整個流程中，貫穿了百分點萬億級大資料分析平臺的核心設計理念：服務透明化、管理精細化。百分點為客戶交付了自主可控、跨資料中心的解決方案的同時，也希望以自身實踐經驗分享回饋社群，推進大資料平臺架構創新和行業落地。