前言

剛剛過去的21世紀的第二個十年，是消費互聯網蓬勃發展的十年，也是云計算、大數據、人工智能等新一代信息技術，即“數字化技術”快速崛起的十年。

在這一時期，以信息服務為主的消費互聯網行業，如電商、互聯網金融、社交娛樂等，充分享受了數字化技術帶來的“數字化紅利”，極大推動了其終端用戶的消費行為與體驗的數字化轉型。

但相比于消費互聯網行業在數字經濟浪潮下的蓬勃發展，以傳統線下服務、實體商品制造為主的傳統行業逐漸顯得落寞。在國際局勢不明朗、國內市場紅利逐步耗盡、存量競爭日益明顯、人才成本日益高企、產業升級換代壓力增大的當下，傳統行業的經營與效益上正面臨三十年未有之變局，在新興的數字化業態沖擊下，還同時面臨著客群與市場相對萎縮的困局。

因此，投資數字化技術，充分接納技術帶來的變革，推動企業數字化轉型，從而實現經營策略由粗放式向精細化的轉變，對抗經濟周期帶來的下行壓力，將成為傳統企業的必然抉擇。

根據華為&牛津經濟研究院報告顯示，自2000年以來，金融、制造、ICT服務、交通、公用事業、房地產、農業等傳統行業的數字化技術投資的年復合增長率，明顯超越以消費互聯網為代表的數字化技術制造業。

圖1：各行業的數字投資增長

該報告還表明，過去三十年中，數字化技術投資每增加1美元，便可撬動GDP增加20美元，而1美元的非技術投資僅能推動GDP增加3美元，數字化技術投資的平均回報是非數字化技術投資的6.7倍。這也說明，驅動傳統行業的數字化技術投資的動力來源，本質上是企業對效益提升的追求。

在數字化技術中，數據庫、數據倉庫、大數據平臺和云數據平臺等基礎軟件，構成了企業數字化轉型的重要基礎設施，即“數據基礎設施”。隨著各行業的數字化場景的發展，新的業務挑戰對“數據基礎設施”的技術路線演進產生了極大的推動作用。

但是，迄今為止的數據基礎設施發展，仍然難以徹底解決以集團型、多分支-企業為代表的大中型企業數字化轉型的痛點。

比如，銀行、保險等金融機構普遍采用夜間“跑批”的方式對當日交易數據進行ETL處理，從而將數據匯總到數據倉庫、數據集市中，供用戶進行報表分析與即席查詢，但數據基礎設施底層的復雜查詢性能，成為“跑批”結果時效性的主要瓶頸，這也影響了用戶進行決策的頻次和時效性。

再如，電力、電信等關乎國計民生、用戶數量巨大、IT基礎設施復雜的行業，普遍面臨的挑戰是數據規模及其龐大，而數字化應用的計算與存儲需求也及其巨大。為了提升工作負載能力，多集群的數據基礎設施已經成為行業普遍現狀。由此，盡管交易型數據庫的“數據孤島”得到了一定程度的治理，但在數據基礎設施內部，卻因為多集群間的數據共享難題，產生了新的“數據孤島”。

由此可見，數據基礎設施的技術架構、功能與性能特點的不斷演進和發展，仍具備無限的想象空間。以“云數據平臺”為代表的新一代數據基礎設施，正逐漸成為集團型、多分支企業推進整體數字化轉型的最佳選擇。

01

數據基礎設施支撐企業數字化轉型

在宏觀經濟走向中低速增長的今天，“重資產、薄利潤、現金流短缺”等經營現狀，愈發困擾著傳統企業，產業升級任重而道遠。

相比于從誕生第一天起就帶有濃重“數字化基因”互聯網企業，許多傳統企業對數字化技術的應用還處在摸索階段。但是，中國經濟已經開始邁入“數字經濟”的新階段，快速涌現和崛起的數字原生企業，以及數字化技術帶來的競爭優勢，意味著傳統企業如果不快速接納數字化技術帶來的變革，那么將必然無法維持原有競爭優勢。

因此，通過積極接納數字化技術，重塑業務流程，拓展業務邊界，將成為傳統企業實現可持續發展的必然選擇。

1.1 企業數字化的戰略規劃

國務院發展研究中心課題組發布的《傳統產業數字化轉型的模式和路徑》對產業數字化進行了定義：利用新一代信息技術，構建數據的采集、傳輸、存儲、處理和反饋的閉環，打通不同層級與不同行業間的數據壁壘，提高行業整體的運行效率，構建全新的數字經濟體系。

在這一基礎之上，愛分析認為，企業的數字化轉型，則是指企業依托于數字化技術（即“新一代信息技術”），構建與數字化技術相適應的戰略規劃、人才能力、組織架構、運營方法，推動業務及運營模式的不斷變革與敏捷創新，從而幫助客戶創造更大價值，實現業績增長與運營效率提升。

相比于傳統企業，數字化企業具備四大基本特征：以客戶為中心、以數據價值為基礎、以AI能力為引領、以敏捷能力與驅動型IT組織為支撐。

由此可見，企業數字化轉型是一項系統性、全員性工程，絕非能夠一蹴而就。傳統企業的數字化轉型項目，普遍存在“成本高、周期長、難度大”等問題，這使得傳統企業的數字化轉型步伐顯得遲緩且保守。

為了降低數字化轉型項目的失敗風險，降低試錯成本，提升項目整體效益，進行自頂向下的戰略規劃顯得至關重要。根據先進企業的數字化實踐經驗來看，成功的企業數字化戰略，至少應當包括數字化戰略、數字化場景、數字化技術與數字化組織等四個層次。

圖2：企業數字化的戰略規劃

數字化戰略：企業數字化戰略具備系統性特征，是“一把手工程”，責任首先在于企業高層，成功的關鍵也在于企業高層觀念與理念的轉變。因此企業首先需要進行戰略目標的設定，從而充分調動全企業、各部門的資源，對業務場景、組織架構、數據基礎設施進行整體規劃，并對實施流程進行整體把控。

數字化場景：數字化戰略的核心價值在于賦能業務場景，缺乏落地場景的數字化戰略只是“空中樓閣”。因此，企業應當在具體業務場景中衡量數字化的真實價值，這就需要企業全面梳理業務場景，并對各場景的業務需求、現有條件、預估投入、波及范圍和預期業務收益進行全面評估，保證數字化轉型的目標與收益相對明確、實施過程與影響相對可控。

數字化技術：數字化技術主要指為企業數字化戰略提供技術支撐的云、數據、AI等技術能力。其中，數據能力主要指企業基于數據分析來支撐業務決策的能力，其在基礎軟件層面的具體載體是“數據基礎設施”。

數字化組織：數字化戰略的內在要求是對數字化組織架構的打造。為了深度應用各類數字化技術，企業需要推動數字化人才的引進和培養，比如數據分析師、數據科學家、算法工程師等專業性技術人才，以及具備數字化意識的業務人才和管理人才。在人才基礎上，企業需要進一步搭建最大化人才價值的數字化團隊。在文化層面，企業需要通過一系列的規范標準、制度安排、激勵措施，推動“以數據發現問題所在、以數據分析問題成因、以數據預測發展趨勢、以數據推動業務變革”成為全企業、各部門的集體共識，將數據文化內化為企業文化的一部分。

1.2 數據基礎設施的定義

愛分析認為，數據基礎設施是一套建立在過往的交易數據基礎之上，并結合一定的技術手段與業務流程，為業務場景提供數據服務，實現數據價值變現的生態體系。數據基礎設施的建設方式、建設質量直接決定了數字化團隊的協作方式與工作效果，也進一步影響了整個企業數字化戰略的最終效果。

一般來講，數據基礎設施包括數據體系、技術體系、運營體系、服務體系等四個部分。

圖3：數據基礎設施架構

數據體系：包含了企業內可利用數據的組織方式，包括源系統的交易數據，各類非結構化、半結構化、二進制數據，以及結構化數據的數據分層關系、數據模型、數據表結構、視圖關系、字段名稱、數據容量、數據權限分配等。

技術體系：包含了一系列數據相關的技術產品，如交易型數據庫、數據接入工具（數據同步/消息中間件）、分析型數據庫、NoSQL數據庫、數據開發工具、AI算法開發工具等，以及不同產品之間的協同關系與業務流程。

運營體系：通過數據標準、數據質量、數據資產目錄、數據服務培訓與推廣、平臺操作流程與規范等，搭建數據的資產化管理與運營體系，從而為服務體系提供穩定的運營支撐，并保證數據基礎設施與組織架構之間的協同效率。

