網易數帆資料生產力技術體系

任何一個方法論的落地，都必須有其配套的成熟工具軟體作為支撐，正如埃德加·弗蘭克·科德提出關係模型理論，Oracle 是其方法論下最為成熟的關係資料庫軟體，資料生產力的方法論也不例外。

經過網易 數 帆 多年的實踐和持續的打磨，在資料生產力DataOps、DataFusion和DataProduct三大方法論的指引下，構建了面向資料生產力的產品技術體系，這套成熟的技術體系不僅服務於網易內部的各個業務，例如網易雲音樂、嚴選、有道和新聞等。同時在2017年，網易也開始將其通過商業化品牌“網易數帆”進行對外輸出，在金融、零售、能源、製造、物流、教育、醫藥、農業等多個行業進行了應用，並沉澱了最佳案例。

1

網易 數 帆 資料生產力四層技術架構

網易 數 帆 資料生產力的技術體系包括四層架構：基礎設施層、資料研發層、資料中臺層和資料產品層。資料研發層的核心方法論就是DataOps，資料中臺層的核心方法論對應的就是DataFusion，資料產品層則對應的是DataProduct。

1.1 資料基礎設施

網易 數 帆 大資料基礎設施的核心是以Hadoop為主體構建的物理資料湖，以及基於湖之上的分散式計算引擎。在傳統Hadoop部署架構中，HDFS 作為分散式檔案系統，提供了資料湖的統一儲存底座，Yarn 提供了統一計算資源排程及管理的能力，Hive MetaStore提供了統一的元資料管理，LDAP、Kerberos、Ranger分別管理了使用者、認證和許可權，Spark，Flink以及Hive，提供了可以彈性擴充套件的分散式計算框架，這套體系滿足了海量資料計算以及儲存的需求。

在雲原生的時代，計算和儲存分離，以支援S3協議的物件儲存替換HDFS更滿足廉價儲存的需求，通過kubernetes實現大資料計算資源的統一管理，能夠實現線上業務和離線業務的資源統一排程，甚至可以做到線上和離線的混部，對於提高資源利用率，降低成本有很大的幫助。網易 數 帆 認為存算分離，混合排程，是雲原生時代大資料的標準形態，所以已經率先在網易內部開始了實踐。

例如，網易雲音樂的海外業務，部署在AWS上，我們使用S3替換了HDFS，作為物理湖的統一儲存，但是又面臨著物件儲存的讀寫效能實際無法滿足分散式計算的效能要求，我們必須引入alluxio分散式快取加速資料的讀寫效能，目前網易雲音樂在海外AWS上部署了超過700Core叢集。在網易新聞業務上，已經實現了線上和離線業務的混合排程，利用線上業務凌晨計算資源相對空閒的時間點，將離線業務排程到線上業務的伺服器上進行計算，有效提高了資源的利用率，每年為新聞節省了超過百萬的伺服器成本。網易 數 帆 已經為即將到來的雲原生時代做足了充分的技術儲備。

在基礎設施層，另外一個顯著特色，就是我們不僅只有Hadoop體系管理的大資料，還把RDBMS、MPP等系統管理的相對體量較小的資料也納入了基礎設施管理的範疇。我們認為，資料到底是用Hadoop去加工計算，還是用Oracle、MySQL等RDBMS，或者介於其中的MPP，只取決於資料的規模，與是否是企業的資料資產無關。也就是說不論資料是否物理入湖，都可能是企業資料資產的一部分，所以需要統一管理。

為此，網易 數 帆 提出了邏輯資料湖的概念，希望面向使用者的資料研發體系和資料中臺體系，不僅僅是圍繞Hadoop，還要實現其他計算儲存引擎的統一管理，構建一個基於元資料的邏輯資料湖，進行統一的資料開發和資料治理，如果資料量不大，可以直接基於RDBMS或者MPP完成資料分析，只有當資料規模或者資料型別無法滿足計算要求時，才進行物理入湖。

