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