數據運營體系建設在金融行業的重要性： 在中國經濟轉型、金融科技高速發展、金融環境及監管政策變化的大背景下，金融行業尤其銀行業面臨著持續挑戰和變革壓力，亟需推進全面的數字化轉型。 在需求層面，數據已經成為金融機構的戰略資產，數據的準確性、完整性、一致性等數據質量指標對金融機構至關重要。 在政策層面，銀監會、人民銀行、外管局等監管機構對商業銀行等金融機構的數據良好標準、數據一致性、完整性等數據質量指標的要求也日趨嚴格。比如，銀保監會于2018年5月21日正式發布《銀行業金融機構數據治理指引的通知》（銀保監發【2018】22號），對銀行數據治理體系建設提出了規范要求，并將數據治理與監管評級掛鉤，將銀行業金融機構開展數據治理工作的重要性提高到了戰略高度。 但是，當前許多金融機構仍然普遍存在“缺少數據治理體系、數據質量較差、數據應用難以有效開展”等問題，與滿足監管的基本要求還有較大距離，也難以滿足日益增長的數據應用需求。 因此，構建完善的數據運營體系，加強數據治理、提升數據質量、發揮數據資產價值、支持業務創新和精細化管理的必要性和緊迫性日益凸顯。

服務體系：是數據與業務結合的關鍵環節，主要以可視化大屏、固定報表、自助式報表、數據API服務、數據應用等數據服務形態，以便捷的方式為業務部門提供數據服務，實現數據變現。

1.3 數據基礎設施的演進歷程

作為企業數字化轉型的核心支撐，數據基礎設施的技術架構特點，決定了其支撐數字化團隊與數字化場景的能力上限。

根據業務場景、組織架構、技術架構、功能特點、性能特點的差異，數據基礎設施的演進歷程，已經經歷了數據庫、數據倉庫、大數據平臺三個完整階段。目前，數據基礎設施正在邁向前三個階段之后的第四個階段，即“云數據平臺”階段。而在這一演進過程中， 還出現了像“數據中臺”這樣的階段性概念。

圖4：數據基礎設施的演進歷程

1.3.1 數據庫階段

數據庫是數據基礎設施的萌芽階段，而最早的商用數據庫產品，如Oracle、DB2，均誕生于1970年代末到1980年代初。

早期的數據庫應用于以OLTP（聯機事務處理）場景為主，即直接承載來自業務系統、交易系統的數據存儲與計算，因此這類數據庫又被稱之為“事務型數據庫”或“交易型數據庫”。在許多情況下，人們也將它等同于狹義的數據庫。

業務場景

該階段的企業缺乏成熟、可落地、面向一線業務人員的數字化場景，核心痛點是為企業管理層解決宏觀層面的經營決策問題。

因此，該階段的數據查詢維度、數字化展現形式都比較單一，主要是基于固定的若干張數據表，生成面向管理層的固定報表、可視化大屏等。

組織架構

該階段的企業普遍缺乏專業的數字化人才，也缺乏成熟的數字化組織架構與文化，主要由IT人員承擔面向管理層的數字化場景的落地。

數據基礎設施的技術架構

該階段的數據基礎設施，尚未完全從業務系統的交易數據庫中分離出來。對數據分析需求，企業一般基于交易型數據庫單獨建設一套用于分析查詢的歷史數據庫，匯集來自不同交易數據庫的原始數據。在少部分數據分析場景下，企業還會直接用交易數據庫進行支持。

交易型數據庫的軟硬件架構都采取共享存儲架構，即計算節點能夠訪問到任意的存儲節點，同時需要基于專有物理硬件，由此保證對性能的良好優化。

數據基礎設施的功能及性能特點

功能特點：對各類SQL標準、ACID特性（指數據庫事務的四個屬性，包括原子性、一致性、隔離性、持久性）的支持都相當完善，因此帶來了很強的穩定性。但是，共享存儲架構帶來的缺點是可擴展性差，一般只能擴展到十幾節點就會遇到瓶頸。

性能特點：主導第一代數倉的Oracle、IBM等IT巨頭公司具備深厚的基礎研究和性能優化能力，因此在OLTP場景中表現優良，但是由于共享存儲架構在可擴展性方面的不足，使得其在大數據分析場景中的性能表現相對一般。

*典型產品：Oracle、IBM DB2

1.3.2 數據倉庫階段

1990年代后，尤其是隨著E.F.Codd于1993年正式提出聯機分析處理（OLAP）的概念，數據基礎設施開始進入“數據倉庫”時代。

業務場景

該階段的企業開始具備一定的數字化意識，數據分析的需求開始從管理層下沉到業務部門，核心痛點是為一線業務人員的解決業務決策問題。

由于OLAP的數據查詢維度更加復雜，查詢頻次更高，企業開始將承載OLAP工作負載的數據庫與業務系統的交易數據庫進行分離，從而避免OLAP對核心交易造成干擾。因此，專用于OLAP的分析型數據庫誕生，并逐步從交易型數據庫中分離出來，也因此獲得了“數據倉庫”這一更加形象的別稱。

該階段的數字化展現形式，仍然以傳統報表和可視化大屏為主，因此為了支撐業務部門的數據分析需求，需要具備專業的數據分析人員響應需求，并提供技術支持。

但是，為了滿足業務人員需要，企業需要存儲更多的歷史數據，常常需要對數據倉庫進行擴容，而Oracle、DB2等交易型數據庫擴展性較差，難以滿足擴容需求。因此，基于MPP無共享架構的數據庫逐步進入人們視野。

組織架構

在組織架構層面，該階段的企業大多仍然由IT部門來支撐數字化，業務部門、IT部門均缺少數字化人才。因此，其IT組織架構盡管能夠支撐一定頻次的業務需求，但對于緊迫需求仍然難以充分響應。

數據基礎設施的技術架構

數據倉庫的軟硬件架構經歷了較為漫長的發展歷程。

1980年代，Teradata首次推出了采取MPP無共享存儲架構的數據庫，其主要特點是基于大規模并行處理（MPP）架構，即在每個計算節點都有自己獨有的存儲節點，數據并均勻打散到所有節點存儲，并將多個并行任務分散到不同的節點上執行。此外，Teradata繼續采用了類似早期Oracle、DB2等數據庫的專有物理硬件。到1990年代之后，MPP數據庫被越來越多的應用到數據倉庫的構建之中。

到2006年前后，Greenplum、Vertica等支持x86通用服務器的MPP數據庫出現，降低了數據倉庫的建設和擴容成本。

數據基礎設施的功能及性能特點

功能特點：無共享架構使得節點擴展變得更加容易，而不再受到共享存儲架構的制約，節點數量上限一般能達到數百個；基于x86通用服務器的無共享架構，降低了擴展成本，提升了靈活性；對SQL標準、ACID特性的支持性較好。

性能特點：主導MPP數倉的Teradata、EMC（收購Greenplum）、惠普（收購Vertica）等公司，在整體實力上同樣較為雄厚，具備較強的基礎研究和性能優化能力；無共享和MPP架構消除了在大數據場景下的性能瓶頸，提升了負載均衡能力，在大數據分析場景中有著超越交易型數據庫的性能表現。

典型產品：Teradata、EMC Greenplum、HPE Vertica

1.3.3 大數據平臺階段

2005年后，由于互聯網、移動互聯網的逐步普及，業務系統的終端用戶量的爆發式增長，企業內沉淀的數據量同樣呈現爆發式增長，數據基礎設施開始進入“大數據平臺”階段。

業務場景

在互聯網、移動互聯網技術的推動下，金融、電商、社交娛樂等領域的企業開始越來越多地觸及終端用戶的線上數據。這些數據具有多樣、多維度、大規模的特點。

首先，數據類型十分多樣，包括結構化數據（關系型數據庫中的表）、半結構化數據（如CSV、XML、日志、JSON）、非結構化數據（電子郵件、文檔）、二進制數據（圖形、音頻、視頻）等。其次，數據維度更多，包含了用戶的各類行為數據。此外，存儲的數據量也從過去的GB、TB級別，進一步提升高PB、EB級別。

該階段的數字化展現形式更加多樣，除了傳統報表、可視化大屏，具備自助式分析能力的敏捷BI工具逐步普及。這使得在部分場景下，業務人員能夠自行進行數據探索與分析，而不再需要IT人員、數據分析師隨時進行技術支持。

但是，MPP數據倉庫的擴展規模僅能到數百節點，難以進一步擴容，而且不支持非結構化、半結構化數據，逐漸難以滿足企業需求。在這樣的背景下，以Hadoop為代表的大數據技術逐步成為數據基礎設施的核心技術之一。

組織架構

該階段的企業，普遍開始擁有具備業務理解能力和數據分析能力的數字化人才，但人才往往分散在各業務線，或歸并在IT部門，缺乏統一的數字化組織架構，以及對數字化的整體推動能力。

數據基礎設施的技術架構

以Hadoop為代表的大數據技術為企業統一采集、存儲與處理各類等多種類型數據提供了技術可能性，“數據湖”架構的理念也由此誕生，而許多企業又將“數據湖”稱之為“大數據平臺”。

