與傳統的數據架構要求整合、面向主題、固定分層等特點不同，數據湖為企業全員獨立參與數據運營和應用創新提供了極大的靈活性，并可優先確保數據的低時延、高質量和高可用，給企業數據架構優化提供了很好的參考思路。

01? 企業數據架構的現狀及挑戰

以運營商企業為例，從數據的系統歸屬上看，可分為MSS（管理支撐系統）的面向人、財、物管理類數據，BSS（業務支撐系統）的面向客戶和產品的營銷及客戶服務數據，OSS（運營支撐系統）的面向產品和網絡的功能及運營服務數據，三者之間既相對松耦合，又有著緊密的協作關系，BSS和OSS的銜接點主要在產品及開通、排障服務，MSS和BSS、OSS的銜接點主要在參與人和資源。

從數據分類來看，運營商的數據可分為作為企業核心的功能類實體數據、表示企業所有運營過程的活動類數據、體現內外部客戶感知并圍繞兩大主線所產生的感知類指標數據以及與管理相關的人、財、物及流程數據。電信運營商數據范圍示例如圖1所示。

由于國內運營商以兩級經營模式為主體，系統的集約化建設程度相對較低，以分域（M/B/O）、分省建設為主，即便是同類系統的數據，因為分31個省市建設，各省市的業務管理模式、數據模型標準、主數據等千差萬別，跨省、跨域、跨系統的模型標準統一非常困難，即便通過數據副本的模式進行整合匯聚，也存在轉換不專業和數據失真等問題。同時，域與域之間雖是松耦合的，但因為使用者和建設者的不同，相互之間會冗余存儲對方數據，而建模和主數據又不同，跨域之間數據的關聯整合非常復雜，跨域、跨省的端到端應用困難。運營商的數據還有一個顯著的特點，就是與網絡密切相關，網絡運行數據和網絡拓撲數據需要與網絡保持實時一致，且數據量比較大，網絡智能化后的實時數據應用需求也越來越多。通信網絡是一張大網，即便引入云計算、虛擬化技術，依然有大量網絡節點遍布31個省市，海量網絡數據的實時采集、處理及應用也是運營商數據架構需要考慮的一個重要因素。國內運營商目前都不同程度地建立了自己的企業級大數據平臺，有的分總部/省兩級部署，支撐兩級數據分析，統一全網的架構、來源、算法、規則，總部數據輕度匯總，按需采集匯聚高價值詳單數據；有的采用1+N模式，建設總部和省互補協作平臺，總部提供跨域數據和特定的大數據能力，作為N的省向總部提供本地化數據能力與自定義算法。電信運營商數據平臺架構示例如圖2所示。

不管采用哪種模式，都不同程度地存在其下屬各專業公司、各部門根據各自需要，或在生產系統內構建含大數據技術的混搭數據架構，或建設域內自用的大數據平臺，因此有很多數據未進入企業級大數據平臺，或數據平臺的應用未達到預期。其原因可歸結為如下幾點：1）平臺數據質量不高平臺數據來自于M/B/O的生產系統，而運營商分兩級31省市建設的生產系統，不但數據模型、主數據標準不統一，業務管理模式的差異也很大。數據經過多次模型轉換，存在嚴重失真的問題，且很難對數據質量問題追蹤溯源。2）平臺數據不夠實時數據經過多級采集匯聚，處理環節多，采集周期長。網絡相關海量數據跨省傳輸，占用大量帶寬，數據時延較大。數據平臺目前只能以支撐離線的決策分析為主，難以滿足SDN/NFV/云網絡及物聯網等實時/準實時數據應用需求。3）平臺的靈活性不足數據平臺的建設以存儲計算一體化架構為主，平臺與應用緊耦合，多基于公共數據平臺和整合后的數據支撐應用創新。對于新的數據整合、數據計算分析技術引入、平臺擴容支撐等需求響應不靈活，導致數據平臺應用不足。4）平臺和應用互鎖，形成惡性循環企業級數據平臺難以滿足生產系統數據應用需求，生產系統就沒有動力將自身數據和應用遷入數據平臺，進而數據平臺的數據質量和可用性越來越差。同時，還導致生產系統和各個大數據平臺的數據重復采集、重復存儲，且相互之間數據訪問技術和管理壁壘嚴重，建設和維護成本大幅提高。

