4月6日，TeaTalk· Online開源論道系列活動第2期——“論道雲原生，且看大資料江湖”線上直播成功舉辦。本次直播從“從Hadoop到雲原生”、“雲原生大資料的關鍵技術”、“雲原生大資料分析Lakehouse”這三個方面圍繞技術發展的趨勢，深度融合雲原生技術，碰撞出彩，同時也對發展未來進行展望。
以下為中國移動雲能力中心，大資料技術專家陶捷老師演講實錄。
大資料技術發展到今天已經有十多年的時間，如今大資料技術已經從新興前沿技術逐漸成熟成為普惠性技術。同時現今雲原生技術又在如火如荼的發展，那麼大資料技術，尤其是基于Hadoop開源生态的技術如何與雲原生技術結合并迸發出火花，是人們關注的熱點。
這次分享主要包括幾個方面：
- 講解基于開源的Hadoop技術發展以及和雲原生技術的淵源
- 講解大資料雲原生的關鍵技術，這裡主要包括大資料元件容器化、計算存儲分離、資料湖&湖倉一體方面
- 介紹移動雲雲原生大資料分析Lakehouse産品，這個是大資料與雲原生結合的典型案例
- 對雲原生大資料進行總結和展望
中國移動雲能力中心從2014年開始大資料平台相關工作，到今天已經有8年的積累了。從發展的曆程來看，整體分為了三個階段：
階段一：從14年到19年，主要為移動體系内各省建設大資料平台，覆寫了全國2/3的省份，累計建設叢集超過100個，節點數超過10000個，同時也服務于部分外部客戶。
階段二：從16年至今，主要為集團建設統一的大資料平台，目前節點已經超過21000個，并且正在從集中化大資料平台演進到跨域多叢集協同計算的架構。
階段三：從19年雲改開始到現在，将大資料能力上到移動雲，同時打造雲原生的大資料産品。
整體上目前移動雲的大資料平台是公有雲大資料産品和私有化大資料平台并舉的發展狀态。
關于Hadoop大資料平台技術
Hadoop自07年誕生到現在已經第十五個年頭，傳統Hadoop體系的大資料平台基于Hadoop開源生态的諸多元件，各種元件覆寫資料采集、存儲、計算、排程、管理等方面，并且元件不斷疊代，新技術不斷湧現。在實時計算、批量處理、消息隊列等領域，Flink、Spark、Pulsar等技術正在逐漸取代Storm、MapReduce、Kafka等技術。然而近年來實際元件疊代更新的速度實際是在不斷放緩的，更多随着Spark、Flink等技術自身不斷演進成熟而提升。
另一方面，傳統Hadoop平台主要通過實體化部署，并且采用存算一體的架構，元件通過管理平台部署，計算資源通過Yarn來管理和排程。主要存在以下幾個方面問題：
- 資源彈性伸縮不足
- 資源使用率低
- 資源隔離性差
- 自動化運維成本高
- 不同元件管理方式不統一
解決這些問題往往更多需要依靠整體架構上的演進而不僅僅是元件的更新。
關于大資料與雲計算
大資料與雲計算的融合早期就經常會産生讨論。實際的情況是這兩種技術的生态是不同的，但是解決的場景有所重疊，互相交織，是以試圖從技術上進行統一融合，典型的在于兩個方面：
1、計算資源排程
在雲計算場景通常采用虛拟化技術對資源進行排程，而在大資料場景會采用Hadoop的架構提供資源排程能力。我們曾經也嘗試過Slider+Yarn以及Myriad+Mesos的方式進行統一排程，但是前者隔離性上存在缺失，後者機制上是兩層排程，産生額外損耗，并且兩個方案社群成熟度都很低，很快都不在發展了。如今随着Kubernetes+Docker技術的出現和成熟，大資料元件能夠更自然的和計算資源排程相結合，也逐漸成為主流的排程方案。
2、存儲方向
在大資料和雲計算的場景，存儲都非常重要，并且都是需要基于分布式存儲。分布式存儲對資料可靠性的要求，需要資料通常3副本的備援，而直接将大資料的存儲映射到雲上的分布式存儲，往往會産生資料膨脹，一份原始資料産生3*3=9份真實資料，進而産生大量不必要的成本，而解決的方案通常是需要存算分離的方式。
大資料在公有雲上的典型形态就是EMR這類産品，在雲上通過雲主機提供半托管式的服務，使用者能夠得到和線下Hadoop平台一樣的使用者體驗。最早由AWS退出，如今包括移動雲在内的主流雲廠商也都提供了類似的産品。
EMR這樣的雲産品能夠一定程度上利用雲的資源為大資料平台提供彈性伸縮的能力，但是還遠達不到雲原生的狀态。
所謂雲原生的大資料要能夠天然與雲計算技術相結合，最高效的利用雲上的資源服務于大資料的業務場景，使用者能夠像使用水電煤一樣使用大資料的能力。其主要的特征包括：存儲與雲深度融合，計算Serverless化，極低的使用門檻。
大資料元件容器化
大資料元件容器化是一個發展的趨勢，如今越來越多的企業嘗試将大資料元件運作到K8S裡，進而也有大量業界的實踐工作。相對于虛拟化技術，容器化技術能夠支援更快更輕量級的部署，服務啟動時間從分鐘級降低到秒級，同時性能損耗也從10%降低到5%左右。
我們總結了一下大資料元件容器化帶來的優勢：
1、元件服務快速靈活部署：服務運作在容器鏡像之中，隔離了服務對平台環境的依賴，部署快速，服務秒級啟動能夠友善支援多執行個體、多版本的需求。
2、資源管理，彈性伸縮，提升使用率：K8S管理叢集資源，能夠支援服務間資源隔離（yarn能做到運作計算任務之間隔離，但是無法與例如hbase這樣服務進行隔離），同時各種業務（離線任務、線上服務、實時計算）之間混合部署。同時能夠支援各種排程政策，支援納管不同資源（不同規格伺服器、GPU等特殊資源）。
3、更高效的自動化運維能力：Kubernetes 自身架構能夠對服務可用性提供一定保證（例如服務pod挂掉、節點當機等場景），同時可以通過自定義服務存活性探針來定義自動化運維的邏輯。與Prometheus或ELK等成熟生态內建。
但是在大規模實體化部署場景裡，容器化大資料平台也存在一定局限性。在平台層面的彈性伸縮提升有限。實體化部署環境裡資源的供給取決于實體裝置的到位，而部署Hadoop還是K8s并不能對快速叢集擴容帶來改變。同時叢集規模越大，帶來的性能損耗也會随之放大，另外因為引入K8S一層服務，在超大規模下穩定性方面也會帶來挑戰。
我們總結了一下各種不同服務運作到K8S中的不同方式，其中計算服務類元件可以比較自然的運作到K8S中。計算架構類服務需要要求架構本身對K8S的支援，而目前flink、spark等架構能夠原生支援，而MapReduce、Tez架構并沒有成熟的方案。對于一個同時需要支援不同計算架構的平台通常可以采用兩種方案來支援：
- 資源統一管理，但是任務會經過K8S/Yarn兩層排程，産生額外開銷。
- 采用元件原生支援排程架構，但是需要預先劃分好yarn和k8s兩個資源池，資源池之間難以負載均衡。
另外我們在集約化部署的場景，叢集私有化部署，但是資料量沒那麼大，也不具備公有雲上基礎設施，通過大資料容器化方式部署，能夠在高效利用實體資源的方面起到非常明顯的作用。
計算存儲分離
計算存儲分離更多是一種設計理念，而非具體的技術或者産品。我們總結了常見多種存算分離架構。存算分離核真正關心的問題在于：
- 真正降低存儲帶來的成本（軟硬體機關成本、适應不同性能需求下的成本、資源使用率/彈性伸縮帶來的成本）
- 與現有大資料平台體系融合（是否相容目前接口協定、能否與現有存儲良好并存、能否滿足目前對性能和擴充性的需求）
進而實際上存算分離需要解決的是兩個問題：
- 更高成本效益的存儲
- 資料統一通路方案
大資料場景提供一種更高成本效益的存儲，主流有兩種方向：1、構造一種相容HDFS的分布式存儲，并通常設計會針對HDFS存在性能瓶頸（例如NN單點、小檔案）進行優化，輔以通用的優化技術：緩存、SSD、EC、壓縮等，往往可能還會采用軟硬體一體的設計。2、接入現有低成本存儲（通常是對象存儲），這種方案實際是解決對象存儲在大資料場景性能差的問題，這種方案在雲上場景具有更大價值（成本更具有優勢）。
資料統一通路的價值在于，當引入新的存儲（即使相容HDFS）的時候能夠盡可能對上層計算透明，減少使用者感覺和改造成本。同時統一資料通路往往可以結合小檔案合并、冷熱資料等優化。往往可以通過代理通路（RBF），緩存系統（Alluxio）等方案實作。
一個具體的案例，就是移動雲Hbase産品，我們從本地實體化部署的方式到雲上存算分離架構方式，再到存儲使用雲上對象存儲。這個也是産品雲原生程度逐漸提升的過程。
資料湖&湖倉一體
資料湖或者湖倉一體也是近兩年來非常熱門的技術話題。我們總結資料平台整體的架構演進可以是從傳統數倉（MPP）到傳統資料湖（Hadoop）再到湖倉一體（Lakehouse）的過程。
資料湖核心觀點在于采用統一存儲存放原始資料，支援各種格式（結構化、半結構化、非結構化）資料，并提供統一的資料分析處理能力。
我們目前典型的Hadoop架構的大資料平台，本身就是一種資料湖，具備一定的資料湖特質，然而和我們談論的湖倉還是有一些差別：
- 目前底層存儲單一，主要以HDFS為主，未來演進為支援多種媒體，多種類型資料的統一存儲系統。
- 目前根據業務分多個叢集，之間大量資料傳輸，未來演進到統一存儲系統，降低叢集間傳輸消耗。
- 目前計算架構以MR/Spark為主，未來演進在資料湖上直接建構更多計算架構和應用場景。
在公有雲上，資料湖和雲資料倉庫各自有其熱門的産品：
資料湖産品：亞馬遜LakeFormation、阿裡雲DLA、華為雲DLI、騰訊雲DLC
雲數倉産品：亞馬遜RedShift、阿裡雲MaxCompute、SnowFlake、ClickHouse
我們認為資料湖和資料倉庫總體是朝相同方向演進，但是側重點有所不同：資料湖具有更好的靈活性，支援各種類型資料，适用于初創期企業需要快速靈活進行資料探索場景；雲數倉具有更高成本效益和更完備資料規範治理能力，适用于逐漸成熟快速成長型企業需要更高效處理大資料業務的場景。
另一方面技術的趨勢是湖倉一體：一方面資料湖和資料倉庫的生态更好的互動融合，湖能通路倉，倉能融入湖；另一方面資料湖和資料倉庫産品能力互相延伸擴充，像倉一樣使用湖，倉能擴充成湖。
雲原生大資料分析Lakehouse
雲原生大資料分析Lakehouse是移動雲自主研發的大資料平台類産品，融合了湖倉一體、存算分離、容器化等雲原生關鍵技術，為客戶提供一站式的大資料服務能力。
Lakehouse的主要特征包括：
- 計算存儲分離：我們計算基于K8S排程，存儲支援HDFS和移動雲對象存儲EOS兩種，并通過Alluxio進行緩存加速，計算存儲分别計費，計算不足擴計算，存儲不足擴存儲。
- Serverless：差別于傳統資源類服務會按照使用的記憶體、cpu進行規格計費，Lakehouse對客戶可以做到按實際使用的資源量進行計費，使用者可以不必精細預估好需求資源，訂購以後隻有真正運作作業才會記錄使用并收取費用，不用不收費。同時即使需要擴縮容規格，也是秒級完成。
- All In SQL：傳統大資料平台需要使用者對大資料元件具備一定的開發能力，而Lakehouse采用通用的SQL作為互動的輸入，使用者隻要會寫SQL就能進行開發，像使用資料庫一樣開發大資料。
- 智能中繼資料：支援不同資料源中繼資料統一管理，同時具備中繼資料發現能力，對于存儲在對象存儲上無Schema的資料，能夠自動爬取格式并轉化為結構化資料。自動化工作減少大量ETL任務的繁瑣配置。
總結與展望
1、傳統Hadoop生态大資料技術已趨于成熟進入普惠期，雲原生的技術能夠在彈性伸縮、資源使用率提升、運維管理方面進行有效提升。
2、基于K8S容器化提升彈性、結合雲上對象存儲降低成本是目前大資料雲原生的主要趨勢。
3、雲原生架構的LakeHouse能更好的利用雲的資源提供大資料服務能力，并且會逐漸降低大資料技術的使用門檻。
4、私有化大資料和公有雲大資料場景差異使得“雲原生”并非解決所有問題的銀彈，但整體發展趨勢仍然趨于統一。
掃碼可得活動回顧及專家PPT
這一期的 TeaTalk· Online 我們跟随陶老師，乘着俠義時代的風雲，從微毫處見識了盛大的大資料江湖，非常感謝陶老師帶我們領略雲原生的魅力所在。作為開發者社群系列活動的重要一環，未來TeaTalk·Online線上直播欄目将更加專注細分技術領域，進一步擴充知識廣度、技術深度，加速擁抱開發者。
繼續關注我們吧，我們下一期不見不散！
誠邀加入移動雲開發者社群
共築移動雲生态！
掃碼進入