基于Hadoop生態的大數據平臺，需要兼容前一階段建設的MPP數據倉庫，同時提供基于SQL-on-Hadoop（如Hive、SparkSQL）的數據倉庫，以及包括NoSQL數據庫（如HBase）、流處理、批處理、分布式存儲（如HDFS）在內的大數據套件。

與MPP數據倉庫的共享存儲架構不同，SQL-on-Hadoop數據倉庫基于HDFS等分布式、軟件定義的存儲，在軟件層面實現了存儲節點與計算節點的相互獨立，因此可以實現計算、存儲獨立擴展。

數據基礎設施的功能及性能特點（僅針對SQL-on-Hadoop數據倉庫）

功能特點：由于計算存儲分離架構的特點，SQL-on-Hadoop數倉能夠實現計算、存儲分別擴展，因此在擴展性、在線擴容等方面有明顯優勢，支持上千節點的擴展規模；但是，由于HDFS的只讀限制，SQL-on-Hadoop數倉在對傳統事務型數據庫所具備的SQL標準、ACID特性支持較差，這也使得應用從事務型數據庫、MPP數據庫向SQL-on-Hadoop數倉遷移的過程中，存在大量不兼容的問題，即應用易遷移性較差。

性能特點：SQL-on-Hadoop數倉由開源項目、互聯網公司、初創型公司所主導，生態相比于前兩代數倉更加開放，但是由于缺乏針對性能和功能的深度優化，在大多企業客戶中只被應用于邊緣場景，一直未達到能夠全面取代傳統數倉的要求。

典型產品：Hive、SparkSQL、Cloudera Impala、Facebook Presto

1.3.4云數據平臺階段

2015年后，企業上云已經成為普遍共識，同時企業各業務部門對大數據分析的需求更加普遍化、敏捷化、個性化、場景化，數據的業務價值也由輔助決策轉變為推動創新。在這一背景下，數據基礎設施開始進入“云數據平臺”階段。

業務場景

該階段的企業，其數字化場景更加廣泛且普遍，而且產生了大量的跨部門、跨業務線，甚至跨分支機構、跨組織、跨地域的數據共享與聯動分析。同時，孵化于企業原有體系內，但又需要由數據來驅動迭代優化的創新業務層出不窮。

因此，企業數字化轉型思路需要從過去的單個場景突破，轉變為全集團、跨組織、跨地域的數據共享與資產化管理，以及全場景數據賦能。

組織架構

為了推動集團層面的業務、數據共享，加速業務的敏捷創新，企業需要在組織架構層面對數字化人才、數據基礎設施的管理和運營團隊進行統籌規劃。

比如，以阿里巴巴、騰訊為代表的互聯網巨頭都先后提出了“中臺戰略”，成立中臺部門對數字化戰略進行統籌。為了推動數據的跨部門復用與共享， “數據中臺”的概念也被同時提出。

數據基礎設施的技術架構

然而，“數據中臺”概念的局限性在于并未改變數據基礎設施的底層技術架構，而是沿用了大數據平臺階段的技術架構，并保留了傳統技術路線帶來的弊端。

對此，云數據平臺采用了計算與存儲分離、虛擬計算集群等新型技術架構，對象存儲等云原生技術對數據平臺進行了深度優化。

數據基礎設施的功能特點

基于云原生、計算存儲分離、虛擬計算集群等新型技術架構，云數據平臺實現計算、存儲節點獨立擴展，突破了基于MPP、SQL-on-Hadoop技術的大數據平臺在擴展性、靈活性方面的局限。

此外，云數據平臺還克服了SQL-on-Hadoop數據庫在SQL標準、ACID特性等方面的不足，可以支持數字化應用從傳統共享存儲數據倉庫、MPP數倉向云數據平臺的平滑遷移。

最后，大數據平臺的基礎上，云數據平臺吸納了來自“數據中臺”理念的數據資產層與數據服務層，從而形成“數據平臺-數據資產-數據服務”的三層架構。

圖5：云數據平臺“平臺-資產-服務”三層架構

數據基礎設施的性能特點

相比于大數據平臺，云數據平臺擺脫了以Hadoop為核心的技術體系的影響，克服了其在性能優化和并發等方面的缺陷，對云平臺進行了原生優化，尤其是在分析型云數據倉庫方面，可以支持計算與存儲分離，彈性可擴展，支持數千節點規模集群，虛擬計算集群，湖倉一體，并對性能做了深度優化，從而大幅度提升面向多張表、批量數據、復雜表關聯的復雜查詢性能。

02

企業數字化深入推進，云數據平臺價值顯現

盡管數據基礎設施經歷了漫長的演進歷程，但從數據庫、數據倉庫到大數據平臺階段，數據基礎設施在擴展能力、彈性能力、查詢性能、易遷移性等方面，始終受到技術路線繁雜、遺留問題重重的MPP、SQL-on-Hadoop等上一代數據倉庫技術的制約。

同時，企業數字化實踐的主戰場，已經從過去的互聯網、創新型企業，全面轉到以集團型、多分支企業為代表的大中型傳統企業，數字化需求的深度、廣度出現全面提升。

然而，時下的“數據中臺”解決方案，本質上只是在大數據平臺的基礎上，融合了數據資產化與數據服務化的管理能力，并沒有對大數據平臺的原有技術路線進行革命性升級。

因此，數據基礎設施需要對技術進行徹底變革，變得更加統一與強大，而新一代數據基礎設施——“云數據平臺”的出現，則預示著數據基礎設施的未來變革方向。

2.1 四大新挑戰困擾企業數字化轉型

金融、能源、制造、零售等行業內，存在著許多體量龐大、組織架構復雜的集團型、多分支企業。然而，這類企業在推進數字化轉型過程中，數字化應用逐步表現出了“大規模”、“強敏態”、“高時效”、“智能化”等四大新特征，對數據基礎設施提出了相應的四大挑戰，如下圖所示。

圖6：數據基礎設施面臨的四大挑戰

2.1.1 數據規模膨脹，數據基礎設施產生新“數據孤島”

金融、電力、電信等行業內企業，普遍存在業務系統眾多、交易次數巨大、交易額度巨大、數據積累量巨大等特征。據公開數據顯示，2019年全國銀行卡交易總次數為3219.89億筆，日均8.82億筆，交易總金額886.39萬億元，日均2.43萬億元。

因此，企業內的數字化應用對數據基礎設施的計算并發量、存儲上限的要求越來越高，數據基礎設施的節點規模出現了急劇膨脹。比如，某國有大行需要分析數十PB級交易數據，需要3000以上的數倉節點才能滿足存儲需求。

圖7：數據規模膨脹對數據基礎設施的挑戰

在這樣的背景下，兩方面因素共同導致了數據基礎設施內的“數據孤島”產生，進一步拉高了企業的數據運維管理成本。

傳統交易型數據庫與MPP數倉的節點規模限制

目前，MPP憑借對SQL標準、ACID特性的良好支持，仍然是大型企業的核心數字化應用的主流選擇。此外，許多企業還在采用Oracle、DB2等傳統的交易型數據庫來支撐數據分析業務。

面對膨脹的數字化應用規模，企業內的數據基礎設施一旦達到可擴展的節點上限，必須采用多集群部署方式，即通過應用級的多集群劃分來支撐更多的應用帶來的并發計算，通過多集群間的數據分散存儲來支撐更高規模的數據存儲。

但是，傳統交易型數據庫、MPP數據倉庫的可擴展節點上限僅在十幾到上百節點，在許多數字化較為領先的大型企業內，節點需求已經很容易突破上限，因而同時部署多個MPP集群，已經成為大型企業數字化的必須。

比如，某國有大行需要分析10PB級交易數據，需要3000以上的數倉節點才能滿足存儲需求，因此只能建立40個MPP集群。但是，多集群間的數據共享十分困難，該行只能對部分數據在多個集群進行多份冗余存儲，導致最終的實際數據存儲量高達幾十PB，集群之間數據很容易產生不一致，給該行造成了極大的運維負擔。

由此可見，盡管數據基礎設施的出現與發展始終是為了實現數據共享利用，消除交易型數據庫之間的“數據孤島”，但是多集群的現狀，事實上在數據基礎設施內部制造了新的“數據孤島”。

不同技術架構的數據倉庫間的應用易移植性問題

與傳統交易型數據庫、MPP數倉不同，Hive、SparkSQL等SQL-on-Hadoop數倉具備上千節點規模的擴展能力，但其缺陷在于對SQL標準、ACID特性的支持能力不足，性能比MPP差多倍，并發支持有限，因此許多大型企業傾向于將更多地應用在邊緣業務的數字化場景中，與MPP數倉并行使用，共同構建數據基礎設施。

然而，傳統交易型數據庫、MPP數倉、SQL-on-Hadoop數倉在計算存儲架構方面的差異，以及在SQL標準、ACID特性上的不兼容，意味著雙方之間的數據遷移和共享十分困難。