1.2 資料研發

在資料基礎設施之上，是資料研發層。資料研發的核心是構建資料生產的流水線，根據流水線的不同階段，我們拆分成4個工具產品。

（1）資料整合： 資料整合主要完成資料從各種異構資料來源的物理入湖的過程，將資料統一抽取到以HDFS構建的物理湖中。按照抽取的方式，又可以進一步細分為批量抽取和實時抽取。批量抽取的資料採集任務按照週期性排程的方式，將資料以全量或者增量的方式，抽取到HDFS中。實時抽取是基於CDC技術，實時攝取資料來源的日誌，解析資料庫變更，實時抽取到HDFS或者Kudu中。

（2）資料開發： 資料開發按照開發的作業型別，可以又進一步細分為離線開發和實時開發。離線開發主要完成周期性排程的批量作業的開發，實時開發主要是完成實時流處理作業的開發。資料開發中心，首先必須擁有一個對開發者友好的IDE，具有立即執行、語法檢查、日誌檢視、程式碼格式化等能力，對於離線開發，還能夠支援型別豐富的週期性排程，例如按時間排程是比較常見的排程型別，同時對於證券行業或者其他泛金融行業，排程日曆的能力也是不可缺少的能力。與此同時越來越多的企業，不再設定排程時間，而是直接按照任務依賴進行排程。UDF在資料開發過程中經常用到，需要有UDF的統一開發和管理。此外，引數配置管理，資源管理，需要通過引數組和資源組的方式，實現不同任務之間的共享。

（3）資料測試： 開發完的程式碼必須經過資料測試才能釋出上線，資料測試中心承擔了資料測試的功能，其中包括資料比對、資料形態探查等能力。資料比對，應用的主要場景就是對模型進行增改欄位之後，需要進行比對，確保未修改的部分，資料是一致的。同時還用於模型重構和遷移的場景，需要校驗重構前和重構後資料是否一致。資料形態探查，主要用於三個場景，其一是對抽取到ODS層的原始資料進行探查，瞭解資料的分佈，形成資料標準，為後面的建模和配置質量稽核規則提供準備。其二是讀取一個已經存在的模型資料，進行下游的任務開發，需要了解模型中資料分佈，為後續開發做準備。其三，是開發完成以後，需要對資料進行探查，檢視資料的分佈是否滿足預期。

（4）任務運維中心： 資料釋出上線後，資料開發需要通過任務運維中心，完成對生產任務的監控及故障處理。任務運維中心，首先提供的是任務的監控報警能力，對於海量任務的監控，還必須用到“基線預警”。基線代表的是一組任務的最遲產出時間，一方面，我們對於數倉，可以按照分層的方式，設定多條基線，例如在嚴選，我們設定了2點半作為DWD（明細層）的基線，4點半作為DWS（輕度彙總層）的基線，6點半作為ADS（應用層）和DM（集市層）的基線，任務運維中心可以根據任務之間的依賴關係，對基線的產出時間進行預測，提前發現因為上游任務延遲，導致基線任務產出延遲的問題。任務運維中心，同時還需要提供任務重跑，凍結池等能力，可以快速完成故障的處理和恢復。

1.3 資料中臺

在資料研發之上，就是資料中臺層。 資料中臺又可以細分為資料治理和資料服務兩個部分。 網易 數 帆 資料治理的所有工具構建在一個統一的元資料中心的基礎之上。 元資料中心可以完成各種異構資料來源的元資料採集和管理的功能，元資料的範圍包括資料字典、資料血緣以及資料特徵等。 基於統一的元資料中心之上，我們有7個面向不同方向的資料治理的工具產品。

（1）指標系統， 是實現DataFusion 統一指標管理的工具產品，它能夠實現指標的規範化定義和釋出審批流程，消除指標口徑的二義性。對於資料開發而言，指標系統規範了資料開發的需求，對於資料產品來說，指標系統提供了統一的指標管理能力，對於業務人員來說，指標系統提供了統一的指標字典，可以檢視企業所有指標及其口徑定義。