02 數據湖方案的價值及可行性分析

數據湖推崇存儲原生數據，對不同結構的數據統一存儲，使不同數據有一致的存儲方式，在使用時方便連接，真正解決數據集成問題。數據湖的本質是一種數據管理的思路，利用低成本技術來捕捉、提煉和探索大規模、長期的原始數據存儲的方法與技術。數據湖可存儲任何種類的數據，高質量、高效率地存儲數據，更快速、更廉價地處理數據，將建模應用問題丟給最終開發者。數據湖的方案應用可以帶來如下幾個顯著的好處：

1）規模大、成本低全企業海量數據統一存儲，采用開源技術，基于低成本硬件資源，建立和維護成本相比數據倉庫低一個數量級。

2）數據“原汁原味”數據湖以原始形式保存數據，并在整個數據生命周期捕獲對數據和上下文語義的更改，尤其便于進行合規性和內部審計。如果數據經歷了轉換、聚合和更新，將很難在需求出現時將數據拼湊在一起，而且幾乎沒有希望確定清晰出處。

3）數據方便易用結構化、非結構化、半結構化的數據都是原樣加載和存儲，以后再進行轉換，開發和保存成本低，產生和使用之間時延小。客戶、供應商和數據運營者不需要數據擁有者提供太多幫助即可整合數據，消除了數據共享的內部政治或技術障礙。

4）應用按需建模數據湖提供數據給靈活的、面向任務的結構化應用，詳細的業務需求和艱苦的數據建模都不是數據湖的先決條件。數據湖給予最終用戶最大的靈活度來處理數據，對于同一份原始數據，不同的用戶可能有不同的理解。目前，大部分運營商采用傳統的以數據為中心的處理架構（存儲計算一體化，如主流MPP、Hive和分布式計算廠商產品），好處是計算效率高、技術成熟，缺點也很明顯，如靈活性不足，使得數據應用適用于少數人，這也制約了原生數據提供者向平臺提供的積極性，進而導致數據的質量、數據的全面性都得不到很好的保障。引入數據湖概念的一個顯著特點就是存儲和計算松耦合，可采用以計算為中心的處理模式（存儲與計算分離，如Spark技術及AWS、阿里云等云服務提供商產品），使得運營商可以更加專注于數據的存儲和管理，存儲和計算不用相互制約，從而優先確保數據的高質量、低時延、高可用，并為數據應用的快速構建提供了極大的靈活性。數據湖按照成熟度可劃分為4個階段：

第一個階段，應用程序獨立建設，部分應用將數據提供給數據倉庫，基于數據倉庫構建分析應用；

第二個階段，數據湖和數據倉庫并存，應用程序向數據湖提供副本數據，基于數據湖開發分析型應用，數據倉庫和應用也可從數據湖提取數據；

第三個階段，新系統以數據湖為中心構建，應用通過數據湖交互彼此數據，數據湖成為數據架構的核心，數據倉庫基于數據湖提供特定的應用需求，數據治理變得重要；

第四個階段，所有新的應用均基于數據湖構建，數據湖成為彈性的分布式平臺，數據的治理和安全需持續加強，支撐企業的數據運營和分析能力。

電信運營商目前普遍處于第二個階段向第三個階段演進的過程中，在構建數據技術方案方面具備較好的基礎條件。

03 數據湖建設思路

調整現有分析型數據平臺建設思路，將其數據與應用解耦，引入數據湖概念，強調原生數據入湖，并與全網生產系統模型和主數據標準化協同推進，兼顧層次化的傳統數據架構和扁平化的數據湖架構的優點，SchemaonRead和SchemaonWrite并存，統一支撐企業實時、準實時和離線數據應用快速創新，是電信運營商實現以數據為中心IT架構轉型的有效途徑。數據湖作為運營商數據存儲和訪問的唯一出口，成為所有IT系統共享的基礎設施，統一存儲全企業IT和網絡數據，通過開放架構支撐智慧運營，并可作為IT系統集約化演進的紐帶。