但是，未來大型企業的數字化，往往不再是過去由單個部門、單條業務線驅動的數字化，而是越來越多地由戰略層面進行統籌規劃，全部門、全業務線協同推進的數字化。在這種背景下，大型企業常常需要將過去獨立建設的數字化應用進行遷移，以同一套數據基礎設施支撐上層各個業務線的數字化應用，不但實現了管理的統一，還可提升其擴展能力。

因此，在將遺留的數字化應用在不同技術架構進行遷移過程中，往往需要進行大量的代碼重構，移植成本較高，難以實現平滑遷移。

例如，某電網系統內分公司搭建了基于Hive的大數據測試環境，但是擁有更多計算節點的Hive大數據分析性能對比Oracle幾乎沒有提升，且原有基于Oracle的眾多應用系統向Hive遷移時，由于Hive不支持存儲過程等Oracle很多功能，需要改寫的代碼量巨大。

因此，大型企業在數字化過程中，亟需探索一套通過“大一統”方式來建設數據基礎設施的解決方案，消除數據基礎設施內的“數據孤島”現象。

為了應對這些挑戰，新一代數據基礎設施——“云數據平臺”應具備以下能力：

計算存儲分離架構，及其帶來的強擴展性、強共享性：采取計算、存儲分離的技術架構，支持數千節點的集群規模，支持多虛擬計算集群；

強SQL標準支持、ACID特性、Hadoop原生支持（即支持傳統Hadoop生態系統），及其帶來的強兼容性：具備完善的SQL標準、ACID特性的支持能力，兼容過去采用Oracle、DB2等傳統交易型數據庫、MPP數據庫的數字化應用，并支持對接訪問HDFS等Hadoop原生組件，從而兼容過去采用SQL-on-Hadoop數據庫的數字化應用。

圖8：云數據平臺應對數據規模膨脹挑戰

2.1.2 敏態特征凸顯，數據基礎設施彈性能力受挑戰

早在2014年，Gartner就提出了融合“穩態IT”與“敏態IT”的“雙模IT”概念。對于傳統行業內的集團型、多分支企業來說，加強“敏態IT”能力建設，是推進數字化轉型的重要組成部分。

在“敏態IT”模式下，企業需要更加關注業績增長、品牌營銷與客戶體驗，大幅增強面對不確定場景的響應能力，這就要求企業IT團隊在資源獲取、應用迭代、系統運維等方面實現敏捷化轉型。

比如，國內某大型航空公司，為了推進全公司的IT敏捷化轉型，從團隊、工具、方法、實踐等四個層面實踐敏捷理念。在工具層面，該航司依托云計算IaaS平臺，以及基于云數據庫、Docker、Kubernetes、AIOps等技術的PaaS平臺，構建了一站式敏捷開發管理平臺，將過去基于傳統IT環境的應用交付過程遷移到云上，有效提升了產品迭代速度，優化了客戶體驗，促進了業績增長。

由此可見，具備按需取用、快速彈性、自動化編排等優勢的云計算、云原生技術，成為支撐“敏態IT”的新型IT基礎設施。

這一趨勢對數據基礎設施的影響表現為兩個層次，第一層是傳統業務上云帶來的數據的上云，第二層是數字化場景拓展帶來的數字化應用上云。

傳統業務與數據上云

隨著數字化轉型的深入推進，企業上云從互聯網企業逐步滲透到傳統企業，從創新業務、邊緣業務逐步滲透到傳統業務、核心業務。同時，隨著企業上云的推進，全球范圍內的數據的產生與存儲過程，越來越多地從傳統數據中心轉移到公共云環境中。

根據IDC報告顯示，到2025年，公共云中的數據百分比將接近50%。

數字化應用上云

隨著數字化營銷與銷售、數字化生產制造、數字化采購、數字化協同辦公等新興數字化場景不斷出現，企業IT的“敏態”特征不斷增強，工作負載量、負載量的波動性相比過去都有明顯提升。

因此，數字化應用上云也成為大勢所趨。另一方面，來自傳統業務、核心業務的交易數據的逐步上云，也為數字化應用的上云鋪平了道路。

在這兩大背景之下，為了保證數字化應用的高可用性，數據基礎設施同樣應當具備“敏態”特征，滿足資源快速取用、快速啟停的彈性能力。因此，對數據基礎設施進行云化改造將成為必然趨勢。

圖9：數字化應用的敏態化對數據基礎設施的挑戰

但是，數據基礎設施在進行云化改造時面臨的兩大挑戰。

首先，共享存儲、MPP無共享、SQL-on-Hadoop等技術架構對云環境的特性（如彈性能力）、組件（如云存儲）適應性不足，存在彈性性能瓶頸，難以充分發揮云的彈性優勢。

其次，共享存儲、MPP無共享等技術架構的計算、存儲節點深度耦合，無法實現計算、存儲性能的非等量擴容，對IT資源的高效利用帶來障礙。

再如，某制造型企業上線數字化的排產管理系統后，經常會遇到兩種情況：首先，隨著應用上線時間推移，數據存儲量呈快速的線性增長；其次，在生產高峰期內，計算工作負載往往在短時間內會出現波峰，但在生產高峰期結束后則會迅速恢復到正常水平。過去，該企業采用基于MPP架構的Greenplum集群，計算、存儲節點完全耦合，不支持存儲和計算獨立擴容。因此，當該企業處于生產高峰期內，如果選擇充分滿足計算性能需求，則存儲性能容易造成浪費，但如果選擇有限滿足計算性能需求，則會造成服務可用性不足。

圖10：計算存儲耦合與計算存儲分離架構的對比

因此，企業數字化的新階段下，為了應對應用上云、數字化應用比例增加的趨勢，“云數據平臺”應具備以下能力：

云原生特性、計算存儲分離架構，及其帶來的高彈性：利用云服務器、分布式存儲等云原生技術，對數據基礎設施的擴展性能進行深度優化，充分適應云上數字化應用對高度彈性、無限擴容能力的要求；采取計算、存儲分離的技術架構，充分適應數字化應用對計算、存儲分別獨立擴展的要求，增強彈性擴展的靈活性。

圖11：云數據平臺應對數字化應用敏態化挑戰

2.1.3 數據時效性要求提升，數據基礎設施查詢性能受限

面對激烈的市場競爭，大型企業在決策效率方面的劣勢，同樣亟需通過數字化手段進行改變。

在金融、零售等具有強烈營銷導向的行業內，越來越多的企業決策者和業務人員，都期望能夠實現T+1、甚至T+0的數據反饋，從而基于更有時效性的數據進行業務決策，避免因決策周期過長而導致錯失商機，這意味著大型企業對數字化應用的時效性要求將持續提升。

從技術原理來看，數字化應用的時效性，主要依托于大數據平臺所提供的面向批處理、即席查詢等分析型場景（OLAP）的復雜查詢能力。但是，數據量的增長帶來的數據處理量的增長，以及基于SQL-on-Hadoop的數據基礎設施在OLAP復雜查詢場景的性能瓶頸，使得數字化應用的時效性越來越難以得到保證。

圖12：數據時效性要求提升對數據基礎設施的挑戰

批處理的性能瓶頸：在批處理模式下，數據服務依托于構建好的分層數據模型。Hive、SparkSQL、MPP等查詢引擎，對來自ODS（貼源數據層）的數據進行批量計算，分層將數據抽取到DWD（明細數據層）、DWS（聚合數據層）、ADS（應用數據層）/DM（數據集市層）中，最后由ADS或DM來為可視化大屏、報表分析、數據API等數據服務提供數據支撐。因此，批處理性能的瓶頸，將會導致數據基礎設施難以在T+1日內完成批處理工作，從而影響數據服務的時效性。

即席查詢的性能瓶頸：在即席查詢模式下，數據服務不依托于數據模型，而是由用戶自行定義查詢維度，直接從數據庫中進行關聯查詢。因此，即席查詢性能的瓶頸，將會導致用戶查詢時面臨較高的時間延遲，影響用戶體驗。

例如，某股份制商業銀行在Oracle、DB2傳統數據倉庫上，建設了管理會計系統、績效考核系統、監管報送系統、數據集市系統等幾十個大型分析系統，數據在PB級以上，但是傳統數據倉庫的性能瓶頸造成了兩方面的困擾。一方面，管理會計系統、績效考核系統等分析系統全部無法全部滿足T+1時間需求，嚴重影響銀行領導的決策分析，以及各分行業務部門每日運營工作的安排部署。另一方面，大數據分析人員需要在海量歷史數據中進行即席查詢，但隨著銀行數據量快速增加，每運行一條分析SQL都需要10分鐘以上時間。

因此，企業數字化的新階段下，為了應對數字化應用、數據服務的高時效性要求，“云數據平臺”應具備以下能力：