（2）模型設計中心， 實現DataFusion 規範、高複用模型設計的工具產品，基於維度建模的基礎方法論，實現資料建模，提高模型設計的規範化和複用性。模型設計中心，提供了模型設計統計指標，從跨層引用率，模型複用度等多個維度，統計展現當前數倉模型設計的質量，是否達到面向資料中臺的模型設計要求。

（3）資料地圖， 提供了企業統一的資料資產門戶，不論是業務人員，還是開發人員，都可以基於資料地圖，發現數據，找到自己需要的指標、標籤、模型等。資料地圖不僅涵蓋了Hive Meta註冊的Hadoop體系內的元資料，還包括了Oracle，MySQL，Greenplume，HBase，Vertica等非Hadoop體系的元資料。同時，資料地圖還提供了元資料管理的能力，資料來源owner可以配置元資料的採集範圍、採集頻率以及監控採集的任務。

（4）資料資產中心， 實現了DataFusion 基於ROI的資料資產管理的工具產品。資料資產中心承擔了資料治理的入口的功能，它立足於資料健康分，從質量、安全、成本、價值、架構等多維度評估數倉建設水平，基於問題驅動資料治理落地。特別需要指出的是，資料資產中心基於應用粒度的ROI分析，以資料應用的訪問頻率和訪問使用者數作為價值體現，以資料應用上游鏈路的所有資料模型加工和計算儲存的資源消耗作為成本，分析資料應用的ROI，推動剝洋蔥式的從資料應用開始，逐層下線低價值的資料，沉澱真正的資料資產。

（5）資料質量中心， 主要負責全鏈路的資料質量稽核監控。資料質量中心，立足於資料一致性、完整性、準確性、及時性、有效性、唯一性六大原則，提供了豐富的資料稽核規則模版，對全鏈路資料生產進行卡點稽查，如果不符合設定的校驗規則，則認為資料質量出現風險，可以選擇中斷任務進行處理，也可以作為報警事件進行後續跟蹤。

（6）資料安全中心， 主要負責安全管控的相關工具產品，安全涉及許可權的管理，許可權授權，資料脫敏，資料加密，資料安全等級，敏感資料識別，許可權治理，安全審計以及異常行為識別等能力。

（7）資料標準中心， 主要負責資料標準的制訂、稽核和釋出管理。資料標準，與模型設計中心能夠進行配合使用，模型設計中心可以直接選取資料標準中的資料元作為建模的欄位，同時標準還和資料質量中心能夠進行聯動，每個資料標準的資料元都有其對應的稽核規則，如果模型中引用了該資料標準，則可以直接將該標準對應的稽核規則新增到資料模型上。

1.4 資料產品

資料產品，可以分為兩個大類，一類是一些通用資料產品，例如滿足不同人群取數需求的自助取數，以及滿足人群畫像分析的標籤工廠，這類資料產品不區分業務場景，對每個企業幾乎都可以直接用。 另外一類是場景化的資料產品，網易 數 帆 資料生產力技術體系能夠提供的是以無程式碼的方式開發這些資料產品的工具鏈。

（1）資料門戶： 提供了業務人員看資料和用資料的一站式站點。資料門戶提供了統一導航的功能，使用者可以設定多級導航，將不同報表看板組織成資料門戶。資料門戶又可以分為移動端和PC端。資料門戶同時也可以整合到一些業務系統中，作為子模組存在。

（2）視覺化報表： 主要基於資料模型的基礎上，生成不同型別的視覺化圖表，包括指標卡、透視表、桑基圖等，視覺化報表是資料產品的核心組成部分，這些生成的圖表最終被嵌入到資料門戶中，展現到業務人員面前。

