長期以來，國內數據技術都由海外廠商主導。然而隨著國際競爭環境日益激烈，爭端所引發的技術卡脖子事件頻發， 2022年3月Cloudera宣布停止對CDH技術支持以及Apache Log4j引發嚴重安全漏洞的問題，企業對核心技術自主可控的意愿急迫，國產化替換需求不斷增強。本文將探討國產化趨勢下，大數據平臺該何去何從。主要包括以下幾大方面：

• 為什么要做軟件國產化？
• 軟件國產化?臨的挑戰
• 數帆?主?數據平臺介紹

01 為什么要做軟件國產化？

1. 軟件國產化的必要性-外部形勢

從2020年至今，隨著中美貿易戰的不斷升級，美國商務部限制美企對華為、中興、大疆等企業的各種零部件出口。此外，俄烏戰爭導致Oracle、Apple、Google等被限制向俄羅斯出口。面對特殊的大環境，全球化帶來的科技創新共同體背后，國家IT產業實現自主可控的重要性不言而喻。

2. 軟件國產化的必要性-安全因素

2021年底爆出的log4J漏洞，因使用率較高且沒有修復方案，尤其對于一些信息安全要求較高的金融或政府類單位來說，影響范圍極大。對于一個產品來說，如果不能掌握源代碼，那只能通過等待發版或者一些治標不治本的封禁手段來修復漏洞，然而大多時候產品的發版速度跟不上實際應用節奏，因此急需一個可以掌控的技術環境，能滿足我們對安全的要求。

3. 軟件國產化的必要性-安全政策導向

我國在軟件國產化方面正在向自主可控方向發展。芯片領域如飛騰、鯤鵬、龍芯、海光等；服務器PC產品有華為、浪潮、新華三等。數據庫也正在往國產化方向發展，如OceanBase、PostgreSQL、TiDB、達夢、人大金倉等。

為確保國家信息安全，政府部門出臺了一系列的相關政策以支持IT系統的國產化。政策導向也在鼓勵國內的各行業向自主可控方向發展。

02 軟件國產化的挑戰

1. 什么是國產化？

《數據庫導論》的作者Andy Pavlo稱國內大部分自主可控的數據庫系統都是從MySQL或者Postgres的分支上發展起來的，這些數據庫算不算國產化？

2. 國產化的核心

國產化的核心并不是從0到1的建設，而是能夠掌握源代碼，深入理解其原理和實現，對不合理的內容進行改造，并在此基礎上進行更多的優化和功能增強。這就是軟件國產化自主可控的表現。

軟件國產化自主可控另一個方面是整個軟件生態的建設，通過做一些工具讓生態閉環更加完整，在兼容老的生態的基礎上構建自身生態。

3. 國產化的現狀

操作系統領域：作為軟硬件的紐帶，國內如中標麒麟、統信UOS、OpenEuler等都有了不錯的發展。

數據庫領域：大批數據庫廠商不斷涌現，如OceanBase、TiDB、GaussDB及達夢數據庫等。

軟件領域：如金山WPS、用友、金蝶等。

經過一段時間的發展后，我國在軟件方面產品的成熟度以及認知度日漸提升。從圖表中可以看到，2021年OpenEuler在金融行業的裝機量占比23.3%，金融機構的操作系統正在慢慢的向國產化方向轉變。數據庫方面雖然也有部分機構做了一些替換，但是案例較少，原因在于金融核心交易系統的穩定性是第一要義，新研發數據庫產品對于上層系統的兼容性難以完全覆蓋，一旦出現問題，可能會影響整個交易鏈路，這對于金融機構是不能接受的。

4. 大數據平臺的現狀

中國信息通訊研究院在2019做了一個關于國內大數據平臺發行版本的統計，其中超過70%是在CDH 或者HDP的基礎上包裝成產品對外提供的，24%是在Apache開源產品上做一些加工，6%的版本是自研產品。從2021年1月31日開始，所有Cloudera軟件都需要有效的訂閱，并且只能通過付費墻進行訪問。這說明大數據平臺免費的時代將要終結。

5. 大數據平臺的選擇

大數據平臺正在慢慢向付費方向切換，如果繼續保持版本不變 ，由于官方不再提供服務，則可能會存在嚴重漏洞及性能上的不足，對于安全要求較高的金融或政府行業來說，在生產上存在較大的風險。

如果做升級改造，也會存在升級風險，對于一些服務不可中斷的行業，需要一個更平滑更穩定的遷移方式，同時上層產品的兼容性也是一個重要的考量標準。

6. 大數據平臺升級的幾種方式

• 原地升級，不需要額外的機器資源，但需要停機升級，錯誤回滾是一個很大的問題。
• 遷移升級，重建一套系統，然后將數據拷貝過去。這種遷移可以做到不停服務，對線上系統無感知，但是需要額外的機器資源，成本及時間支出較高。
• 滾動升級，滾動升級需要對業務做一些拆分，然后基于業務部分遷移。這種方式相對遷移升級來說，對資源的需求相對更少，是一個對成本控制和業務影響相對穩妥的方案。

03 數帆大數據平臺介紹

1. 網易數帆的發展歷程