高性能并行執行能力，及其帶來的強復雜查詢性能：采取最新的SIMD指令集，實現指令內并行技術，從而實現更高性能的并行執行器，從而提供面向PB級大數據的，比MPP、SQL-on-Hadoop數據倉庫更快的復雜查詢性能，從而明顯降低批處理、即席查詢所需的時間，提升數據服務的時效性。

圖13：云數據平臺應對數據時效性的挑戰

2.1.4 智能化場景逐步成熟，數據基礎設施AI支持能力不足

近些年來，金融行業作為數字化較為領先的行業，其客戶畫像、信貸信用評分、反欺詐、反洗錢、合規審計等智能化場景逐步成熟。由此，數據的價值逐步由“數據驅動問題發現”“數據驅動問題分析”走向“數據驅動趨勢預測”、“數據驅動業務決策”，這進一步要求數據基礎設施能夠支撐智能化應用的快速開發。

傳統的數據倉庫中通常會內置In-Database機器學習庫，但對于使用者的AI知識水平要求較高，而許多傳統行業企業缺乏AI人才，如果選擇從零開始構建AI團隊、建設AI平臺，投入成本十分高昂。

圖14：智能化應用對數據基礎設施的挑戰

因此，企業數字化的新階段下，為了應對數字化應用的智能化需求，“云數據平臺”應具備以下能力：

自動化機器學習支持：基于AutoML技術，允許業務人員通過托拉拽、低代碼的方式，實現自動化AI建模；融合云數據平臺的數據模型，構建從業務理解、數據接入與處理、特征工程、模型選擇、優化算法選擇、參數調優、模型評估、模型部署與發布、模型優化等AI全生命周期管理流程。

2.2新一代數據基礎——云數據平臺

為了滿足以集團型、多分支企業為代表的大中型企業數字化轉型的新挑戰，新一代數據基礎設施應當通過底層技術變革，推動技術能力變革，最終滿足上層業務的變化。

為此，愛分析從底層技術變革、技術能力變革、業務場景變革三個層次，對新一代數據基礎設施“云數據平臺”進行定義。

2.2.1 云數據平臺的定義

愛分析認為，“云數據平臺”是新一代的數據基礎設施，它能夠依托云原生特性、計算存儲分離架構、強ACID特性、強SQL標準支持、Hadoop原生支持、高性能并行執行能力等一系列底層技術的變革，實現高彈性、強擴展性、強共享性、強兼容性、強復雜查詢能力、自動化機器學習支持等上層技術能力的變革，最終幫助企業有效應對大規模、強敏態、高時效、智能化等愈發明顯的數字化趨勢。

圖15：云數據平臺的概念

云原生特性、計算存儲分離架構，及其帶來的高彈性：利用云服務器、分布式存儲等云原生技術，對數據基礎設施的擴展性能進行深度優化，充分適應云上應用對高度彈性、無限擴容能力的要求，并采取計算存儲分離架構，進一步提升數據基礎設施的擴展靈活性；

計算存儲分離架構，及其帶來的強擴展性、強共享性：采取計算、存儲分離的技術架構，充分適應數字化應用對計算、存儲分別獨立擴展的要求，增強了彈性能力，并能夠支持數千節點的集群規模，盡可能避免多集群部署，并可低成本地支持跨集群的數據共享；

強ACID特性、SQL標準支持、Hadoop原生兼容，及其帶來的強兼容性：具備完善的SQL標準、ACID特性的支持能力，兼容過去采用Oracle、DB2等傳統交易型數據庫、MPP數據庫的數字化應用，并支持對接訪問Hive、HDFS等Hadoop原生組件，從而兼容過去采用SQL-on-Hadoop數據庫的數字化應用，實現數字化應用在數據基礎設施間的平滑遷移；

高性能并行執行能力，及其帶來的強復雜查詢性能：面向PB級大數據，具備比MPP、SQL-on-Hadoop數據倉庫更快的復雜查詢性能，從而明顯降低批處理、即席查詢所需的時間，保證數據處理能力的高時效；

自動化機器學習支持：具備對自動化機器學習技術的支持能力，基于AutoML等技術，為業務人員提供自動化AI建模能力，實現AI模型全生命周期管理，降低AI研發與管理成本。

數據資產管理能力：具備數據標準管理、數據質量管理、元數據管理、數據資產目錄（敏感數據/業務術語表關聯/數據標簽/血緣分析）等數據資產化管理能力，從而更好地賦予數據以價值，實現數據的資產化管理與運營。

數據服務管理能力：通過數據API管理模塊提供的低門檻、可視化的操作方式，以及分組、權限管理、服務上下線、計量與計費等管理功能，幫助數據分析人員將各類數據查詢語句封裝為API服務，供各業務部門和業務系統調用，從而實現數據的價值變現。

2.2.2云數據平臺對數字化技術的“有機統一”

作為新一代的數據基礎設施，“云數據平臺”實現了兩方面的“大一統”，即對多種數據基礎設施技術架構、多種數字化技的有機統一。

一方面，“云數據平臺”本質上是對傳統的數據庫、數據倉庫、大數據平臺階段遺留的一系列底層技術、技術能力的升級與替代。

圖16：云數據平臺是對數據庫、數據倉庫、大數據平臺的升級與替代

另一方面，“云數據平臺”實現了對云、大數據、AI等多種數字化技術價值的有機統一。在實際的數字化項目落地過程中，以云能力、數據能力、AI能力為中心的數字化轉型往往相互割裂，未能實現充分協同。

以云能力為中心的數字化轉型：通過云基礎設施建設及組織架構的變革，推動企業IT資源管理能力的數字化轉型；缺乏數字化能力的IT組織難以充分支撐業務部門數字化的需求，同時又是企業更好地沉淀、利用數據的基礎；

以數據能力為中心的數字化轉型：通過數據基礎設施建設及組織架構的變革，推動企業數據利用能力的數字化轉型；既是對云基礎設施價值的進一步提升，也為AI應用的開發建立良好的數據基礎，在整個企業數字化轉型中居于承上啟下的地位；

以AI能力為中心的數字化轉型：通過AI平臺建設、智能化應用的落地應用及組織架構的變革，推動企業分析決策能力的智能化轉型，也是對數據基礎設施價值的進一步挖掘。

整體來看，“云數據平臺”充分整合了云原生特性，更統一、更強大的數據能力，以及對AI應用的支持能力，為企業提供了“更統一、更強大”的數字化技術能力，未來將進一步推動企業數字化深度、廣度的全面升級。

圖17：云數據平臺的價值

2.2.3以云數據平臺為核心的企業數字化轉型方案

近些年來，隨著企業數字化深度、廣度的全面升級，國內外分別崛起了一系列典型的“云數據平臺”提供商。

國外較為領先的云數據平臺提供商Snowflake，在2020年9月17日于紐交所上市當天，市值突破700億美元。截止2020年11月底，Snowflake的市值更是已高達830億美元。

國內較為領先的云數據平臺提供商偶數科技，核心創始團隊來自EMC數據庫團隊，其核心產品為新一代云原生數據倉庫Oushu Database。

偶數科技基于云數據平臺的企業數字化方案

偶數科技除了具備核心產品新一代云原生數據倉庫Oushu Database，還提供了包括數據管理平臺Oushu Lava、自動化機器學習平臺Oushu LittleBoy等一系列配套產品，共同構成一套完整的云數據平臺解決方案，從而有效支撐金融、能源、制造等行業的大中型企業客戶的全面數字化轉型。

圖18：偶數科技云數據平臺解決方案

新一代云原生數據倉庫Oushu Database：Oushu Database（簡稱OushuDB）是由新一代云原生數據倉庫，具備ANSI-SQL標準兼容、ACID特性支持、Hadoop原生支持等特性，兼容Oracle、Greenplum Database、PostgreSQL和Hadoop原生技術體系，采用了存儲與計算分離和虛擬計算集群技術架構，實現彈性伸縮、秒級擴容和超大規模集群（幾千節點級別）的支持。OushuDB在業界首次解決了大數據量下跨數據中心的數據存儲和分析問題，并設計了新一代SIMD執行器，性能比傳統數倉快大約5-10倍，提供PB級數據交互式查詢能力，提供對主要BI工具的描述性分析和AI支持，對于金融等行業的吸引力進一步增強。

數據管理平臺Oushu Lava：Oushu Lava是一款定位于幫助企業構建云數據平臺的工具集，包括數據接入工具、數據開發工具、數據資產管理工具、數據服務管理工具等部分，支持客戶進行敏捷數據應用開發，助力企業實現數字化轉型。

自動化機器學習平臺Oushu LittleBoy：Oushu LittleBoy是一個通用的自動化機器學習平臺，可以幫助企業級用戶輕松實現人工智能落地。Oushu LittleBoy可通過內置的AutoML從上億個模型中自動挑選出優化的模型，讓用戶在不了解算法原理的情況下自動選出最優配置，提升業務效率。