（3）智慧決策： 智慧決策包括智慧預警、異動分析和決策引擎三個功能。智慧預警可以基於圖表，也可以基於模型實現異常資料的監控。對於發現的異常資料，可以通過異動分析，實現類似杜邦分析的能力，找到指標異動的根因。根據問題的原因，可以在決策引擎中，產生對應的事件，作為決策建議。決策引擎實現了資料到決策的轉換。

（4）連線中心： 智慧決策產生的建議，最終要通過業務系統完成決策的執行，所以連線中心，可以通過webhook的方式，將決策推送給業務系統，在業務系統中實現決策執行。

（5）演算法平臺： 在網易 數 帆 資料生產力的技術體系內，我們將演算法平臺放到了資料產品層，主要原因是演算法平臺在該體系內發揮的主要作用是通過演算法學習能力，發現異常原因，提供更精準的決策建議。演算法平臺又可以細分為傳統機器學習演算法和深度學習演算法。例如，在網易嚴選的供應鏈決策協同系統河洛中，我們使用了隨機森林等演算法，進行銷量預測，提高補貨的精準性。

（6）資料文化分享中心： 網易 數 帆 為了鼓勵一線業務人員在自己的日常工作中更多使用資料，指導業務決策，構建企業人人用資料、時時用資料的企業資料文化，每年會舉辦資料分析大賽，讓各個崗位的基層員工來分享他在工作中是怎麼做分析的，這些故事性很強的案例最終會沉澱到資料文化分享中心中，作為案例，提供給更多的人學習。

2

網易 數 帆 資料生產力技術架構原則

網易 數 帆 在構建資料生產力技術體系之初，就設計了一系列的技術架構原則，這些原則指導了後續網易 數 帆 資料生產力軟體的系統架構設計。

2.1 模組化產品設計

一個複雜龐大的軟體，對於使用者來說，不僅操作入口極深，學習和使用成本都非常高。網際網路產品的一個核心設計思維就是以使用者為中心，一切產品的設計，都為了讓使用者用的更爽，操作更簡單，使用更流暢。所以我們摒棄了傳統軟體堆砌功能的設計模式，採用了模組化產品矩陣的方式，通過設計很多靈活的子產品，每個產品聚焦一個功能場景，簡化使用者的操作入口，提高產品的易用性。例如在網易 數 帆 資料生產力技術體系中，資料安全中心、指標系統、模型設計中心、資料標準等每一個模組都是一個獨立的產品，我們在一個產品中就可以完成一個相對聚焦的功能閉環。

通過模組化的方式構建產品矩陣，對於商業化也非常重要。每個企業所處的階段各不相同，面臨的問題也有很大的差異，業務模式的不同，導致企業對資料分析的敏捷度和規範性有不同的要求，所以並不是每個企業的都需要相同的產品，我們必須要針對企業面臨的問題，根據企業的需求，制訂不同的解決方案，這就需要我們的產品能夠以套餐的方式，進行靈活的組合售賣。

例如，對於業務模式創新速度非常快的網際網路企業，資料標準顯然並不是首要考慮的因素，敏捷開發是他們迫切需要解決的問題。但是如果換做是一個證券公司，它的業務模式非常的穩定，以資料標準為核心的資料治理投入產出比就非常高。所以產品矩陣的模式增加了產品售賣的靈活性。

模組化產品矩陣的設計模式，也推動了網易 數 帆 工具技術軟體研發效率的提升。原先單個產品，只能按照固定的迭代週期進行釋出上線，一個月更新一次，而現在有20多個子產品，每個產品都可以並行進行開發釋出上線，每週就有好幾次軟體釋出。

模組化產品矩陣的構建，離不開以下系統設計：

（1）可擴充套件的控制檯架構， 雖然產品功能被模組化為多個子產品，但是租戶、工作空間、人、角色、資料來源等必須是統一的，為了保證使用者的互動體驗，我們必須擁有一個可擴充套件的控制檯，子產品可以按需加入到控制檯中，在同一個控制檯使用者可以進行隨意切換到不同的子產品中。