網易數帆從2009年就開始研發大規模分布式系統，2015年大數據平臺、數據可視化平臺上線，經過十多年的發展，已經形成從數據存儲、數據治理、數據研發、數據展示的完整的解決方案和產品架構。

2. 網易有數基礎團隊

網易有數基礎團隊主要負責集團內部大數據平臺內核底層技術的研發，如Hadoop 、OLAP 、Impala 、Spark 等，還貢獻了Apache的 Kyuubi 項目，是支撐網易數帆產品的底層基座。

3. 網易有數平臺支持

在持續保持良好的核心技術支撐的同時 ，有數平臺同時還在積極做國內信創安全適配，通過一系列的技術改造，有數整體平臺能夠兼容包括華為鯤鵬芯片、麒麟操作系統等符合信創要求的基礎設施。有數平臺后續的發展會致力于搭建更兼容的平臺架構。

4. 數帆有數平臺

數帆有數平臺融合了網易10多年的平臺建設經驗，依托社區優勢，致力于打造自主可控的數據底座，并實現易用性、穩定性、安全性等的升級。

5. 網易有數平臺增強

有數平臺還會在開源大數據框架的基礎上做一些增強，如Hadoop的回收站功能、Impala的虛擬數倉隔離和負載均衡、Spark的權限管控和 Ranger 兼容、Hive的負載問題等。

Impala 的增強體現在把所有的節點通過 group分組，對不同業務進行隔離，從而避免業務之間的資源沖突。同時也通過自研管理服務器進行SQL審計，通過收集查詢習慣進行預計算，從而減少部分查詢對整體的影響。

此外在HDFS上也做了增強回收站的功能，通過修改 HDFS源碼，確保刪除數據首先保存到回收站，防止數據異常刪除。 

6. 網易有數服務策略

有數平臺還提供三位一體的服務支持。技術人員幫助客戶快速熟悉產品，使得用戶遇到問題可以有效解決，用戶遇到故障時，運維人員能夠快速主動提供運維增值服務。此外還提供研發兜底機制，一旦出現內核層面的問題，研發團隊會快速響應進行修復。

7. 平臺遷移支持

平臺支持Apache Hadoop、CDP、HDP等的遷移。在Hive元數據遷移過程中需要考慮元數據兼容性問題，業務數據的遷移主要通過鏡像后定時增量拷貝的形式同步數據，同時提供遷移工具進行權限的一鍵式遷移，我們還構建了調度平臺，并提供Oozie調度任務的遷移工具。

04 Ｑ＆Ａ環節

Q1：CDH 底層技術該怎么做？在金融行業遷移需要重點關注哪些問題？

A1：CDH遷移涉及到平臺的構建、兼容性的遷移等等，由于遷移過程的復雜性，我們會針對每個用戶設計遷移方案，根據用戶的使用習慣進行遷移。

Q2：金融技術的自主可控需要關注哪些問題？

A2：第一個關注點是目標供應商對大數據平臺的自主可控能力，是否有對底層源碼的一個掌控能力。第二個關注點是供應商能否完全兼容平臺的平滑遷移。

Q3：金融行業做數據中臺有哪些價值？

A3：數據中臺主要做數據研發、數據質量、數據服務的事情，各個業務單元所提供的數據口徑是不一致的，數據中臺可以將數據口徑進行統一，這樣可以在權限管控、質量管控、資源管控等方面做更好的控制。

Q4：很多公司基于HDP＋Ambari 管控平臺做大數據平臺的封裝？ 

A4：CDH+ cloud manager是商業化的產品，HDP＋Ambari是開源的，這也是大家選擇的原因。CDH更改了擴展后，如果使用Ambari屬于盜版行為，會被追究法律責任。數帆也是因為Ambari 的問題，基于hadoop官方社區，建立一套自己的管控平臺。

Q5：關于大數據組件的升級換代有什么建議？ 

A5：從大的方向來說，升級是有必要的，版本升級換代有助于性能和安全層面的提升，如果老版本的安全風險和性能是可接受的，可以暫不升級，如果需要更高的性能或安全需求，則可以考慮升級。

Q6：網易大數據平臺的數據安全性如何保障？ 

A6：網易大數據平臺依托于現有開源的社區的組件能力，基于Kerberos加 Ranger 的權限控制體系，同時做一些增強，對于組和用戶對資源的訪問權限進行細粒度的控制。此外在產品層面也做了安全中心，來保證底層數據訪問的安全性。 

Q7：有 K8S組件的規劃嗎？

A7：這是我們未來的發展方向，去年在K8S 上做了Spark調度，以解決在線業務的錯峰調度，今年會慢慢地會考慮整個底層基礎平臺往 K8S 方向上做，如OLAP、Flink 等的業務。

Q8：網易用什么工具做平臺維護？

A8：網易做了一套EasyOps來管控整個大數據的底座，提供自動化運維方案。

Q9：網易的大數據平臺有和HDP或 CDH做對比嗎？

A9：網易的基礎組件是跟CDH等的大的社區一致的，同時根據實際應用情況對一些基礎組件進行深度增強及性能上的改善。

今天的分享就到這里，謝謝大家。