愛分析認為，“云數據平臺”未來將成為以集團型、多分支企業為代表的大中型企業數字化的堅實底座。

03

以云數據平臺為中心的企業數字化落地方法論

正如章節2.2.2所述，云數據平臺在數據基礎設施的基礎上，實現了對云、AI能力的無縫融合，是企業數字化落地的一種更先進的技術形式。

但是，以云數據平臺為中心的企業數字化轉型，需要更加完善和體系化的落地方法論。一般來講，數字化方法論包括戰略規劃與落地實施兩個維度。

按照章節1.1中的描述，企業數字化的戰略規劃應當包括數字化戰略、數字化場景、數字化技術、數字化組織等四個層次。

從落地實施維度上看，企業數字化實施過程包括：路徑規劃、需求分析、方案設計、方案實現、方案支持與迭代等五個步驟。

圖19：企業數字化實施過程

3.1 路徑規劃

路徑規劃階段的主要目標是確立數字化轉型路徑。為此，企業首先需要確立數字化愿景與整體目標，梳理業務場景、數字化現狀，并構建數字化實施團隊，最終交付現狀調研報告與數字化轉型路線圖。

圖20：路徑規劃

數字化愿景與整體目標確立

確立企業數字化愿景與整體目標的主要價值，在于使得企業上下達成對數字化的同一認知，從而有助于協調資源，降低數字化推行阻力。為此，企業高層領導需要對數字化轉型進行統籌規劃，提出宏觀層面的方針與指示。

應用場景梳理

梳理數字化場景的主要價值，在于使企業能夠正確認識數字化帶來的潛在價值，明確數字化轉型項目的波及范圍及投入規模。為此，企業需要對應用系統現狀進行梳理，并對現有的痛點及業務價值進行判斷。

應用系統現狀梳理：各應用系統的產品名稱、版本、開發商、使用者、運維方，應用系統的對接方式（接口類型、模板、語言、工具）及數據庫對接方式；

痛點及業務價值判斷：對用戶在使用各應用系統過程中存在的痛點進行調研與收集，對潛在的數字化價值進行初步判斷。

數字化現狀梳理

梳理數字化現狀的主要價值在于幫助企業判斷業務場景數字化的當前階段。為此，企業需要對源系統數據存儲、現有大數據平臺、BI平臺、人工智能、基礎設施及架構的現狀進行系統性梳理。

源系統數據存儲現狀：交易型數據庫產品名稱、版本、應用情況、使用者、運維方；對外數據接口方式、負載現狀、元數據信息；

數據基礎設施現狀：分析型數據庫產品名稱、版本、使用者、運維方、應用場景、數據存量；用戶規劃、權限分配等情況；運維、監控、預警平臺現狀；schema數量、名稱、作用；主題域、邏輯模型和物理模型；表、視圖、函數數量；

比如，數據基礎設施往往存在多種負面現狀，如集群數量過多、不利于數據共享與維護，計算存儲耦合、彈性能力受限，數據跑批與即席查詢性能不足、數據報表與查詢結果產出時效性差等；在云數據平臺的實施過程中，企業對這些現狀應當予以重點解決；

BI平臺現狀：BI產品名稱、版本、使用者、運維方；BI報表數量、BI是否支持自助式報表；

人工智能現狀：AI平臺產品名稱、版本、使用者、運維方；AI模型的應用場景；AI模型的名稱、數量及算法；建模任務現有運行時間；特征工程建立方式；

比如，企業往往以使用規則引擎、傳統機器學習算法來實現AI預測，且僅面向少量應用系統，無法實現對深度學習AI模型的敏捷開發；在云數據平臺的實施過程中，企業對該現狀應對予以重點解決；

基礎設施及架構現狀：現有系統架構圖、現有系統組件構成、現有集群數量及系統部署情況、現有服務器單節點硬件配置。

數字化轉型實施團隊構建

構建數字化轉型實施團隊主要價值在于為企業數字化戰略提供人才支撐，因為缺乏人才支撐的數字化轉型，在啟動階段就會遇到重重障礙。數字化轉型實施團隊主要包括以下三類人才。

數據戰略和數據治理類：數據戰略顧問、數據治理專家、數據項目經理；

數據科學和數據工程類：數據科學家、人工智能機器學習算法工程師、大數據工程師、數據測試工程師、數據運維工程師；

數據管理和數據應用類：數據建模顧問、數據分析顧問。

在一系列現狀梳理工作過程中，數字化轉型實施團隊可通過交付《現狀調研報告》來作為中間成果，從而幫助企業高層明確企業現狀，并為未來的需求分析工作積累文檔素材。

在戰略規劃階段結束時，數字化轉型實施團隊需要交付《數字化轉型路線圖》作為階段性成果，以確定企業數字化轉型階段劃分，從而幫助企業高層合理安排資源投入，并確定項目排期。

3.2需求分析

需求分析階段的主要目標，是將路徑規劃階段制定的整體目標拆解到具體業務場景中，以制定更加具體的數字化實施排期方案。為此，企業需要首先對應用場景進行定義與分析，并對數字化需求進行分析，從而進行初步的系統演示，并交付數字化需求分析報告。

從這一階段開始，企業可與有大量成功實施經驗的數字化廠商（如偶數科技）展開密切合作，從而有效降低學習成本，提升實施效率，降低失敗風險。

圖21：需求分析

應用場景定義與分析 應用場景定義與分析的主要價值，在于使得企業更加明確各個場景內數字化的潛在價值、所需投入，并有效指導數字化需求分析過程的分析范圍與最終目標。為此，企業需要確定應用場景對應的業務目標，并對場景內的流程與需求功能進行分析。 數字化需求分析 數字化需求分析的主要價值，在于對數字化解決方案架構中的各個系統、模塊與組件應達成的目標與效果進行確認，包括對數據存儲與計算、數據資產、數據服務、數據平臺、硬件部署、人工智能等各個模塊的需求分析。

數據存儲與計算需求：未來數年數據量增長、存儲需求、災備需求及批處理、實時查詢性能需求；數據存儲和計算需求功能列表；

比如，業務部門需要在T+1完成跑批結果，同時希望進一步擴大跑批所分析的數據量，從PB級到十PB級以上；業務部門希望將長達數分鐘的即席查詢周期，提升到秒級獲取查詢結果；

數據資產管理需求：數據治理的目標分析，元數據管理、數據標準、數據質量規則需求，數據治理需求功能列表；數據資產目錄需求，數據資產管理需求功能列表；

數據服務管理需求：數據服務接口需求，數據服務部署需求；數據集市需求，數據可視化需求，數據報表需求；

現有數據平臺需求：現有大數據平臺存在的優勢，以及與源數據系統、外圍應用系統的適配性分析；數字化轉型對大數據平臺的新需求，現有大數據平臺對業務需求及數據需求的不滿足之處，以及所需的需求功能列表；

硬件部署需求：業務增長及數字化轉型對新型平臺硬件的變更需求，平臺硬件部署拓撲結構變化需求分析，平臺硬件部署需求功能列表；

人工智能需求：AI模型最終用戶確認；AI模型需求分析，如業務應用準確率與召回率，樣本庫數據，模型指標庫，AI模型更新頻率等；AI工具需求分析，如AI模型生命周期管理，應用系統調用AI模型方式；AI模型開發運維團隊分配；現有AI模型問題匯總。

在需求分析階段結束時，數字化廠商可基于測試環境，對數字化轉型方案進行系統安裝演示，并與企業客戶密切配合，共同交付《業務及數據需求分析報告》。

3.3方案設計&方案實現

方案設計階段的主要任務，是對數字化轉型方案中的各個系統、模塊與組件的技術實現方式進行設計，提前發現實施中可能存在的難點，指導各個實施小組的具體分工協作方式，以保證方案實現階段的工作能夠合理、有序進行。

方案實現階段的主要任務，是按照方案設計階段輸出的交付物，通過實際的編碼、實施，將設計方案進行落地交付。

在理想狀態下，方案設計與方案實現的內容能夠完全一一對應，而且不會交替進行。但是，在許多情況下，由于設計階段考慮的不周，或者項目排期的客觀原因，這兩個階段可能是交替進行的，即在方案實現過程中或階段完成后，方案設計仍需要重復進行。

在方案設計與實現階段，企業需要對應用場景、數字化技術方案進行設計與實現。

圖22：方案設計&方案實現

應用場景設計與實現

應用場景設計與實現的主要價值，在于保證云數據平臺與企業業務場景的良好適配，從而實現其最大化的業務價值。

業務架構設計與實現：對應用場景下，企業自有的業務流程體系、業務運營模式、組織結構及其對應IT應用系統架構進行設計與實現，該工作一般需要企業或相應的外部服務商來完成；