數據統一存儲

統一存儲MSS、BSS、OSS及網元平臺的實時、歷史、在線、離線數據，全網的原生數據只存儲一份在邏輯統一的分布式數據湖內，原生數據與生產系統數據模型標準和主數據一致，新IT系統/網元平臺的生產數據直接使用數據湖存儲。

數據統一管理

所有入湖數據的目錄、元數據、數據應用及數據質量、數據標準、數據安全必須統一管理。數據模型標準和主數據動態維護，數據質量集中治理，原生系統的數據問題溯源處理，生產系統建設者全程參與數據管理，責任權利保持一致。

數據統一標準

生產系統管理部門負責31省市系統模型和主數據的標準化；數據湖統一管理生產系統的數據模型及主數據；暫未進行標準化的生產系統數據模型，由對應系統的管理部門負責數據模型的轉換和運營，協調推進生產系統數據標準進程。

數據近源采集

提供數據統一采集、實時訂閱分發框架，支撐實時/準實時數據、離線數據的采集。各網元/平臺數據采集能力以組件方式納入數據湖，分專業采集、預處理加工，海量實時數可靠近網絡近源部署前置采集模塊。非網絡類數據（如BSS、MSS、OSS流程等），初期以副本采集方式匯聚入湖，遠期直接以服務交互方式入湖。

數據與應用分離

數據應用環境與數據存儲環境分離，按應用計算的網絡帶寬需要就近部署。提供統一的服務化訪問、小批量數據訂閱、數據分析計算云平臺環境。基于云平臺環境，應用開發者可自行整合數據、構建應用，數據存儲、數據整合、平臺組件、數據應用間相互解耦，建設的進程不會相互制約。同時，建立全生命周期數據目錄，統一標識各項數據，完善數據治理機制，管理數據湖數據的生產加工流程，對各項數據生成和使用過程進行跟蹤記錄，支撐數據的應用和溯源，是數據湖方案順利實施的關鍵要素。

并且還需要加強數據標準的全生命周期流程以及數據標準的元數據及數據質量問題收集、自動稽核、問題溯源、影響分析及跟蹤處理等數據管理能力。可以采用爬蟲的方式生成數據目錄，在不影響數據所有者或用戶的情況下自動生成，

決定數據湖能否順利實施的因素有很多，包括數據湖涵蓋哪些數據及如何分區存儲、數據湖如何分布式部署、紛繁復雜的現有IT系統數據如何入湖、數據和應用能否分離、數據湖與現有各類數據平臺的演進關系等。當然，更重要的是數據管理思維的轉變，這是一切的基礎。

04 數據湖建設的4個要點

針對運營商數據湖的實施，提出如下4個方面的關鍵要點及建議。

要點1：數據湖分區數據湖邏輯上可劃分為生產數據區、原生數據區、整合數據區、匯總數據區4個大的存儲區域。數據湖的應用可基于PaaS平臺按需使用各個區的數據，4個區的數據目錄、元數據、數據加工處理流程及數據應用需要統一管理、維護和治理。

生產數據區

M/B/O系統生產數據的存儲區域，涵蓋實時交易型數據、實時/準實時網絡采集數據等，可以是關系型和非關系型混搭的存儲結構，各生產系統需要進行架構優化，數據與應用分層解耦，將數據存入生產數據區。

原生數據區

將各系統的生產數據直接寫入數據湖原生數據區，以非關系型數據格式存儲生產系統數據，方便各數據應用使用，生產數據和原生數據模型標準、主數據一致。原生數據區涵蓋企業的任何內容，無限接近企業各系統、部門的敏感信息。供數據湖科學家和技術人員訪問使用。

整合數據區