（2）可擴充套件的IAM 架構， IAM（Identity and Access Management）最早出現在AWS中，提供統一的使用者識別和細粒度的訪問控制管理的能力，所有接入控制檯的子產品，需要通過IAM 實現安全訪問控制。管理者在同一個IAM中可以完成不同子產品的許可權控制。

（3）可擴充套件的監控和報警架構， 為接入控制檯的不同的子產品，提供統一的監控和報警能力，使用者只需要在同一個地方就可以完成所有產品的監控報警的設定，同時也避免每個子產品重複開發相關的能力。

2.2 外掛化系統設計

在資料生產力技術體系內會存在很多整合型（Hub）系統，例如元資料中心，它需要採集不同型別的資料來源的元資料，需要對接不同的資料來源系統；資料傳輸，需要完成不同的資料來源之間的資料交換。對於整合型系統，我們可以將不同資料來源的對接部分設計為不同的外掛，將公共邏輯抽象出來，對於不同的資料來源，我們只需要研發對應的外掛即可，大幅度提高了資料來源的對接效率。

例如，在資料傳輸工具中，我們可以把公共處理邏輯，比如欄位對映，資料分片，併發控制等抽象為Server，然後針對不同的資料來源，設計不同的Reader和Writer外掛。

同時，外掛化的設計也賦予研發模式更強的靈活性，不同的企業可以根據自己用到的資料來源設計不同的外掛，然後貢獻給工具產品。在網易，雖然工具技術平臺統一都是由網易杭州研究院提供的，但是很多資料來源的外掛都是各個業務自己開發，然後貢獻給杭研院的。我們非常提倡這種集體貢獻的開發模式。

外掛化設計另外一個優勢還體現在系統升級過程中，當我們新增一個數據源時，不需要進行系統發版升級，只需要部署一個新的外掛即可，這點對於商業化尤為關鍵，因為每個企業技術棧都有差異，涉及到的資料來源各不相同，如果每部署一個客戶，都需要重新發版升級，必然無法滿足商業化交付效率的要求。

2.3 分層的軟體設計

網易 數 帆 認為，在大資料軟體產品設計過程中，應該充分採用分層的軟體設計。 從網易 數 帆 資料生產力技術架構中，我們可以看到它被劃分成4層架構，基礎設施層、資料研發層、資料中臺層和資料產品層，每一層之間都可以解耦。 例如網易 數 帆 的資料研發和資料中臺相關係統不繫結Hadoop發行版，既可以對接網易 數 帆 自己的Hadoop版本，同時也可以對接像HDP、CDH\CDP、Fusion Insight等其他Hadoop發行版。

分層的軟體設計有助於構建開放的技術體系。分層賦予了軟體更強的靈活性，在每一層之上，可以構建開放的生態，生長出更多的優秀軟體。例如在大資料基礎設施層軟體中，HDFS和S3是儲存層，在其之上，可以有ORC、Parquet、JSON不同的資料格式，再往上，又可以有不同的計算引擎，例如Flink、Spark，程式設計介面可以支援Flink SQL、Spark SQL等。

分層的軟體設計增加了商業化靈活性。在網易 數 帆 對外商業化過程中，很多使用者都已經構建了大資料的基礎計算儲存平臺，他們需要的可能是網易 數 帆 敏捷資料研發的能力或者構建資料中臺的能力，這個時候，就需要資料研發和資料中臺相關係統能夠對接不同的基礎設施。

分層的軟體設計還有助於提高軟體的研發效率，降低運維升級故障。例如，通過將產品需求比較集中的資料研發和資料中臺軟體，與需求相對較少，對穩定性要求更高的基礎設施層軟體進行解耦，我們可以保證資料研發和資料中臺層軟體以更高的頻率進行迭代更新，而基礎設施也可以避免頻繁升級導致的各種運維故障。

2.4 雲原生系統設計