平臺功能設計與實現：對應用場景下，云數據平臺自身的交互流程、功能界面及接口進行設計與實現；

數據流設計與實現：對應用場景下，數據在云數據平臺、BI平臺及外部系統的流動方式進行設計與實現。

數字化技術方案設計與實現

數字化技術方案的設計與實現，是整個數字化轉型項目的核心內容，其時間與人力成本投入在整個項目中占據較高比重。

數據模型設計與實現：數據模型的設計規范；邏輯數據模型的設計與實現，包括主題域分析，建立實體模型，建立實體間依賴關系；物理數據模型的設計與實現，包括轉換邏輯數據模型為物理數據模型，對模型設計進行優化；

數據處理設計與實現：通過ETL、任務調度等工具進行數據轉換與加載，包括數據抽取、轉換和加載策略的設計與實現，以及自動化調度依賴關系的設計與實現；

比如，企業可應用Oushu Lava，以OushuDB高性能云數據倉庫替代Hive引擎，基于同樣的PB級數據和僅一半服務器節點數，跑批性能提升幾十倍，復雜即席查詢分析可在秒級完成；

數據資產管理設計與實現：元數據管理的設計與實現，包括元數據功能、元數據提取規則及周期、元數據變更；數據標準的設計與實現；數據質量檢查的設計與實現；錯誤數據處理的設計與實現；數據資產目錄的設計與實現，包括數據權限分配等；

數據服務管理的設計與實現：數據服務接口的設計與實現；數據服務部署的設計與實現；數據集市模型的設計與實現；數據可視化、數據報表、圖形可視化的設計與實現；

AI模型設計與實現：AI模型特征工程設計與實現；AI模型算法/參數設計與實現；AI模型指標庫設計與實現；AI模型服務設計與實現；AI應用場景數據寬表設計與實現；

比如，應用LittleBoy自動化機器學習系統深度學習算法自動化完成關于客戶畫像、電信反欺詐等應用場景的模型訓練、發布、生命周期管理，顯著提升預測準確率、召回率。

基于企業與數字化廠商的密切配合，在方案設計階段結束時，雙方需要交付《數字化轉型方案設計報告》，而在方案實現階段結束時，雙方需要交付《數字化轉型方案交付報告》，并由企業對項目進行驗收測試與試運行。

3.4方案支持與迭代

在方案支持與迭代階段的主要目的，是保持數字化轉型方案的生命力，讓其產生更加持久的業務價值。為此，企業需要與數字化廠商配合，對現有方案進行培訓與推廣，對已完成的數字化轉型項目的業務價值進行復盤，對數字化技術方案進行持續迭代，對潛在業務場景進行持續探索。

圖23：方案支持與迭代

用戶培訓與應用推廣：對業務場景、操作規范、云數據平臺相關技術進行培訓；制定應用推廣計劃，包括應用準備、應用推廣啟動、業務需求交流、專題應用開發、專題結果分析、應用評估總結、應用跟蹤提升等環節；

業務收益復盤：通過業務部門的持續反饋以及對項目前后的業務指標的統計，通過定性判斷、定量計算等多種方式，對數字化轉型項目的業務價值與收益進行復盤，發現不足并尋找原因，從而指導未來的方案優化迭代；

數字化技術方案迭代：基于業務收益復盤的結果，對數據存儲和計算進行性能調優，對數據資產管理、數據服務管理進行回顧與優化，對AI模型進行持續迭代與優化；

新應用場景探索：通過業務部門的持續反饋，確定企業新的業務場景、業務需求，并重復需求分析、方案設計、方案實現等環節，最終實現業務價值的驗證。

04

典型行業實踐案例

4.1 銀行行業案例

企業概況

某銀行是12家全國性股份制商業銀行之一，以四大業務板塊（公司、小微、零售、同業）作為品牌支柱。該行于2016年在香港聯交所上市，于2019年在上海證券交易所上市，系全國第13家“A+H”上市銀行。

截至2019年末，在全國19個省（直轄市）及香港特別行政區設立了260家分支機構，實現了對長三角、環渤海、珠三角以及部分中西部地區的有效覆蓋。

面對經濟新常態，該行順應互聯網信息技術發展新趨勢和客戶價值創造新需求，確立了“兩最”總目標和平臺化服務戰略，堅持“服務實體經濟、創新轉型、合規經營、防化風險、提質增效”五項經營原則，打造平臺化服務銀行，為客戶提供開放、高效、靈活、共享、極致的綜合金融服務。

數字化愿景與整體目標

為實現全行數字化轉型，打造行業領先的零售銀行、普惠金融，該行需要通過建立云數據平臺滿足業務創新應用敏捷開發、大數據數據資產價值最大化、人工智能深入應用的需求，從而不斷提升客戶體驗，進一步加強在股份制銀行中的地位。

應用場景梳理

該行現有應用系統包括管理會計系統、績效考核系統、風險預警系統、客戶畫像系統、反電信詐騙系統、反欺詐系統、監管報送系統等幾十個基于全行數據分析完成的應用。

數字化現狀梳理

該銀行已建設大數據智能平臺來推動數字化轉型，其基本現狀如下：

Oracle、DB2傳統數據倉庫幾百TB級數據，幾萬張表、上萬個ETL作業任務，全行大數據在快速增長；

ODS區是采用文本文件的方式從源系統獲取數據；標準數據集市區為統一交換平臺，為分行大數據平臺服務；總行大數據平臺區實現數據粘帖、數據匯總、數據應用；分行大數據平臺區實現數據粘帖、數據匯總、數據應用；沙盤演練區：開發測試環境區域，供開發測試以及各種演示使用

只有少數場景使用規則引擎加手工修改腳本參數的方式實現人工智能預測。

數字化需求分析

該行現有的數據基礎設施存在大量痛點，難以支撐數字化轉型的進一步推進：

由于傳統數據倉庫存儲及計算性能接近上限：無法滿足全行數據未來幾年的增長；

數據孤島依然存在：沒有沉淀數據資產，缺少數據治理系統工具及完備的數據標準；

無法快速賦能業務應用創新；對于某個分析業務的需求，用戶從準備數據，匯集數據，建立模型，生成報表整個過程需要的周期太長，效率低下；

規則引擎預測準確率比較低、缺少自動化機器學習模型預測。

數字化技術方案設計與實現

偶數科技為了幫助該行應對數字化中存在的痛點，從數據戰略、云數據平臺整體架構、數據資產管理、數據治理、人工智能建模平臺建設等方面為該行完成了詳細的設計與實施方案：

圖24：新一代云數據平臺方案

數據來源：偶數科技

應用Oushu Lava，以基于HDFS的OushuDB高性能云數據倉庫替代Oracle、DB2數據倉庫，現有上百個節點可以支持PB級數據、可動態擴容，單一集群支持上千節點，滿足行方未來十年數據高速增長，且跑批性能是之前傳統數據倉庫的數倍；

應用Lava數據治理套件實現數據治理，完成數據標準管理、元數據管理、數據資產管理；

應用LittleBoy自動化機器學習系統完成風險預警、反洗錢、反欺詐等應用場景的模型訓練、發布、生命周期管理，顯著提升預測準確率、召回率；

應用Lava數據服務套件，將數據資產、AI模型發布為數據與AI Rest API服務實現上層共享。

業務收益復盤

在偶數科技的方案成功實施之后，該行獲得了以下方面的業務收益：

Oushu Lava實現上層應用敏捷開發、數據資產價值最大化，使得數據及時賦能業務，提升用戶體驗 、提高業務部門效率；

OushuDB實現了傳統數據倉庫所無法處理的海量數據、且系統遷移時間短；其在秒級時間內給出交互式分析結果，為業務人員針對重點問題及時決策分析提供了強有力的工具保障；

LittleBoy自動化機器學習系統提供的模型預測增強了全行風險管控能力、智能獲客能力。

4.2保險行業案例

企業概況

某保險公司屬國家大型金融保險企業。2018年，該保險公司的集團公司合并營業收入7684億元；合并保費收入6463億元；合并總資產近4萬億元。

該保險公司已連續17年入選《財富》世界500強企業，排名由2003年的290位躍升為2019年的51位；連續12年入選世界品牌500強。該保險公司所屬股份有限公司繼2003年12月在紐約、香港兩地同步上市之后，又于2007年1月回歸境內A股市場，成為全球第一家在紐約、香港和上海三地上市的保險公司。

目前，集團公司下設8家一級子公司、1家全國性股份制銀行，業務范圍全面涵蓋壽險、財險、企業和職業年金、銀行、基金、資產管理、財富管理、實業投資、海外業務等多個領域多家公司和機構；2016年開啟保險、投資、銀行三大板塊協同發展新格局。

近年來，該保險公司堅持高質量發展，扎實推進保險主業價值和規模協調發展，努力提升投資板塊貢獻，積極做好銀行金融服務，有序開展綜合化經營、科技化創新、國際化布局，全面推進國際一流金融保險集團建設。

