剛剛過去的21世紀的第二個十年，是消費網際網路蓬勃發展的十年，也是雲端計算、大資料、人工智慧等新一代資訊科技，即“數字化技術”快速崛起的十年。

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

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

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

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

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

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

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

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

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

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

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

目錄

1. 資料基礎設施支撐企業數字化轉型

2. 企業數字化深入推進，雲資料平臺價值顯現

3. 以雲資料平臺為中心的企業數字化落地方法論

4. 典型行業實踐案例

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

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

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

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為核心的技術體系的影響，克服了其在效能最佳化和併發等方面的缺陷，對雲平臺進行了原生最佳化，尤其是在分析型雲資料倉儲方面，可以支援計算與儲存分離，彈性可擴充套件，支援數千節點規模叢集，虛擬計算叢集，湖倉一體，並對效能做了深度最佳化，從而大幅度提升面向多張表、批次資料、複雜表關聯的複雜查詢效能。

2.   企業數字化深入推進，雲資料平臺價值顯現

儘管資料基礎設施經歷了漫長的演進歷程，但從資料庫、資料倉儲到大資料平臺階段，資料基礎設施在擴充套件能力、彈效能力、查詢效能、易遷移性等方面，始終受到技術路線繁雜、遺留問題重重的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從上億個模型中自動挑選出最佳化的模型，讓使用者在不瞭解演算法原理的情況下自動選出最優配置，提升業務效率。

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

3.   以雲資料平臺為中心的企業數字化落地方法論

正如章節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模型進行持續迭代與最佳化；

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

4.   典型行業實踐案例

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實現資料治理、資料資產管理和資料服務化全生命週期管理，實現資料價值最大化，使得資料及時賦能業務部門和資料科學家團隊，提高了業務部門基於集團大資料開發智慧推薦的效益。

報告編委

報告執筆

黃勇  愛分析  合夥人&首席分析師

馮偉  愛分析  分析師