數棧是雲原生—站式資料中臺PaaS，我們在github和gitee上有一個有趣的開源專案：FlinkX，FlinkX是一個基於Flink的批流統一的資料同步工具，既可以採集靜態的資料，也可以採集實時變化的資料，是全域、異構、批流一體的資料同步引擎。大家喜歡的話請給我們點個star！star！star！

github開源專案：

gitee開源專案：

網際網路和移動網際網路技術開啟了大規模生產、分享和應用資料的大資料時代。面對如此龐大規模的資料，如何儲存？如何計算？各大網際網路巨頭都進行了探索。

Hadoop技術生態起源

1.Google三篇論文揭開Hadoop序幕

Google的三篇論文 GFS(2003)、MapReduce(2004)、Bigtable(2006)為大資料技術奠定了理論基礎。隨後，基於這三篇論文的開源實現Hadoop被各個網際網路公司廣泛使用。在此過程中，無數網際網路工程師基於自己的實踐，不斷完善和豐富Hadoop技術生態。

2.日臻成熟的大資料技術生態

經過十幾年的發展，如今的大資料技術生態已相對成熟，很多公司也都選擇開源的大資料框架構建自己的大資料平臺，如下圖：

Hadoop生態的大資料元件很多，每種大資料元件能解決特定場景的業務，所以大資料元件的選型是至關重要；下面通過袋鼠雲自研的資料中臺產品-數棧的整體架構介紹，來分析一些大資料元件的使用場景。

二、大資料元件使用場景分析

——以袋鼠雲資料中臺產品數棧為例

數棧是通用型的資料中臺產品，是十分複雜的工程。整體架構主要分五層：一是平臺層主要偏業務的上層資料應用；二是任務排程層主要是任務的定時排程和提交，需要遠端無狀態提交，對計算節點無侵入；三是資源管理層主要是cpu或gpu，記憶體等資源的動態管理，需要適配不同的資源排程元件；四是計算層主要是資料同步，實時計算，離線計算，演算法建模等，需要適配不同的大資料計算元件；四是儲存層主要是負責結構化和非結構化資料的的儲存，需要適配不同的物件儲存和本地儲存；五是管控層主要是支撐數棧產品的快速部署，升級和監控。

如下是數棧整體架構圖

1.平臺層

微服務，單點登入

平臺層架構圖

平臺層主要是偏業務的上層應用，數棧這邊實現的有離線平臺，實時平臺，演算法平臺，標籤引擎，資料資產，資料質量等應用；統一抽象了使用者認證中心（UIC），各個平臺的使用者認證統一跟UIC對接，這樣做的好處有兩個；一，只要一個應用登入，進入其他應用無需再次登入；二，對接客戶側的使用者認證體系，只要UIC對接就可以，各個平臺應用無需做改造；業務中心主要是抽象了平臺應用一些公共的模組並且提供rest api，例如血緣解析，後設資料地圖等功能。

2.任務排程層

分散式、水平擴充套件、外掛化

任務排程層架構圖

任務排程層是上層平臺應用和計算引擎的紐帶，所有的任務都要下發到這層，主要功能有兩個；一是任務的週期性定時排程和依賴性排程（任務與任務之間有上下游依賴會形成有向無環拓撲圖）；二是把離線，實時，演算法等任務提交到遠端計算節點；任務排程層是有袋鼠雲自研的框架DAGScheduleX來實現，DAGScheduleX是標準的分散式應用，有Zookeeper來做多節點應用協同，Master節點主要負責任務的排程策略和任務分發，Work節點負責任務提交到遠端的計算節點；Master和Work節點通過Akka通訊。

Work應用實現了一個Engine-plugin模組，它抽象了提交的介面，在把不同型別任務提交的具體實現以外掛化的方式封裝成一個個單獨的jar包，在以SPI的方式載入，這樣就能做到不同任務型別相互不干擾。任務的提交都是對接資源排程元件原生的API方式遠端提交，對計算節點無侵入。市面上開源的任務排程主流框架有DolpinScheduler，Azkaban等，如下是DAGScheduleX跟其他框架的對比圖。

對比圖

3.資源管理層

雲原生、外掛化

資源管理層管理的資源現在有3種，Memory（記憶體），CPU或GPU；數棧這邊適配資源元件有3種，Kubernetes，Yarn，雲資源列如阿里的MaxComputer；Kubernetes更適合雲原生場景，計算儲存分離架構；Yarn適合本地化私有云部署。

4.計算層

資料採集批流一體化、外掛化

計算層任務主要有資料採集任務、實時任務、離線任務、演算法任務等。