網易 數 帆 認為，未來的軟體設計，必須滿足雲原生的軟體設計原則。 雲原生的軟體，應該是分散式、無狀態、能夠基於kubernetes部署，對於流量型服務同時還要能夠根據流量的變化進行動態伸縮，這也是對資料生產力軟體的設計要求。 例如在資料服務的系統設計中，系統有管控服務、API服務和閘道器服務。 每一個釋出的API都可以被執行在kubernetes管理的容器中，且可以根據API的呼叫量實現多副本伸縮。

2.5 基於OpenAPI 構建開放的技術架構

一套標準的資料生產力軟體產品，有可能無法滿足企業的所有需求，必然會面臨一些定製化場景，例如企業需要構建自己的資料資產門戶，在門戶中甚至要融入一些業務流程，那標準工具產品必然無法滿足需求，此時就需要資料生產力軟體開放出來更多的OpenAPI，允許企業基於API的能力，構建出滿足企業定製化需求的產品。

OpenAPI構建的開放的技術架構，促進了網易 數 帆 資料生產力軟體的持續創新。我們鼓勵更多的企業基於網易 數 帆 資料生產力軟體提供的API能力進行持續創新，解決在實際資料建設過程中遇到的問題，網易 數 帆 可以將這些成熟，具備複用價值的工具再吸收回網易 數 帆 資料生產力的軟體體系內。

開放 OpenAPI 降低了產品需求的交付壓力。因為網易 數 帆 資料生產力軟體也在持續的創新過程中，面臨很多新的產品需求，如果開放了豐富的OpenAPI，使用者就可以自己去解決問題，不至於一直阻塞在產品的研發進度上。

最後OpenAPI 也增強了軟體的粘性。因為一旦使用者基於軟體提供的OpenAPI構建了更多的系統，那這些API 也增加了使用者替換軟體的成本，對於軟體來說，地位就會更加牢固。

2.6 避免對開源系統的過度侵入

網易 數 帆 一直堅持開源的技術路線，這也同樣體現在資料生產力的技術體系中。 我們基於開源的Hadoop體系之上，構建了資料研發平臺和資料中臺系統。 開源的優勢在於可以持續的享受社群的紅利，但是如果因為產品需求，我們侵入到開源系統中，對開源系統進行了深度定製，最終就會導致與開源社群版本脫離，無法享受升級新版本帶來的能力提升，也失去了開源技術路線的價值。

網易 數 帆 在過往的技術迭代中吃過類似的虧，例如，為了實現表授權，同時自動對HDFS 目錄授權的功能，直接修改了Ranger的程式碼，導致Ranger 後續無法升級。為了汲取類似的教訓，網易 數 帆 制訂了避免對開源系統過度侵入的系統設計原則。但是為了實現業務的需求，我們可以在開源系統外圍設計一個獨立的服務，將產品需求集中在該服務內，同時該服務通過開源系統提供的標準介面，與開源系統進行互動。這樣既可以實現產品的需求，同時也避免了對開源系統的過度侵入。

3

網易 數 帆 資料生產力技術優勢

網易 數 帆 資料生產力的技術架構具備以下優勢：

3.1 領先方法論驅動的產品技術創新

網易 數 帆 始終重視且堅持，以領先方法論驅動產品技術創新的模式。方法論是對產品技術體系化思考後沉澱的經驗和原則，方法論能夠幫助我們發現過往產品技術的不足，同時還能夠指導後續我們的發展方向。

例如，我們在做資料研發層軟體設計時，發現業界幾乎所有的資料研發類軟體提供的都是資料開發和任務排程的能力，缺少對資料測試的支援。但是如果我們是站在DataOps的角度，從構建資料生產流水線出發，以CI/CD的方式去思考，那就應該要有資料測試的能力。

通過跟實際業務的調研，發現數據開發確實在資料測試方面存在痛點，所以我們設計了資料測試中心這款工具，用於資料開發階段的資料測試，獲得了良好的應用，這就是典型的以方法論驅動的產品創新案例。

