來源：DataFunTalk
導讀 本文是由浙江數新網路有限公司為我們帶來的《新一代雲資料平臺架構演進之路》的技術分享。
本次分享分為四個部分：
1. 大資料發展回顧
2. 雲資料平臺演進趨勢
3. 雲資料平臺技術架構
4. 雲資料平臺實踐案例
分享嘉賓｜原攀峰 數新網路 CTO
編輯整理｜邢朋彬 小波科技
出品社群｜DataFun
大資料發展回顧
資料平臺是指提供資料整合、資料儲存、資料管理、資料處理、資料分析、資料服務等資料全生命週期能力的軟體平臺。資料平臺能夠遮蔽底層大資料引擎的底層細節，降低資料建設和使用門檻，對外提供統一的服務平臺，幫助企業實現資料驅動業務。下面我們將從不同發展階段來介紹大資料平臺的演化和大資料基礎設施的演進過程。隨著技術的迭代更新，資料平臺也在與時俱進、不斷進化，回顧整個發展歷程，大致可以分為三個階段：
（1）傳統資料時代：上一世紀 80 年代到 2000 年左右處於這一階段。資料平臺和計算平臺由 Oracle、Teradata 等資料庫廠商提供，資料應用以 BI 報表的應用為主，主要由 SAP、微策略等 BI 公司提供能力。（2）大資料時代：從 2000 年以後就進入大資料時代。該階段以 Hadoop 的誕生和推廣為主，得到了廣泛的發展和應用，各個廠商也以此為基礎推出了自己公司的資料中臺、資料平臺等產品。在該階段資料平臺還是以企業內部使用場景為主。（3）雲資料時代：隨著雲端計算技術的普及和發展，大資料平臺也隨之進入了雲資料時代。國外誕生了諸如 Redshift、Snowflake、Databricks 等雲資料平臺公司，國內以阿里為例，在阿里雲推出 Max Compute、PAI、EMR 等雲上計算引擎，以及御膳房電商資料開放平臺、DataWorks 雲資料開發平臺等產品。數新網路是在雲資料時代背景下孕育而生，公司的宗旨是為客戶提供全棧式的大資料平臺和服務能力。上圖中最右側部分是數新網路提供的國產開源可控雲資料平臺 DataCyber，整體基於開源技術底座，自底向上依次提供了大資料計算儲存引擎、雲資料平臺、面向垂直行業的資料中臺、以及應用層的輕量化分析套件、應用市場等能力。透過回顧資料平臺的發展和演化歷程，可以總結出大資料基礎設施演進的四個技術階段。
（1）資料倉儲階段：以 OLAP、BI 報表分析為主。（2）資料平臺階段：大規模資料儲存和計算，主要為批處理計算，同時結合大量線上服務的形式。（3）資料中臺階段：以阿里為代表提出資料中臺的理念，基於資料平臺，結合資料標準、資料體系、組織變革機制，構成整個資料中臺能力。（4）雲資料平臺階段（資料雲）：以雲數倉為代表，典型特點是支援多租戶的資源彈性伸縮和按量計費，由此發展出現流批一體、湖倉一體、數智一體、雲原生、存算分離、雲原生、開源開放等技術方向。雲資料平臺的定義：也稱為雲資料倉儲，是基於雲端計算技術、支援多租戶的資料平臺技術和產品，為使用者提供海量資料探勘和分析服務。我們理解，雲資料平臺更多指的是一種現代化的資料架構，其部署模式可以部署在本地資料中心、雲上或混合雲等多種環境。在介紹雲資料平臺的演進趨勢之前，我們先回顧一下大資料平臺技術架構的演進過程。主要分為四個階段：共享儲存架構、大規模並行處理、SQL-ON-Hadoop、雲原生架構。每個階段都有各自的技術特點，也是適應當時環境而產生的。
（1）第一代架構：以共享儲存的架構為代表（share storage），支援的節點很少，擴充套件困難，只能支撐報表分析的場景為主。（2）第二代架構：以大規模並行處理 MPP 架構為代表（share nothing），節點規模能夠達到百級，能夠處理的資料規模得到了一定提升，但仍存在限制。（3）第三代架構：以 Hadoop、Spark 為代表，基於分散式的儲存、分散式的資源排程，獲得了更大規模的叢集規模及資料處理規模。（4）第四代架構：雲原生架構，在新的網路傳輸速度背景下，基於統一的分散式儲存、資料倉儲、資料湖技術，支援多種型別計算引擎，從而滿足更多分析場景的需求。下面將圍繞雲原生架構，介紹雲資料平臺的幾個重點技術演進方向。在雲端計算+大資料的背景下，無論是儲存引擎，還是計算引擎、實時分析引擎，都呈現出多元化的趨勢。
（1）儲存引擎：雲上儲存如 S3、OSS 發展迅速，私有云和公有云長期並存，因此本地儲存、雲上儲存也將長期並存。（2）流批計算引擎：經過多年的迭代演進，Spark 和 Flink 逐漸成為企業級主流計算框架，目前呈現出擅長不同場景的態勢：Spark 擅長高吞吐量的計算，以及機器學習、圖計算等場景；而 Flink 則擅長實時性要求高、流批一體等場景；不同企業的選擇也不盡相同。（3）實時分析引擎：以 MPP 架構為例，近年來不斷湧現新的 MPP 查詢引擎、MPP 資料庫，每個引擎都有各自擅長的場景，並處於快速發展和升級中，因此，各個企業的選擇差異較大。基於大資料引擎多元化的這一趨勢，雲資料平臺需要能夠適配支援多種型別的計算和儲存引擎。第二個演進趨勢是實時化以及流批一體。實時處理的需求在廣泛的行業都有普遍訴求，尤其是電商、物聯網等。
實時資料架構最為經典的是 Lambda 架構和 Kappa 架構，以及由這兩種架構衍生的一些混合架構方案。以目前的技術發展來看，很難做到統一到一種架構。因此，我們需要的是根據不同的場景，選擇最為合適的實時資料架構。（1）Lambda 架構的核心思想是提供流處理和批處理兩種處理鏈路，從而發揮流處理和批處理的優勢，透過批處理提供全面、準確的資料，透過流處理提供低延遲的資料，從而達到平衡延遲、吞吐量和容錯性的目的。為了滿足下游的即席查詢，批處理和流處理的結果會進行合併。它適用於已有完備的離線數倉平臺，實時計算較少的場景。（2）Kappa 架構的核心思想是透過改進流計算系統來解決資料全量處理的問題，使得實時計算和批處理過程使用同一套程式碼。優勢在於統一了流批資料邏輯，但受限於處理效能，適用於以實時計算為主，全量資料吞吐量可控的場景。第三個演進趨勢是湖倉一體。資料倉儲和資料湖的介紹和對比，這裡不再詳細展開，在企業發展的不同階段，需要做到兼顧資料倉儲和資料湖的優勢，達到更好的資料管理和使用能力。在湖倉分體階段，本質上資料是沒有打通的，是存在壁壘的。而湖倉一體階段的核心是資料統一儲存，湖倉共享同一份資料進行計算或者分析。所以湖倉一體架構可以更加靈活的支援各種分析場景、機器學習、BI 報表、推薦演算法等。
（1）在資料倉儲上支援資料湖（左右結構）：一般是透過在數倉中建外部表來實現，解決資料倉儲如何更加靈活，以數倉為核心，支援訪問資料湖。代表廠商有 Snowflake 等。（2）在資料湖中支援數倉能力（上下結構）：一般是以資料湖儲存為基礎，在資料湖之上構建資料倉儲的服務層，強化資料治理和資料服務的提供。代表廠商是 Databricks 等。這兩種方案本身沒有優劣之分，需要企業結合自身的技術棧和資料需求，選擇適合企業現狀和未來規劃。第四個演進趨勢是雲原生、存算分離。Hadoop 大資料處理框架在長期的發展中一直是存算耦合的方式，在當下企業資料中心網路進入萬兆、十萬兆頻寬，資料規模增長顯著高於資料計算需求的背景下，導致存算資源很難進行合理分配，存算耦合的優勢變得越來越弱。另外，資料湖、雲原生、物件儲存等技術的發展，也都推動了企業大資料基礎設施朝著存算分離的架構方向演進。
（1）基於 Hadoop 的存算分離架構：將 Yarn 叢集和 HDFS 叢集分別部署兩個叢集，從而實現儲存與資源管理的解耦，這種方式增加了一種額外的運維負擔、以及本地讀的效能損失，但是根據相關企業的實踐經驗來看，損失可控，對於關注大資料平臺成本、同時以私有云為主的場景下，是可以採用這種方案的。（2）雲原生存算分離架構：該架構優勢在於資源彈性化、資料雲上化。在該架構下，儲存叢集、資源排程、計算引擎是高度解耦的，底層儲存可以是 HDFS，也可以是 S3 協議實現等；資源排程則完全擁抱 K8S，計算引擎可以支援多種主流引擎。第五個演進趨勢是多雲、混合雲、資料雲。對於企業來說，資料中心同時在公有云、私有云部署越來越成為常態，在此背景下要求雲資料平臺具有同時管理本地機房資料和雲上資料的能力，達到基於一套平臺對不同資料進行管理的效果，並且要求雲資料平臺具有跨雲資料管理的能力。這也必然產生企業之間、企業內部的跨雲資料流動問題，需要有相應的機制進行安全保障。例如，隱私計算技術用於解決不同企業之間的資料平臺之間的資料安全流動。
以上介紹了雲資料平臺的技術演進趨勢，下面將為大家分享現代化雲資料平臺的典型技術架構。
上圖所示是一個典型的雲資料平臺總體技術架構，自底向上依次分為幾部分構成：（1）資料來源：平臺支援多種型別的結構化資料、半結構化資料、非結構化資料。（2）湖倉儲存引擎：提供大資料統一儲存能力，支援 HDFS 和物件儲存兩種分散式儲存系統，支援資料倉儲、資料湖的主流儲存格式，支援針對資料湖場景進行查詢加速。（3）資源排程框架：支援 Yarn 和 K8S 兩種分散式資源排程能力，能夠同時支援存算耦合、存算分離的資料架構，覆蓋傳統大資料叢集資源排程、雲原生彈性資源排程的場景。（4）計算分析引擎：支援 Hive/Flink/Spark 等流批引擎、TensorFlow 等機器學習引擎、TSDB/Neo4j 等專用計算引擎；支援 GaussDB/StarRocks 等 MPP 分析引擎、Presto/Impala 等聯邦查詢引擎；支援離線數倉、實時數倉、湖倉一體等開發場景。多元異構引擎透過 Hive 後設資料作為後設資料標準實現後設資料打通和統一管理。（5）雲資料作業系統核心：提供通用的技術服務元件，銜接底層大資料引擎和上層資料開發治理平臺，這裡重點展示了幾個最為核心的元件：統一後設資料系統、統一引擎接入閘道器、統一任務排程系統、資料整合系統、跨網傳輸服務；其中，跨網傳輸服務是專門用於解決混合雲等多雲場景下資料高速、安全流通的基礎服務，例如，隱私計算場景下的密態資料傳輸。（6）資料開發治理平臺：圍繞資料的採集、開發、運維、管理、服務、質量、安全等全生命週期，提供一站式全鏈路的資料開發和服務平臺。（7）平臺管理：整個平臺的支撐系統，包含租戶、賬號、許可權、專案、資源等基礎能力，通常由一個多租戶技術元件來承載實現。限於篇幅原因，下面將主要和大家分享統一後設資料系統、統一排程系統、資料整合系統這幾個核心技術元件的架構實現。為了能夠適用於多元異構的大資料引擎元件，統一後設資料服務支援兩種能力：第一種是與 Hive Metastore 實現打通，支援 Hive 後設資料，透過 Hive 後設資料為計算分析引擎提供後設資料管理能力。第二種是擴充套件支援更廣範圍資料來源的後設資料管理能力，基於計算引擎的自定義 Catalog 擴充套件機制，為 Spark/Flink 等引擎提供後設資料能力。
基於業界開源的後設資料標準提供後設資料能力，主要體現在與 Hive Metastore 進行互動，實現對 Flink、Spark 等計算引擎的管理。透過後設資料介面實現多元異構系統的統一後設資料儲存和管理，實現外界後設資料主動發現、多計算引擎後設資料互通、跨多源計算。其核心能力主要包括：後設資料許可權控制、統一資料許可權、角色許可權配置、訪問日誌審計等。其核心能力主要包括：湖表管理與最佳化、資料生命週期管理、資料血緣、儲存分析與最佳化等。
排程系統主要分為兩部分：Coordinator 叢集和 Worker 叢集。整個排程系統的大腦，主要職責包括：作業排程、資源排程、作業例項生成以及作業例項下發、對外提供服務 API 等。技術架構關注點：高穩定性、高可用性、高併發。主要職責包括：負責作業的實際執行過程，可以是本地執行，也可以是提交到遠端執行；技術上核心關注多種型別任務的適配性、擴充套件性、資源隔離性等方面。從功能上，需要覆蓋不同型別的作業，多種週期排程，靈活的依賴關係，補資料、斷點重跑等完備的排程功能；從效能和可用性上，排程器和執行器需要滿足分散式無中心的設計，能夠實現水平擴充套件和故障轉移。值得特別說明的是，在超大規模作業排程的場景下，需要進行技術架構的進一步升級，包括透過按租戶進行 Coordinator 叢集水平擴充套件、排程後設資料分庫儲存等技術手段實現排程系統的高可用和穩定性。資料整合系統的核心功能是實現異構資料來源之間資料的高速整合，目前主流的資料整合採用 Spark、Flink 等分散式計算引擎實現資料的高效整合。（1）在功能方面，能夠支援批次同步、流式同步、全量同步、增量同步等場景。（2）在架構方面，由於採用的是分散式計算引擎，能夠根據資料規模決定計算資源，具有較好的水平擴充套件能力。（3）在網路方面，需要能夠針對雲上、混合雲的複雜網路場景，解決跨網段的傳輸能力。
透過以上介紹，相信大家對數新網路雲資料平臺的技術架構也有了一定的瞭解，其關鍵技術點主要是：異構引擎計算、統一後設資料系統、統一排程系統、資料整合系統和一體化架構。
該案例是面向產業生態建設的客戶，其主要以資料為驅動力，加強企業的設計研發、生產製造、市場服務等，並且對企業資料資產進行全面工具化管理，針對合同、製造、適航、績效等七大業務場景提供資料服務，提升企業生產、管理、運營的效率。數新網路根據客戶的需求場景，為其量身打造了流批一體架構的一站式大資料開發平臺。透過異構資料採集、流批一體計算、資料服務、資料應用等功能一站式支援客戶的各個場景，大大提升了客戶的生產效率。
該解決方案是基於數新網路自主研發的雲資料平臺（CyberMeta）來實現的，該平臺是高度整合、一站式的全鏈路平臺，能夠根據客戶的業務場景和資料架構輸出定製化的解決方案，例如離線數倉、實時數倉、流批一體數倉、湖倉一體等方案。
05
Q1：怎麼實現無中心化？
A1：該問題是基於排程系統的問答。叢集去中心化設計的關鍵點在於如何設計合理的資料分片策略。以排程系統為例，排程系統的後設資料是儲存在 Database 中的，可以直接基於 Database 做業務後設資料的分片，如不同節點負責拉取和處理不同租戶或專案的作業排程，根據業務場景選擇合適的分片邏輯。Q2：如何實現跨不同 VPC 的打通？支援哪些雲？A2：跨不同 VPC 打通需要基於雲廠商提供的 VPC 網路打通方案來實現，並且雲上部署的大資料產品支援的網路部署模式也不完全相同。因此，需要結合大資料引擎的部署情況以及雲廠商對 VPC 網路通道方案進行合理的技術方案設計與實現。A3：後設資料服務核心提供兩個能力：一是構建統一的後設資料服務，透過後設資料主動發現與採集，實現後設資料統一儲存，提供統一的後設資料服務，實現儲存、計算和服務的全鏈路後設資料管理能力；二是提供後設資料產品化的能力，包括資料資產管理、後設資料許可權管理、後設資料治理等能力。Q4：整體平臺的雲原生程度如何，部署架構是怎樣的？A4：數新網路提供的雲資料平臺採用的是兩種技術路線並行：一是傳統的（非原生的）技術架構；二是雲原生技術模型，基於存算分離的架構實現。兩種技術架構主要是適用於不同的客戶：對於追求穩定並且資源不敏感的使用者，我們會提供非原生的技術架構，例如透過 Hadoop+Spark/Flink 實現資料的儲存、計算；對於資源敏感且對雲原生接受度高、業務場景關注資源彈性伸縮的客戶，我們會選擇雲原生的技術架構提供服務。目前部署上支援私有云部署、公有云部署、混合雲部署。A5：在同一租戶內部或者企業內部場景下，實現思路主要體現在以下幾個方面：一是透過 OpenLDAP+Kerberos+Ranger 等安全元件，支援儲存的安全認證和管控；二是基於統一的後設資料服務，管理分佈在混合雲上的不同資料中心的後設資料資訊，並做好資料許可權管理；三是敏感資料做好資料加密、資料脫敏等安全加固，完成處理後做好計算結果的保護；四是在跨網傳輸時做好資料安全傳輸。在跨租戶場景下，資料安全管理核心需要保障不同租戶的資料不被洩露的前提下進行安全使用。可以藉助於可信資料沙箱、隱私計算等技術，基於底層的大資料引擎底座和大資料作業系統核心服務，構建多方之間的聯合資料分析、聯合建模預測等資料流通機制。A6：流批一體核心解決的是資料處理邏輯的統一性問題，目前主要採用的是基於Flink做流批一體實時數倉。互動式分析是針對高併發、低延時實時分析處理資料的場景，例如基於互動式分析引擎+ BI 工具對資料進行多維分析和業務探索，它與流批一體計算針對的是不同的資料處理場景。至於流批一體機器學習，業界有阿里開源的 Alink 機器學習平臺，感興趣的話可以瞭解一下。A7：目前這幾個資料湖引擎都處在快速迭代更新階段，因此不同版本的功能和穩定性會差異比較大。目前數新網路在資料湖引擎方向上面向客戶輸出的是 Hudi 和 Iceberg。A8：這兩種資源排程框架是根據不同客戶的場景選擇使用哪種資源排程框架。例如客戶已經有 Hadoop 叢集，我們就可以構建 Spark/Flink on Yarn 的架構，直接採用 Yarn 資源進行排程。如果客戶資料已上雲或者已有 K8S 叢集，那麼我們會建議基於 K8S 構建大資料平臺，Spark/Flink 也都可以不同的 K8S 部署模式。當然，也有少數客戶同時有兩種場景的需求，此時客戶也是可以同時使用 Yarn 和 K8S 分別管理不同型別的計算資源叢集。Q9：Analysis Ready Schemas 具體指的是什麼？A9：這個概念是指透過主動後設資料收集等方式，完成資料集 Dataset 的 Schema 收集及結構化、歸一化，資料整合系統能夠基於收集的 Schema 資訊，方便地定義和配置資料同步任務，完成資料的提取、傳輸和載入。Q10：資料開發是如何使用後設資料服務進行開發的？A10：後設資料服務的使用場景很廣泛，在資料開發場景中，例如 Web IDE 可以基於後設資料檢視庫表資訊、UDF 資訊、實現表名稱、表欄位自動補全等功能。在資料管理場景中，可以基於後設資料提供資料資產目錄，例如支援資料地圖、資料治理等功能的實現。尤其在資料治理場景下，還可以實現智慧化的能力，例如透過後設資料系統探查到上游表發生了變化，可以自動對下游任務進行告警，甚至是自動化處理等。A11：以數新網路的產品為例，不同的客戶採用不同的儲存方案，有些客戶是雲化的，有些客戶是本地的。雲化的場景主要是在 S3 或者 OSS 中儲存，本地的以 HDFS 儲存為主。在混合雲的場景下，資料儲存還可能是同時包含雲化和本地的。A12：具體可以分為兩種場景：一是基於資料湖建倉，資料透過流式採集的方式彙集到資料湖中，基於湖資料進行分析、計算等。但隨著資料體量的增大和企業不同階段的發展，資料管理、標準化、規範化的訴求也不斷增加，此時結合湖倉一體的優勢，在資料湖的基礎上構建資料倉儲，以更好的實現資料的管理和處理；二是在完備數倉的基礎上打通資料湖的能力，該場景不同於湖上建倉的上下分層的結構，而是左右分層的結構，透過外表等機制支援湖和倉的打通，該場景在嚴格意義上講並沒有完全做到資料集中化儲存一份。A13：不完全等同。新一代雲資料平臺體現在很多方面，雲原生只是其中一個方面，還包括多雲、混合雲、多元異構引擎、流批一體、湖倉一體等方面。雲原生資料湖只是雲資料平臺的一種技術架構和實現路徑。Q14：Spark/Flink 上雲是用的什麼技術？A14：Spark/Flink 支援多種 K8S 部署模式，包括 Standalone、Native、Operator 等部署模式，可以重點關注 Native 和 Operator 模式，能夠方便的支援動態的資源伸縮等能力。A15：排程智慧化是一個重要方向。舉兩個例子，一是基於任務執行的歷史資訊，實現任務排程策略、任務計算資源的最佳化，以保證整個平臺的任務排程穩定性和高效能。二是基於統一後設資料服務，實現排程系統的智慧化告警，甚至是任務的自動化問題修復，以此提升資料平臺的智慧化和自動化運維能力。Q16：StarRocks 和 Doris 是同一個產品嗎？A16：它們都屬於 MPP 資料庫，二者從功能和定位上有很大相似之處，但並不是同一個產品。Doris 是在 Apache 基金會維護，基於 Apache License 開源的 MPP 資料庫。StarRocks 是基於 Elastic License 開源的 MPP 資料庫，與國內幾個雲廠商都有合作。目前數新網路和 StarRocks 公司已經簽署戰略合作協議，雙方在產品整合、效能壓測及最佳化等方向均有合作。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70027827/viewspace-2940186/，如需轉載，請註明出處，否則將追究法律責任。