存儲按照數據分析需求建模加工后的公用數據。模型從生產/原生數據模型派生而來，被業務和IT部門熟知，可供企業各種應用程序使用。原生數據區中依然有很多數據或屬性沒有被真正理解，并未完全包含在這個數據區的模型中。

匯總數據區

存儲按需求分析匯總的結果數據，一般可存儲在關系型數據存儲內，便于數據服務的快速加載呈現。數據湖生產數據區和原生數據區作為最重要的數據分區，是數據湖內數據整合和匯總的源頭數據，數據質量必須得到保障。另外，數據湖雖不鼓勵應用特定模型，但也可劃分特定數據區給私有應用使用，提供快速構建數據應用的途徑，這些應用獲取數據湖數據且具有數據處理能力，數據湖構建初期，可將已有業務應用數據導入數據湖特定數據區中。電信運營商數據湖數據分區示例如圖4所示。

要點2：數據湖部署

數據湖部署方案的設計需要考慮如下要素：

現有BSS/OSS系統分省/總部兩級建設和維護，源系統模型屬地管理；網絡/平臺數據量大，且貼近網絡建設歸屬地，屬地應用占比大；

M/B/O及網絡/平臺之間數據松耦合，主要通過企業主數據進行銜接。數據湖原生數據區和生產數據區與數據源系統就近分布式部署（總部1+省市31模式）。

生產數據云節點由生產系統按需分區、分片部署，即支撐生產應用交易處理，也支撐實時網絡數據采集和應用。

原生數據云節點與生產數據云節點就近、集中部署，靠近數據歸屬地，數據實時從生產數據云節點寫入原生數據云節點。原生數據云節點可再細分為核心數據區（如客戶、銷售品、產品、服務、資源、組織、人員等）、BSS數據區、OSS數據區、MSS數據區、網絡/平臺數據區。

數據湖整合、匯總數據云節點采用1+N模式部署，統一管理、控制和調度節點環境，兼顧全網統一和個性化應用需求，數據科學家逐步探索和建模數據，開放數據應用。1+N模式中的“1”支撐全網應用，“N”支撐省內應用，并作為創新基地，有條件、數據量大、應用豐富的省可選擇建設N分區。分區節點內可按照應用范圍（全局需求、特定需求）、地域歸屬（集團、省）、數據層次（整合、匯總）、數據分級（普通、密級）等進一步分區存儲。電信運營商數據湖部署方案示例如圖5所示。

要點3：IT系統數據入湖

數據湖的建設不可能一蹴而就，需要根據運營商IT系統建設情況分別采用不同策略進行數據入湖演進。電信運營商IT系統入湖方案示例如圖6所示。

方式一：數據同步方式。適合交易型系統已存在、數據模型和主數據已全網統一的場景，生產數據直接同步寫入原生數據區，如BSS、MSS、傳統OSS。

方式二：數據同步/轉換方式。適合交易型系統已存在、數據模型和主數據并未全網統一的場景，如BSS、MSS、傳統OSS。將非標準生產數據寫入原生數據區，支撐省內整合匯總應用及集團標準的寬表需求；將非標準生產數據按全網統一標準轉換，提供給全網數據整合匯總及數據治理使用。

方式三：數據正本方式。適合交易型系統新建模式，如新一代OSS資源、編排、告警等。正本數據寫入生產數據區，統一模型和主數據標準，基于交易型PaaS平臺完成應用；生產數據區數據直接寫入原生數據區。

方式四：采集入庫方式。適合網絡監控分析型系統新建模式，如新一代OSS的網絡采集數據、資源拓撲、深度分組檢測（DPI）數據等。數據采集文件、流數據等暫存在生產數據區；寫入原生數據區后，生產數據區不再保留；統一原生數據模型和主數據標準，基于實時和非實時PaaS平臺完成分析型應用。

要點4：數據湖數據與應用分離