數字化愿景與整體目標

該保險公司在戰略層面，確立數字化轉型的“四大行動”：客戶體驗數字化、運營管理數字化、商業模式數字化和全面夯實數字化基礎平臺。

該保險公司通過科技化創新，持續深化業務與科技融合、數據融合、平臺融合、線上線下融合、科研融合、生態融合，不斷提升科技創新能力和賦能水平，提供企業級數據資產管理平臺，統一數據標準，通過數據標準體系與數據指標系統建設，統一數據指標口徑，統一數據服務，實現數字化平臺、智能服務與運營服務。

應用場景梳理

該保險公司現有包括綜合業務處理系統、個人渠道銷售人員管理信息系統、團體銷售人員管理信息系統、中介代理短險銷售系統、客戶主數據管理系統等幾十個業務應用及分析系統。

數字化現狀梳理

該保險公司已建設傳統數據倉庫來推動數字化轉型，其基本現狀如下：

幾十個SQL Server、Oracle傳統數據倉庫，累計近PB級數據，上萬張表、幾千個ETL作業任務，集團大數據在快速增長；

數據龐雜而分散，前臺和后臺、內部與外部、全景匯聚數據、結構化與非結構化的數據，分散在不同大數據平臺來分別進行加工處理；

面向少數應用系統使用規則引擎、傳統機器學習算法實現人工智能預測，但是無法實現對模型的敏捷開發，上層各應系統無法便捷獲取模型/數據服務。

數字化需求分析

該保險公司現有的數據基礎設施存在大量痛點，難以支撐數字化轉型的進一步推進：

集團與各省分公司業務指標一致性不理想，急需建立統一的數據模型與數據標準，提高數據一致性；

公司系統的數據質量問題，而數據差錯的溯源比較困難；急需建立數據治理的閉環和數據質量體系；

數據孤島依然存在，沒有沉淀為全集團共享的統一的數據資產；

無法快速賦能各省業務應用創新；對于某個業務創新的需求，從分析數據，匯集數據，建立AI模型，完成自動打標簽，直至生成報表整個過程需要的周期太長，效率低下。

數字化技術方案設計與實現

偶數科技為了幫助該保險公司應對數字化中存在的痛點，從數據戰略、云數據平臺整體架構、數據治理、數據資產、數據標準、元數據管理等方面上為此保險公司完成詳細的規劃設計和實施方案：

圖25：某保險公司方案

數據來源：偶數科技

應用Ouhshu Lava，以OushuDB高性能分析型云數據庫替代SQL Server、Oracle傳統數據倉庫，現有近百個節點可以支持PB級數據、可動態擴容，滿足未來數據高速增長需求，且跑批性能是之前傳統數據倉庫的數倍；

應用Lava數據治理工具數據治理，完成數據標準管理、元數據管理、數據資產管理；

應用Lava標簽和指標管理套件，完成標簽和指標體系的可視化定義、建模、自動化打標簽、標簽展示、上線、權限管理、訪問監控、統計分析、全生命周期管理；

應用Lava數據服務模塊，將數據資產、AI模型發布為數據與AI Rest API服務實現上層共享。

業務收益復盤

在偶數科技的方案成功實施之后，該保險公司獲得了以下業務收益：

Oushu Lava實現數據指標一致性管理、數據質量管理、標簽和指標體系管理、數據資產價值最大化，為降本增效、實現精細化管理、賦能保險業務等起到重要支撐作用

OushuDB實現了傳統數據倉庫SQL Server、Oracle所無法處理的海量數據、且跑批任務所用時間大幅縮短近50%；并同時支持在秒級時間內為業務人員提供交互式即席分析結果。

4.3電信行業案例

企業概況

某國內電信運營商在國內31個省（自治區、直轄市）和境外多個國家和地區設有分支機構，并在香港、北美、歐洲、日本和新加坡設有境外運營公司，是中國唯一一家在紐約、香港、上海三地同時上市的電信運營企業，連續多年入選“世界500強企業”。

該電信運營商提供電話業務、互聯網接入及應用、數據通信、視訊服務、國際及港澳臺通信等多種類業務，能夠滿足國際、國內客戶的各種通信需求，主要經營GSM、WCDMA和FDD-LTE制式移動網絡業務，固定通信業務，國內、國際通信設施服務業務，衛星國際專線業務、數據通信業務、網絡接入業務和各類電信增值業務，與通信信息業務相關的系統集成業務等。

該電信運營商在英國《銀行家》雜志“2019年全球銀行1000強”榜單上，按一級資本位列第107位、按總資產位列第98位。

數字化愿景與整體目標

近年來，該電信運營商實施聚焦創新合作戰略，開展“一型兩化”布局，聚焦非傳統鏈接、平臺型、應用集成型創新領域，快速提升自主研發、自主集成、自主運營、自主維護能力。

該電信運營商通過云數據平臺建設實現“1+2”大數據管理模式，即“數據運營方+管理方+審計方”，在加強數據隱私保護的基礎上，增強大數據數據資產價值及業務創新應用，擴展運營商大數據在客戶畫像、智能推薦等人工智能應用領域的深入發展。

應用場景梳理

該電信運營商現有包括話務流量分析系統、通訊費用管理系統、銀行對賬系統、綜合維修系統、客戶服務管理系統、反電信詐騙系統、客戶畫像系統等幾十個基于全集團數據分析的應用。

數字化現狀梳理

該電信運營商已建設大數據智能平臺來推動數字化轉型，其基本現狀如下：

現有大數據平臺基于Hadoop Hive 集群近2000個節點，存儲全國幾十PB級數據，上萬張表、上萬個ETL作業任務，全集團大數據隨著5G的發展增長迅猛，日均數據增長量幾百TB；

Hadoop Hive通過讀取大量文本文件每日多次定時從源系統批量獲取源端導出的數據；Hive集群每天幾乎不間斷的基于PB級數據為幾十個應用分析系統的上萬個作業任務進行跑批運算分析，目前一般在T+3得到跑批結果，隨著數據量的增加，跑批時間在不斷延長；業務部門基于大數據分析的即席分析時間長達數分鐘；

大數據平臺中的數據資產尚未實現服務化管理為業務人員其他應用系統提供數據服務；

只有少數場景使用規則引擎和傳統機器學習算法實現人工智能預測。

數字化需求分析

該電信運營商現有的數據基礎設施存在大量痛點，難以支撐數字化轉型的進一步推進：

各業務部門需要在T+1完成跑批結果，同時希望進一步擴大跑批所分析的數據量--從現在的PB級到十PB級以上；

業務部門需要基于大數據分析秒級獲取查詢即席分析結果，但是目前即席分析時間長達數分鐘；

缺少數據治理系統工具及完備的數據標準，沒有沉淀為統一的數據資產；

規則引擎預測準確率比較低、新模型開發周期長，缺少自動化機器學習模型預測系統和自動打標簽系統。

數字化技術方案設計與實現

偶數科技為了幫助該電信公司應對數字化中存在的痛點，從數據戰略、云數據平臺整體架構、數據倉庫及維度模型建設、數據治理和數據標準建設、自動化機器學習平臺建設、標簽和指標平臺建設等方面，分別為集團本部及省分機構完成詳細的規劃設計和實施方案：

圖26：某電信運營商方案

數據來源：偶數科技

應用Oushu Lava，以基于HDFS與Hive共享數據的OushuDB高性能云數據倉庫替代Hive 引擎，基于同樣的PB級數據和僅一半服務器節點數（幾百個節點），跑批性能較Hive提升幾十倍，復雜即席查詢分析可在秒級完成；

應用Lava數據治理套件實現數據治理，完成數據標準管理、數據資產管理，與AI Rest API服務實現上層共享；

應用LittleBoy自動化機器學習系統深度學習算法自動化完成關于客戶畫像、電信反欺詐等應用場景的模型訓練、發布、生命周期管理，顯著提升預測準確率、召回率；

應用Lava標簽和指標管理系統，便捷實現標簽定義、標簽引擎計算、自動打標簽、標簽展示 、標簽統計等。

業務收益復盤

在偶數科技的方案成功實施之后，該電信運營商獲得了以下業務收益：

OushuDB對比原有Hive數據分析實現了幾十倍的性能提升，可以滿足業務部門T+1獲得跑批結果的及秒級獲得即席查詢結果的需求，為業務人員針對重點問題及時決策分析提供了強有力的工具保障；

LittleBoy自動化機器學習系統提供的模型預測增強了集團客戶畫像、客戶挖潛的能力；

Oushu Lava實現數據治理、數據資產管理和數據服務化全生命周期管理，實現數據價值最大化，使得數據及時賦能業務部門和數據科學家團隊，提高了業務部門基于集團大數據開發智能推薦的效益。

審核編輯 ：李倩