這種模式也使得網易 數 帆 對產品技術的思考更加全面，更加系統化，從網易 數 帆 資料生產力的產品技術架構中，也可以看到網易 數 帆 的全棧產品能力，雖然產品模組很多，但是每一個產品都是緊密圍繞DataOps、DataFusion和DataProduct這三個核心方法論設計的。

3.2 網易內部業務的持續實踐

網易 數 帆 資料生產力產品技術是經過網易內部多元化業務長年實踐積累下來的，經歷過網易嚴選複雜業務形態的考驗，也經歷過網易雲音樂海量資料規模的驗證，與其他純做資料中臺或者資料產品的軟體公司不同，我們不是以專案交付制的方式研發產品，而是真正從使用者的角度去思考，如何去構建一個對業務有價值的產品，所以內部業務是網易 數 帆 資料生產力軟體最大的試金石，內部業務面臨的問題也是網易 數 帆 資料生產力軟體持續創新的需求來源。

3.3 基於開源的技術架構

網易 數 帆 積極擁抱開源社群，並且也在持續回饋開源社群。網易 數 帆 資料生產力基礎設施軟體完全是基於開源的技術體系構建的，針對開源軟體的bug缺陷，進行了修復，同時針對功能的不足，進行了增強。我們也積極將我們針對開源社群軟體的修改，回饋給社群。

在Spark 3.0的全球個人貢獻排名中，網易排名高達全球第二。在2021年6月21日，由網易 數 帆 貢獻的Spark 資料湖探索服務Kyuubi被全球頂級開源組織Apache 基金會以全票通過的表現，正式進入Apach 基金會孵化器。

基於開源技術體系的優勢，在於企業可以招到更多的人去維護軟體，在使用過程中的問題，也可以在社群找到問題的解決方案，降低軟體使用的門檻。同時，開源技術體系，也可以讓企業不被特定的軟體廠商繫結，企業的自主可控權增加。

3.4 支援跨雲的軟體定位

網易 數 帆 資料生產力軟體對自己的商業化定位非常的清晰，我們不是一個雲廠商，我們是一個專注於基礎軟體的服務商，這就是說，我們跟雲廠商不是競爭的關係，而是可以合作共贏的關係。從軟體定位上，我們可以支援跨雲的軟體部署，讓使用者不被某個雲廠商繫結。我們和雲廠商的邊界，在於我們只使用雲廠商提供的基礎計算和儲存資源，例如我們提供的Spark 執行在雲廠商提供的Kubernetes叢集上，我們提供的Alluxio構建在雲廠商提供的物件儲存服務之上。

同時，我們還可以支援混合雲部署，在雲上和雲下，使用者都可以通過一套軟體統一的開發和管理。例如，在德邦物流，它有云上和雲下兩個叢集，網易 數 帆 資料生產力軟體在雲上構建在華為雲提供的OBS物件儲存服務之上，同時雲下還管理了數百臺物理叢集。

網易 數 帆 認為，一個成熟的大資料商業生態，它一定是分層的，這點在較為成熟的國外市場已經得到過驗證，AWS 提供了基礎的計算、儲存資源，解決了資源彈性伸縮的問題，Informatica提供了大資料的開發和資料治理套件，解決了資料研發和管理的問題，Tableau提供了視覺化分析的能力，解決了敏捷資料分析的問題。

但是在國內，雲廠商為了增強自己在競爭過程中的優勢，加強使用者的粘性，不僅提供了基礎資源，還提供了上層的工具產品，但是這些軟體，從商業化定位來看，它的目標是服務於使用者更好的使用資源，本質還是在資源上，所以它必然不會提供跨雲支援的能力。

作者簡介

孫仲謀，網易 數 帆 大資料專家，大資料平臺負責人，曾任網易雲資料庫產品負責人，十多年網際網路資料研發和管理經驗，網易資料中臺建設的親歷者和實踐者。

分享，點贊，在看，安排一下？