數據湖通過數據服務平臺、數據共享平臺及統一數據應用環境按需支持交易類、實時監控類、分析類應用。數據增、刪、改、查服務統一部署在數據服務平臺上，供交易類應用訪問調用；通過訂閱需要監控的數據，由數據共享平臺將數據實時分發給監控類應用使用。數據的加工整合、分析應用、海量搜索、人工智能等應用均可部署在應用環境內，按需動態加載并臨時存儲數據，結果寫回到數據湖存儲環境，以服務方式啟動任務和查詢結果數據。

其中，應用環境公共組件隨著技術的更新不斷疊加，逐漸平臺化共享，暫時無法滿足應用需求的可由應用在統一環境內部署組件及加載數據。數據湖應用加載數據的方式可分為實時增量加載、準實時增量/全量加載、離線批量加載等，數據可按需全量或增量短期加載。對于應用和數據無法解耦的組件（如Hive、MPP等），按需復制數據，以空間換數據管理和應用的靈活性；對于應用和數據可以有效解耦的組件（如Spark等），可以按需動態、實時加載數據。

應用組件逐漸由與數據緊耦合的組件向與數據松耦合的組件演進。數據湖采用讀寫分離、應用計算與數據存儲分離、關系數據與非關系數據存儲并存的模式，并提供數據存儲節點分布式部署、服務化訪問及統一數據加載、共享及分發能力，降低數據湖數據存儲訪問負載，提升數據的可用性及數據訪問效率。由數據湖提供數據的統一遷移，包括主從庫的復制、關系庫到非關系庫的數據轉換等。提供統一的關系和非關系庫數據訪問及分布式數據路由以及數據共享開放和訂閱分發管理框架，實現高效的數據訪問；提供統一的數據應用環境管理，包括配額管理、數據訪問權限管理、數據回寫節點分配管理等，獨立部署分析計算類應用，分析計算節點與數據湖數據存儲節點分離；提供統一的分布式服務運行框架，基于服務調用實現交易類增、刪、改、查應用的數據訪問，避免直接操作數據。電信運營商數據湖應用方案示例如圖7所示。

要點5：數據湖數據統一管理

數據湖的實施，需要實現模型和主數據標準的動態維護以及數據的集中治理，避免數據湖成為數據墓地。而數據來源眾多，數據管理需要依賴于多方的密切合作以及數據標準管理、目錄/元數據管理、應用/服務管理、質量等管理及海量數據探索分析等高效的管理工具。電信運營商數據湖管理體系示例如圖8所示。

電信運營商數據涉及系統眾多、關系復雜，沒有任何一個獨立的團隊能夠通曉所有的數據模型和關聯關系，因此需要企業數據管理團隊與專業數據管理團隊分工合作，共同完成數據模型標準/主數據的管理及數據集中治理。建立橫縱向一體化的數據管理體系，明確企業數據管理和原生數據部門職責分工，固化數據管理流程制度。企業數據管理團隊負責統籌標準和主數據管理及數據治理工作，負責數據建模挖掘和跨專業數據治理協作，負責為業務部門和應用開發者提供數據建模和平臺技術支持；專業數據管理團隊負責建立專業數據的模型標準和管理主數據，識別數據問題及跟蹤處理；數據湖應用開發者負責提出數據需求，按需整合和構建應用，反饋數據問題，評估數據變更影響。

另外，作為企業最核心的數據資產，其全生命周期的安全管理非常重要。需要針對數據采集、數據存儲（生產數據、原生數據、整合數據、匯總數據）、數據應用、數據服務、數據分發共享等環節構建端到端的安全管控體系。

對涉及用戶行為特征及關鍵信息的敏感數據進行統一處理，脫敏后提供給應用使用；不管是敏感數據還是非敏感數據，所有數據的直接訪問均在數據湖的管理范圍內進行，具體措施包括數據應用環境、服務訪問環境、共享分發環境、數據存儲環境統一管控，需要經過統一的對象和屬性等的鑒權才能訪問數據，數據不出數據湖（即數據訪問不出臺），只能使用服務化方式或經過鑒權認證的數據共享分發方式進行數據訪問。同時需要對大數據安全事件具備閉環管控能力，增強數據安全事件快速分析能力，提升安全事件發生后的應對處置效率。