資料採集任務：“巧婦難為無米之炊”，沒有資料也就沒有後面的一切，資料採集作為基礎至關重要；所以一套資料採集框架對資料的準確性、穩定性，資料來源的自定義擴充套件等都有較高的要求；市面開源的框架很難都滿足。

所以數棧自研了資料同步框架FlinkX；FlinkX是基於Flink實現的分散式同步框架，並且實現了離線同步和實時同步一體化；如下是FlinkX架構圖。

如下是跟其他資料同步框架對比圖：

對比圖

實時任務：現在主流的實時計算框架有Flink，Sparkstreaming，Storm；

數棧選擇用Flink構建了自己的實時計算平臺。Flink是目前發展比較火的一個流系統，採用原生的流處理系統，保證了低延遲性，在API和容錯上也是做的比較完善，使用起來相對來說也是比較簡單的，部署容易，而且發展勢頭也越來越好，相信後面社群問題的響應速度應該也是比較快的。個人對Flink是比較看好的，因為原生的流處理理念，在保證了低延遲的前提下，效能還是比較好的，且越來越易用，社群也在不斷髮展。

如下是三個框架的對比：

對比圖

離線任務：離線計算現在主流的框架有Spark，Hive，MapReduce等，每個框架使用要看具體的業務場景；Spark是記憶體計算，所以耗記憶體，計算效率高，並且支援SQL，使用門檻較低；MapReduce中間資料可以落盤，所以記憶體要求較低，但是計算效率會慢，不支援SQL，有一定的使用門檻；Hive有兩種模式 on Spark 或者 on Mapreduce，支援SQL，統一的後設資料管理，適合構建資料倉儲；數棧是都適配了這三種計算框架，根據客戶不同的業務場景和機器資源配置來選擇。

5.儲存層

計算儲存分離，多種儲存引擎相容

數棧引入JuiceFS框架做儲存的適配層來遮蔽底層的儲存裝置，這樣就能靈活的適配各種儲存，對上層應用和計算引擎不需要做額外的程式碼開發。JuiceFS 是一款高效能 POSIX檔案系統，針對雲原生環境特別優化設計，所以更適合雲原生架構，讓計算和儲存鬆耦合,真正做到計算儲存分離。

6.管控層

一鍵視覺化、自動化、全域

管控層主要的職責是是對整個資料中臺應用做一鍵視覺化部署、升級、監控；因為整個資料中臺涉及的元件是很多的。有上層的平臺應用，還有底層的大資料元件，這些應用有十幾種，後續隨著業務的升入涉及的元件會更多。所以，靠人肉寫指令碼的方式很難在段時間的完成部署升級；市面上主流的框架類似CDH、HDH、TDH等都能做到大資料元件的部署和管控；但是他們只能對大資料元件，不支援自定義的應用程式。所以袋鼠雲自研了EasyManager應用來全域的管控業務應用和大資料元件，並且能快速支援一個新的元件無論是自研的還是開源的。

EasyManager是用go技術棧開發，核心是schema檔案，裡面描述了元件相關的資訊和各個元件的依賴關係；EasyManager主要分兩層，一是matrix server；二是agent server；matrix負責schema檔案的解析並把相應的引數和指令下發到agent，有agent負責應用的啟動，停止等動作；還引入了Grafana和Promethus，做應用監控資料的收集和展示；EasyManager現在能支援基於物理機，虛擬機器，Kubernutes的部署；如下是EasyManager架構圖：

EasyManager架構圖

以上是數棧整體架構介紹；但是隨著資料的不斷增長，客戶的業務複雜度的增加，技術架構也會隨之升級來迎接未來的挑戰。

未來展望

大資料技術迭代更新很快，一些新的大資料理念也層出不窮，數棧也會隨著迭代更新和架構升級；數棧近期主要在做批流一體和湖倉一體的研發；批流一體主要解決的是以相同的處理引擎來處理實時事件和歷史回放事件，保證有無故障情況下計算結果完全相同。湖倉一體主要做的是統一後設資料管理並能同時支援結構化和非結構化資料儲存和分析；對外能提供儲存層批流統一介面。

數棧整體架構中使用很多元件大部分都來自開源社群，我們在平時的開發中也沉澱和抽象出一些框架並且已經回饋給社群比如FlinkX，Easyagent等，還有即將開源的任務排程框架DAGScheduleX。

數智洞見｜資料中臺架構解析及未來展望

相關文章

數智洞見 ｜ 資料中臺架構解析及未來展望

相關文章

數智洞見｜資料中臺架構解析及未來展望