愛分析報告丨數(shù)字化轉(zhuǎn)型時代的企業(yè)數(shù)據(jù)新基建
內(nèi)容來源：愛分析
作者：黃勇 、馮偉
微信公眾號后臺回復(fù)： 新基建，獲取報告 PDF
前言
剛剛過去的21世紀(jì)的第二個十年，是消費互聯(lián)網(wǎng)蓬勃發(fā)展的十年，也是云計算、大數(shù)據(jù)、人工智能等新一代信息技術(shù)，即“數(shù)字化技術(shù)”快速崛起的十年。
在這一時期，以信息服務(wù)為主的消費互聯(lián)網(wǎng)行業(yè)，如電商、互聯(lián)網(wǎng)金融、社交娛樂等，充分享受了數(shù)字化技術(shù)帶來的“數(shù)字化紅利”，極大推動了其終端用戶的消費行為與體驗的數(shù)字化轉(zhuǎn)型。
但相比于消費互聯(lián)網(wǎng)行業(yè)在數(shù)字經(jīng)濟(jì)浪潮下的蓬勃發(fā)展，以傳統(tǒng)線下服務(wù)、實體商品制造為主的傳統(tǒng)行業(yè)逐漸顯得落寞。在國際局勢不明朗、國內(nèi)市場紅利逐步耗盡、存量競爭日益明顯、人才成本日益高企、產(chǎn)業(yè)升級換代壓力增大的當(dāng)下，傳統(tǒng)行業(yè)的經(jīng)營與效益上正面臨三十年未有之變局，在新興的數(shù)字化業(yè)態(tài)沖擊下，還同時面臨著客群與市場相對萎縮的困局。
因此，投資數(shù)字化技術(shù)，充分接納技術(shù)帶來的變革，推動企業(yè)數(shù)字化轉(zhuǎn)型，從而實現(xiàn)經(jīng)營策略由粗放式向精細(xì)化的轉(zhuǎn)變，對抗經(jīng)濟(jì)周期帶來的下行壓力，將成為傳統(tǒng)企業(yè)的必然抉擇。
根據(jù)華為&牛津經(jīng)濟(jì)研究院報告顯示，自2000年以來，金融、制造、ICT服務(wù)、交通、公用事業(yè)、房地產(chǎn)、農(nóng)業(yè)等傳統(tǒng)行業(yè)的數(shù)字化技術(shù)投資的年復(fù)合增長率，明顯超越以消費互聯(lián)網(wǎng)為代表的數(shù)字化技術(shù)制造業(yè)。
圖1：各行業(yè)的數(shù)字投資增長
該報告還表明，過去三十年中，數(shù)字化技術(shù)投資每增加1美元，便可撬動GDP增加20美元，而1美元的非技術(shù)投資僅能推動GDP增加3美元，數(shù)字化技術(shù)投資的平均回報是非數(shù)字化技術(shù)投資的6.7倍。這也說明，驅(qū)動傳統(tǒng)行業(yè)的數(shù)字化技術(shù)投資的動力來源，本質(zhì)上是企業(yè)對效益提升的追求。
在數(shù)字化技術(shù)中，數(shù)據(jù)庫、數(shù)據(jù)倉庫、大數(shù)據(jù)平臺和云數(shù)據(jù)平臺等基礎(chǔ)軟件，構(gòu)成了企業(yè)數(shù)字化轉(zhuǎn)型的重要基礎(chǔ)設(shè)施，即“數(shù)據(jù)基礎(chǔ)設(shè)施”。隨著各行業(yè)的數(shù)字化場景的發(fā)展，新的業(yè)務(wù)挑戰(zhàn)對“數(shù)據(jù)基礎(chǔ)設(shè)施”的技術(shù)路線演進(jìn)產(chǎn)生了極大的推動作用。
但是，迄今為止的數(shù)據(jù)基礎(chǔ)設(shè)施發(fā)展，仍然難以徹底解決以集團(tuán)型、多分支-企業(yè)為代表的大中型企業(yè)數(shù)字化轉(zhuǎn)型的痛點。
比如，銀行、保險等金融機構(gòu)普遍采用夜間“跑批”的方式對當(dāng)日交易數(shù)據(jù)進(jìn)行ETL處理，從而將數(shù)據(jù)匯總到數(shù)據(jù)倉庫、數(shù)據(jù)集市中，供用戶進(jìn)行報表分析與即席查詢，但數(shù)據(jù)基礎(chǔ)設(shè)施底層的復(fù)雜查詢性能，成為“跑批”結(jié)果時效性的主要瓶頸，這也影響了用戶進(jìn)行決策的頻次和時效性。
再如，電力、電信等關(guān)乎國計民生、用戶數(shù)量巨大、IT基礎(chǔ)設(shè)施復(fù)雜的行業(yè)，普遍面臨的挑戰(zhàn)是數(shù)據(jù)規(guī)模及其龐大，而數(shù)字化應(yīng)用的計算與存儲需求也及其巨大。為了提升工作負(fù)載能力，多集群的數(shù)據(jù)基礎(chǔ)設(shè)施已經(jīng)成為行業(yè)普遍現(xiàn)狀。由此，盡管交易型數(shù)據(jù)庫的“數(shù)據(jù)孤島”得到了一定程度的治理，但在數(shù)據(jù)基礎(chǔ)設(shè)施內(nèi)部，卻因為多集群間的數(shù)據(jù)共享難題，產(chǎn)生了新的“數(shù)據(jù)孤島”。
由此可見，數(shù)據(jù)基礎(chǔ)設(shè)施的技術(shù)架構(gòu)、功能與性能特點的不斷演進(jìn)和發(fā)展，仍具備無限的想象空間。以“云數(shù)據(jù)平臺”為代表的新一代數(shù)據(jù)基礎(chǔ)設(shè)施，正逐漸成為集團(tuán)型、多分支企業(yè)推進(jìn)整體數(shù)字化轉(zhuǎn)型的最佳選擇。
01
數(shù)據(jù)基礎(chǔ)設(shè)施支撐企業(yè)數(shù)字化轉(zhuǎn)型
在宏觀經(jīng)濟(jì)走向中低速增長的今天，“重資產(chǎn)、薄利潤、現(xiàn)金流短缺”等經(jīng)營現(xiàn)狀，愈發(fā)困擾著傳統(tǒng)企業(yè)，產(chǎn)業(yè)升級任重而道遠(yuǎn)。
相比于從誕生第一天起就帶有濃重“數(shù)字化基因”互聯(lián)網(wǎng)企業(yè)，許多傳統(tǒng)企業(yè)對數(shù)字化技術(shù)的應(yīng)用還處在摸索階段。但是，中國經(jīng)濟(jì)已經(jīng)開始邁入“數(shù)字經(jīng)濟(jì)”的新階段，快速涌現(xiàn)和崛起的數(shù)字原生企業(yè)，以及數(shù)字化技術(shù)帶來的競爭優(yōu)勢，意味著傳統(tǒng)企業(yè)如果不快速接納數(shù)字化技術(shù)帶來的變革，那么將必然無法維持原有競爭優(yōu)勢。
因此，通過積極接納數(shù)字化技術(shù)，重塑業(yè)務(wù)流程，拓展業(yè)務(wù)邊界，將成為傳統(tǒng)企業(yè)實現(xiàn)可持續(xù)發(fā)展的必然選擇。
1.1 企業(yè)數(shù)字化的戰(zhàn)略規(guī)劃
國務(wù)院發(fā)展研究中心課題組發(fā)布的《傳統(tǒng)產(chǎn)業(yè)數(shù)字化轉(zhuǎn)型的模式和路徑》對產(chǎn)業(yè)數(shù)字化進(jìn)行了定義：利用新一代信息技術(shù)，構(gòu)建數(shù)據(jù)的采集、傳輸、存儲、處理和反饋的閉環(huán)，打通不同層級與不同行業(yè)間的數(shù)據(jù)壁壘，提高行業(yè)整體的運行效率，構(gòu)建全新的數(shù)字經(jīng)濟(jì)體系。
在這一基礎(chǔ)之上，愛分析認(rèn)為，企業(yè)的數(shù)字化轉(zhuǎn)型，則是指企業(yè)依托于數(shù)字化技術(shù)（即“新一代信息技術(shù)”），構(gòu)建與數(shù)字化技術(shù)相適應(yīng)的戰(zhàn)略規(guī)劃、人才能力、組織架構(gòu)、運營方法，推動業(yè)務(wù)及運營模式的不斷變革與敏捷創(chuàng)新，從而幫助客戶創(chuàng)造更大價值，實現(xiàn)業(yè)績增長與運營效率提升。
相比于傳統(tǒng)企業(yè)，數(shù)字化企業(yè)具備四大基本特征：以客戶為中心、以數(shù)據(jù)價值為基礎(chǔ)、以AI能力為引領(lǐng)、以敏捷能力與驅(qū)動型IT組織為支撐。
由此可見，企業(yè)數(shù)字化轉(zhuǎn)型是一項系統(tǒng)性、全員性工程，絕非能夠一蹴而就。傳統(tǒng)企業(yè)的數(shù)字化轉(zhuǎn)型項目，普遍存在“成本高、周期長、難度大”等問題，這使得傳統(tǒng)企業(yè)的數(shù)字化轉(zhuǎn)型步伐顯得遲緩且保守。
為了降低數(shù)字化轉(zhuǎn)型項目的失敗風(fēng)險，降低試錯成本，提升項目整體效益，進(jìn)行自頂向下的戰(zhàn)略規(guī)劃顯得至關(guān)重要。根據(jù)先進(jìn)企業(yè)的數(shù)字化實踐經(jīng)驗來看，成功的企業(yè)數(shù)字化戰(zhàn)略，至少應(yīng)當(dāng)包括數(shù)字化戰(zhàn)略、數(shù)字化場景、數(shù)字化技術(shù)與數(shù)字化組織等四個層次。
圖2：企業(yè)數(shù)字化的戰(zhàn)略規(guī)劃
數(shù)字化戰(zhàn)略：企業(yè)數(shù)字化戰(zhàn)略具備系統(tǒng)性特征，是“一把手工程”，責(zé)任首先在于企業(yè)高層，成功的關(guān)鍵也在于企業(yè)高層觀念與理念的轉(zhuǎn)變。因此企業(yè)首先需要進(jìn)行戰(zhàn)略目標(biāo)的設(shè)定，從而充分調(diào)動全企業(yè)、各部門的資源，對業(yè)務(wù)場景、組織架構(gòu)、數(shù)據(jù)基礎(chǔ)設(shè)施進(jìn)行整體規(guī)劃，并對實施流程進(jìn)行整體把控。
數(shù)字化場景：數(shù)字化戰(zhàn)略的核心價值在于賦能業(yè)務(wù)場景，缺乏落地場景的數(shù)字化戰(zhàn)略只是“空中樓閣”。因此，企業(yè)應(yīng)當(dāng)在具體業(yè)務(wù)場景中衡量數(shù)字化的真實價值，這就需要企業(yè)全面梳理業(yè)務(wù)場景，并對各場景的業(yè)務(wù)需求、現(xiàn)有條件、預(yù)估投入、波及范圍和預(yù)期業(yè)務(wù)收益進(jìn)行全面評估，保證數(shù)字化轉(zhuǎn)型的目標(biāo)與收益相對明確、實施過程與影響相對可控。
數(shù)字化技術(shù)：數(shù)字化技術(shù)主要指為企業(yè)數(shù)字化戰(zhàn)略提供技術(shù)支撐的云、數(shù)據(jù)、AI等技術(shù)能力。其中，數(shù)據(jù)能力主要指企業(yè)基于數(shù)據(jù)分析來支撐業(yè)務(wù)決策的能力，其在基礎(chǔ)軟件層面的具體載體是“數(shù)據(jù)基礎(chǔ)設(shè)施”。
數(shù)字化組織：數(shù)字化戰(zhàn)略的內(nèi)在要求是對數(shù)字化組織架構(gòu)的打造。為了深度應(yīng)用各類數(shù)字化技術(shù)，企業(yè)需要推動數(shù)字化人才的引進(jìn)和培養(yǎng)，比如數(shù)據(jù)分析師、數(shù)據(jù)科學(xué)家、算法工程師等專業(yè)性技術(shù)人才，以及具備數(shù)字化意識的業(yè)務(wù)人才和管理人才。在人才基礎(chǔ)上，企業(yè)需要進(jìn)一步搭建最大化人才價值的數(shù)字化團(tuán)隊。在文化層面，企業(yè)需要通過一系列的規(guī)范標(biāo)準(zhǔn)、制度安排、激勵措施，推動“以數(shù)據(jù)發(fā)現(xiàn)問題所在、以數(shù)據(jù)分析問題成因、以數(shù)據(jù)預(yù)測發(fā)展趨勢、以數(shù)據(jù)推動業(yè)務(wù)變革”成為全企業(yè)、各部門的集體共識，將數(shù)據(jù)文化內(nèi)化為企業(yè)文化的一部分。
1.2 數(shù)據(jù)基礎(chǔ)設(shè)施的定義
愛分析認(rèn)為，數(shù)據(jù)基礎(chǔ)設(shè)施是一套建立在過往的交易數(shù)據(jù)基礎(chǔ)之上，并結(jié)合一定的技術(shù)手段與業(yè)務(wù)流程，為業(yè)務(wù)場景提供數(shù)據(jù)服務(wù)，實現(xiàn)數(shù)據(jù)價值變現(xiàn)的生態(tài)體系。數(shù)據(jù)基礎(chǔ)設(shè)施的建設(shè)方式、建設(shè)質(zhì)量直接決定了數(shù)字化團(tuán)隊的協(xié)作方式與工作效果，也進(jìn)一步影響了整個企業(yè)數(shù)字化戰(zhàn)略的最終效果。
一般來講，數(shù)據(jù)基礎(chǔ)設(shè)施包括數(shù)據(jù)體系、技術(shù)體系、運營體系、服務(wù)體系等四個部分。
圖3：數(shù)據(jù)基礎(chǔ)設(shè)施架構(gòu)
數(shù)據(jù)體系：包含了企業(yè)內(nèi)可利用數(shù)據(jù)的組織方式，包括源系統(tǒng)的交易數(shù)據(jù)，各類非結(jié)構(gòu)化、半結(jié)構(gòu)化、二進(jìn)制數(shù)據(jù)，以及結(jié)構(gòu)化數(shù)據(jù)的數(shù)據(jù)分層關(guān)系、數(shù)據(jù)模型、數(shù)據(jù)表結(jié)構(gòu)、視圖關(guān)系、字段名稱、數(shù)據(jù)容量、數(shù)據(jù)權(quán)限分配等。
技術(shù)體系：包含了一系列數(shù)據(jù)相關(guān)的技術(shù)產(chǎn)品，如交易型數(shù)據(jù)庫、數(shù)據(jù)接入工具（數(shù)據(jù)同步/消息中間件）、分析型數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫、數(shù)據(jù)開發(fā)工具、AI算法開發(fā)工具等，以及不同產(chǎn)品之間的協(xié)同關(guān)系與業(yè)務(wù)流程。
運營體系：通過數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)資產(chǎn)目錄、數(shù)據(jù)服務(wù)培訓(xùn)與推廣、平臺操作流程與規(guī)范等，搭建數(shù)據(jù)的資產(chǎn)化管理與運營體系，從而為服務(wù)體系提供穩(wěn)定的運營支撐，并保證數(shù)據(jù)基礎(chǔ)設(shè)施與組織架構(gòu)之間的協(xié)同效率。
在需求層面，數(shù)據(jù)已經(jīng)成為金融機構(gòu)的戰(zhàn)略資產(chǎn)，數(shù)據(jù)的準(zhǔn)確性、完整性、一致性等數(shù)據(jù)質(zhì)量指標(biāo)對金融機構(gòu)至關(guān)重要。在政策層面，銀監(jiān)會、人民銀行、外管局等監(jiān)管機構(gòu)對商業(yè)銀行等金融機構(gòu)的數(shù)據(jù)良好標(biāo)準(zhǔn)、數(shù)據(jù)一致性、完整性等數(shù)據(jù)質(zhì)量指標(biāo)的要求也日趨嚴(yán)格。比如，銀保監(jiān)會于2018年5月21日正式發(fā)布《銀行業(yè)金融機構(gòu)數(shù)據(jù)治理指引的通知》（銀保監(jiān)發(fā)【2018】22號），對銀行數(shù)據(jù)治理體系建設(shè)提出了規(guī)范要求，并將數(shù)據(jù)治理與監(jiān)管評級掛鉤，將銀行業(yè)金融機構(gòu)開展數(shù)據(jù)治理工作的重要性提高到了戰(zhàn)略高度。但是，當(dāng)前許多金融機構(gòu)仍然普遍存在“缺少數(shù)據(jù)治理體系、數(shù)據(jù)質(zhì)量較差、數(shù)據(jù)應(yīng)用難以有效開展”等問題，與滿足監(jiān)管的基本要求還有較大距離，也難以滿足日益增長的數(shù)據(jù)應(yīng)用需求。因此，構(gòu)建完善的數(shù)據(jù)運營體系，加強數(shù)據(jù)治理、提升數(shù)據(jù)質(zhì)量、發(fā)揮數(shù)據(jù)資產(chǎn)價值、支持業(yè)務(wù)創(chuàng)新和精細(xì)化管理的必要性和緊迫性日益凸顯。
服務(wù)體系：是數(shù)據(jù)與業(yè)務(wù)結(jié)合的關(guān)鍵環(huán)節(jié)，主要以可視化大屏、固定報表、自助式報表、數(shù)據(jù)API服務(wù)、數(shù)據(jù)應(yīng)用等數(shù)據(jù)服務(wù)形態(tài)，以便捷的方式為業(yè)務(wù)部門提供數(shù)據(jù)服務(wù)，實現(xiàn)數(shù)據(jù)變現(xiàn)。
1.3 數(shù)據(jù)基礎(chǔ)設(shè)施的演進(jìn)歷程
作為企業(yè)數(shù)字化轉(zhuǎn)型的核心支撐，數(shù)據(jù)基礎(chǔ)設(shè)施的技術(shù)架構(gòu)特點，決定了其支撐數(shù)字化團(tuán)隊與數(shù)字化場景的能力上限。
根據(jù)業(yè)務(wù)場景、組織架構(gòu)、技術(shù)架構(gòu)、功能特點、性能特點的差異，數(shù)據(jù)基礎(chǔ)設(shè)施的演進(jìn)歷程，已經(jīng)經(jīng)歷了數(shù)據(jù)庫、數(shù)據(jù)倉庫、大數(shù)據(jù)平臺三個完整階段。目前，數(shù)據(jù)基礎(chǔ)設(shè)施正在邁向前三個階段之后的第四個階段，即“云數(shù)據(jù)平臺”階段。而在這一演進(jìn)過程中， 還出現(xiàn)了像“數(shù)據(jù)中臺”這樣的階段性概念。
圖4：數(shù)據(jù)基礎(chǔ)設(shè)施的演進(jìn)歷程
1.3.1 數(shù)據(jù)庫階段
數(shù)據(jù)庫是數(shù)據(jù)基礎(chǔ)設(shè)施的萌芽階段，而最早的商用數(shù)據(jù)庫產(chǎn)品，如Oracle、DB2，均誕生于1970年代末到1980年代初。
早期的數(shù)據(jù)庫應(yīng)用于以O(shè)LTP（聯(lián)機事務(wù)處理）場景為主，即直接承載來自業(yè)務(wù)系統(tǒng)、交易系統(tǒng)的數(shù)據(jù)存儲與計算，因此這類數(shù)據(jù)庫又被稱之為“事務(wù)型數(shù)據(jù)庫”或“交易型數(shù)據(jù)庫”。在許多情況下，人們也將它等同于狹義的數(shù)據(jù)庫。
業(yè)務(wù)場景
該階段的企業(yè)缺乏成熟、可落地、面向一線業(yè)務(wù)人員的數(shù)字化場景，核心痛點是為企業(yè)管理層解決宏觀層面的經(jīng)營決策問題。
因此，該階段的數(shù)據(jù)查詢維度、數(shù)字化展現(xiàn)形式都比較單一，主要是基于固定的若干張數(shù)據(jù)表，生成面向管理層的固定報表、可視化大屏等。
組織架構(gòu)
該階段的企業(yè)普遍缺乏專業(yè)的數(shù)字化人才，也缺乏成熟的數(shù)字化組織架構(gòu)與文化，主要由IT人員承擔(dān)面向管理層的數(shù)字化場景的落地。
數(shù)據(jù)基礎(chǔ)設(shè)施的技術(shù)架構(gòu)
該階段的數(shù)據(jù)基礎(chǔ)設(shè)施，尚未完全從業(yè)務(wù)系統(tǒng)的交易數(shù)據(jù)庫中分離出來。對數(shù)據(jù)分析需求，企業(yè)一般基于交易型數(shù)據(jù)庫單獨建設(shè)一套用于分析查詢的歷史數(shù)據(jù)庫，匯集來自不同交易數(shù)據(jù)庫的原始數(shù)據(jù)。在少部分?jǐn)?shù)據(jù)分析場景下，企業(yè)還會直接用交易數(shù)據(jù)庫進(jìn)行支持。
交易型數(shù)據(jù)庫的軟硬件架構(gòu)都采取共享存儲架構(gòu)，即計算節(jié)點能夠訪問到任意的存儲節(jié)點，同時需要基于專有物理硬件，由此保證對性能的良好優(yōu)化。
數(shù)據(jù)基礎(chǔ)設(shè)施的功能及性能特點
功能特點：對各類SQL標(biāo)準(zhǔn)、ACID特性（指數(shù)據(jù)庫事務(wù)的四個屬性，包括原子性、一致性、隔離性、持久性）的支持都相當(dāng)完善，因此帶來了很強的穩(wěn)定性。但是，共享存儲架構(gòu)帶來的缺點是可擴(kuò)展性差，一般只能擴(kuò)展到十幾節(jié)點就會遇到瓶頸。
性能特點：主導(dǎo)第一代數(shù)倉的Oracle、IBM等IT巨頭公司具備深厚的基礎(chǔ)研究和性能優(yōu)化能力，因此在OLTP場景中表現(xiàn)優(yōu)良，但是由于共享存儲架構(gòu)在可擴(kuò)展性方面的不足，使得其在大數(shù)據(jù)分析場景中的性能表現(xiàn)相對一般。
* 典型產(chǎn)品：Oracle、IBM DB2
1.3.2 數(shù)據(jù)倉庫階段
1990年代后，尤其是隨著E.F.Codd于1993年正式提出聯(lián)機分析處理（OLAP）的概念，數(shù)據(jù)基礎(chǔ)設(shè)施開始進(jìn)入“數(shù)據(jù)倉庫”時代。
業(yè)務(wù)場景
該階段的企業(yè)開始具備一定的數(shù)字化意識，數(shù)據(jù)分析的需求開始從管理層下沉到業(yè)務(wù)部門，核心痛點是為一線業(yè)務(wù)人員的解決業(yè)務(wù)決策問題。
由于OLAP的數(shù)據(jù)查詢維度更加復(fù)雜，查詢頻次更高，企業(yè)開始將承載OLAP工作負(fù)載的數(shù)據(jù)庫與業(yè)務(wù)系統(tǒng)的交易數(shù)據(jù)庫進(jìn)行分離，從而避免OLAP對核心交易造成干擾。因此，專用于OLAP的分析型數(shù)據(jù)庫誕生，并逐步從交易型數(shù)據(jù)庫中分離出來，也因此獲得了“數(shù)據(jù)倉庫”這一更加形象的別稱。
該階段的數(shù)字化展現(xiàn)形式，仍然以傳統(tǒng)報表和可視化大屏為主，因此為了支撐業(yè)務(wù)部門的數(shù)據(jù)分析需求，需要具備專業(yè)的數(shù)據(jù)分析人員響應(yīng)需求，并提供技術(shù)支持。
但是，為了滿足業(yè)務(wù)人員需要，企業(yè)需要存儲更多的歷史數(shù)據(jù)，常常需要對數(shù)據(jù)倉庫進(jìn)行擴(kuò)容，而Oracle、DB2等交易型數(shù)據(jù)庫擴(kuò)展性較差，難以滿足擴(kuò)容需求。因此，基于MPP無共享架構(gòu)的數(shù)據(jù)庫逐步進(jìn)入人們視野。
組織架構(gòu)
在組織架構(gòu)層面，該階段的企業(yè)大多仍然由IT部門來支撐數(shù)字化，業(yè)務(wù)部門、IT部門均缺少數(shù)字化人才。因此，其IT組織架構(gòu)盡管能夠支撐一定頻次的業(yè)務(wù)需求，但對于緊迫需求仍然難以充分響應(yīng)。
數(shù)據(jù)基礎(chǔ)設(shè)施的技術(shù)架構(gòu)
數(shù)據(jù)倉庫的軟硬件架構(gòu)經(jīng)歷了較為漫長的發(fā)展歷程。
1980年代，Teradata首次推出了采取MPP無共享存儲架構(gòu)的數(shù)據(jù)庫，其主要特點是基于大規(guī)模并行處理（MPP）架構(gòu)，即在每個計算節(jié)點都有自己獨有的存儲節(jié)點，數(shù)據(jù)并均勻打散到所有節(jié)點存儲，并將多個并行任務(wù)分散到不同的節(jié)點上執(zhí)行。此外，Teradata繼續(xù)采用了類似早期Oracle、DB2等數(shù)據(jù)庫的專有物理硬件。到1990年代之后，MPP數(shù)據(jù)庫被越來越多的應(yīng)用到數(shù)據(jù)倉庫的構(gòu)建之中。
到2006年前后，Greenplum、Vertica等支持x86通用服務(wù)器的MPP數(shù)據(jù)庫出現(xiàn)，降低了數(shù)據(jù)倉庫的建設(shè)和擴(kuò)容成本。
數(shù)據(jù)基礎(chǔ)設(shè)施的功能及性能特點
功能特點：無共享架構(gòu)使得節(jié)點擴(kuò)展變得更加容易，而不再受到共享存儲架構(gòu)的制約，節(jié)點數(shù)量上限一般能達(dá)到數(shù)百個；基于x86通用服務(wù)器的無共享架構(gòu)，降低了擴(kuò)展成本，提升了靈活性；對SQL標(biāo)準(zhǔn)、ACID特性的支持性較好。
性能特點：主導(dǎo)MPP數(shù)倉的Teradata、EMC（收購Greenplum）、惠普（收購Vertica）等公司，在整體實力上同樣較為雄厚，具備較強的基礎(chǔ)研究和性能優(yōu)化能力；無共享和MPP架構(gòu)消除了在大數(shù)據(jù)場景下的性能瓶頸，提升了負(fù)載均衡能力，在大數(shù)據(jù)分析場景中有著超越交易型數(shù)據(jù)庫的性能表現(xiàn)。
典型產(chǎn)品：Teradata、EMC Greenplum、HPE Vertica
1.3.3 大數(shù)據(jù)平臺階段
2005年后，由于互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)的逐步普及，業(yè)務(wù)系統(tǒng)的終端用戶量的爆發(fā)式增長，企業(yè)內(nèi)沉淀的數(shù)據(jù)量同樣呈現(xiàn)爆發(fā)式增長，數(shù)據(jù)基礎(chǔ)設(shè)施開始進(jìn)入“大數(shù)據(jù)平臺”階段。
業(yè)務(wù)場景
在互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)技術(shù)的推動下，金融、電商、社交娛樂等領(lǐng)域的企業(yè)開始越來越多地觸及終端用戶的線上數(shù)據(jù)。這些數(shù)據(jù)具有多樣、多維度、大規(guī)模的特點。
首先，數(shù)據(jù)類型十分多樣，包括結(jié)構(gòu)化數(shù)據(jù)（關(guān)系型數(shù)據(jù)庫中的表）、半結(jié)構(gòu)化數(shù)據(jù)（如CSV、XML、日志、JSON）、非結(jié)構(gòu)化數(shù)據(jù)（電子郵件、文檔）、二進(jìn)制數(shù)據(jù)（圖形、音頻、視頻）等。其次，數(shù)據(jù)維度更多，包含了用戶的各類行為數(shù)據(jù)。此外，存儲的數(shù)據(jù)量也從過去的GB、TB級別，進(jìn)一步提升高PB、EB級別。
該階段的數(shù)字化展現(xiàn)形式更加多樣，除了傳統(tǒng)報表、可視化大屏，具備自助式分析能力的敏捷BI工具逐步普及。這使得在部分場景下，業(yè)務(wù)人員能夠自行進(jìn)行數(shù)據(jù)探索與分析，而不再需要IT人員、數(shù)據(jù)分析師隨時進(jìn)行技術(shù)支持。
但是，MPP數(shù)據(jù)倉庫的擴(kuò)展規(guī)模僅能到數(shù)百節(jié)點，難以進(jìn)一步擴(kuò)容，而且不支持非結(jié)構(gòu)化、半結(jié)構(gòu)化數(shù)據(jù)，逐漸難以滿足企業(yè)需求。在這樣的背景下，以Hadoop為代表的大數(shù)據(jù)技術(shù)逐步成為數(shù)據(jù)基礎(chǔ)設(shè)施的核心技術(shù)之一。
組織架構(gòu)
該階段的企業(yè)，普遍開始擁有具備業(yè)務(wù)理解能力和數(shù)據(jù)分析能力的數(shù)字化人才，但人才往往分散在各業(yè)務(wù)線，或歸并在IT部門，缺乏統(tǒng)一的數(shù)字化組織架構(gòu)，以及對數(shù)字化的整體推動能力。
數(shù)據(jù)基礎(chǔ)設(shè)施的技術(shù)架構(gòu)
以Hadoop為代表的大數(shù)據(jù)技術(shù)為企業(yè)統(tǒng)一采集、存儲與處理各類等多種類型數(shù)據(jù)提供了技術(shù)可能性，“數(shù)據(jù)湖”架構(gòu)的理念也由此誕生，而許多企業(yè)又將“數(shù)據(jù)湖”稱之為“大數(shù)據(jù)平臺”。
基于Hadoop生態(tài)的大數(shù)據(jù)平臺，需要兼容前一階段建設(shè)的MPP數(shù)據(jù)倉庫，同時提供基于SQL-on-Hadoop（如Hive、SparkSQL）的數(shù)據(jù)倉庫，以及包括NoSQL數(shù)據(jù)庫（如HBase）、流處理、批處理、分布式存儲（如HDFS）在內(nèi)的大數(shù)據(jù)套件。
與MPP數(shù)據(jù)倉庫的共享存儲架構(gòu)不同，SQL-on-Hadoop數(shù)據(jù)倉庫基于HDFS等分布式、軟件定義的存儲，在軟件層面實現(xiàn)了存儲節(jié)點與計算節(jié)點的相互獨立，因此可以實現(xiàn)計算、存儲獨立擴(kuò)展。
數(shù)據(jù)基礎(chǔ)設(shè)施的功能及性能特點（僅針對SQL-on-Hadoop數(shù)據(jù)倉庫）
功能特點：由于計算存儲分離架構(gòu)的特點，SQL-on-Hadoop數(shù)倉能夠?qū)崿F(xiàn)計算、存儲分別擴(kuò)展，因此在擴(kuò)展性、在線擴(kuò)容等方面有明顯優(yōu)勢，支持上千節(jié)點的擴(kuò)展規(guī)模；但是，由于HDFS的只讀限制，SQL-on-Hadoop數(shù)倉在對傳統(tǒng)事務(wù)型數(shù)據(jù)庫所具備的SQL標(biāo)準(zhǔn)、ACID特性支持較差，這也使得應(yīng)用從事務(wù)型數(shù)據(jù)庫、MPP數(shù)據(jù)庫向SQL-on-Hadoop數(shù)倉遷移的過程中，存在大量不兼容的問題，即應(yīng)用易遷移性較差。
性能特點：SQL-on-Hadoop數(shù)倉由開源項目、互聯(lián)網(wǎng)公司、初創(chuàng)型公司所主導(dǎo)，生態(tài)相比于前兩代數(shù)倉更加開放，但是由于缺乏針對性能和功能的深度優(yōu)化，在大多企業(yè)客戶中只被應(yīng)用于邊緣場景，一直未達(dá)到能夠全面取代傳統(tǒng)數(shù)倉的要求。
典型產(chǎn)品：Hive、SparkSQL、Cloudera Impala、Facebook Presto
1.3.4 云數(shù)據(jù)平臺階段
2015年后，企業(yè)上云已經(jīng)成為普遍共識，同時企業(yè)各業(yè)務(wù)部門對大數(shù)據(jù)分析的需求更加普遍化、敏捷化、個性化、場景化，數(shù)據(jù)的業(yè)務(wù)價值也由輔助決策轉(zhuǎn)變?yōu)橥苿觿?chuàng)新。在這一背景下，數(shù)據(jù)基礎(chǔ)設(shè)施開始進(jìn)入“云數(shù)據(jù)平臺”階段。
業(yè)務(wù)場景
該階段的企業(yè)，其數(shù)字化場景更加廣泛且普遍，而且產(chǎn)生了大量的跨部門、跨業(yè)務(wù)線，甚至跨分支機構(gòu)、跨組織、跨地域的數(shù)據(jù)共享與聯(lián)動分析。同時，孵化于企業(yè)原有體系內(nèi)，但又需要由數(shù)據(jù)來驅(qū)動迭代優(yōu)化的創(chuàng)新業(yè)務(wù)層出不窮。
因此，企業(yè)數(shù)字化轉(zhuǎn)型思路需要從過去的單個場景突破，轉(zhuǎn)變?yōu)槿瘓F(tuán)、跨組織、跨地域的數(shù)據(jù)共享與資產(chǎn)化管理，以及全場景數(shù)據(jù)賦能。
組織架構(gòu)
為了推動集團(tuán)層面的業(yè)務(wù)、數(shù)據(jù)共享，加速業(yè)務(wù)的敏捷創(chuàng)新，企業(yè)需要在組織架構(gòu)層面對數(shù)字化人才、數(shù)據(jù)基礎(chǔ)設(shè)施的管理和運營團(tuán)隊進(jìn)行統(tǒng)籌規(guī)劃。
比如，以阿里巴巴、騰訊為代表的互聯(lián)網(wǎng)巨頭都先后提出了“中臺戰(zhàn)略”，成立中臺部門對數(shù)字化戰(zhàn)略進(jìn)行統(tǒng)籌。為了推動數(shù)據(jù)的跨部門復(fù)用與共享， “數(shù)據(jù)中臺”的概念也被同時提出。
數(shù)據(jù)基礎(chǔ)設(shè)施的技術(shù)架構(gòu)
然而，“數(shù)據(jù)中臺”概念的局限性在于并未改變數(shù)據(jù)基礎(chǔ)設(shè)施的底層技術(shù)架構(gòu)，而是沿用了大數(shù)據(jù)平臺階段的技術(shù)架構(gòu)，并保留了傳統(tǒng)技術(shù)路線帶來的弊端。
對此，云數(shù)據(jù)平臺采用了計算與存儲分離、虛擬計算集群等新型技術(shù)架構(gòu)，對象存儲等云原生技術(shù)對數(shù)據(jù)平臺進(jìn)行了深度優(yōu)化。
數(shù)據(jù)基礎(chǔ)設(shè)施的功能特點
基于云原生、計算存儲分離、虛擬計算集群等新型技術(shù)架構(gòu)，云數(shù)據(jù)平臺實現(xiàn)計算、存儲節(jié)點獨立擴(kuò)展，突破了基于MPP、SQL-on-Hadoop技術(shù)的大數(shù)據(jù)平臺在擴(kuò)展性、靈活性方面的局限。
此外，云數(shù)據(jù)平臺還克服了SQL-on-Hadoop數(shù)據(jù)庫在SQL標(biāo)準(zhǔn)、ACID特性等方面的不足，可以支持?jǐn)?shù)字化應(yīng)用從傳統(tǒng)共享存儲數(shù)據(jù)倉庫、MPP數(shù)倉向云數(shù)據(jù)平臺的平滑遷移。
最后，大數(shù)據(jù)平臺的基礎(chǔ)上，云數(shù)據(jù)平臺吸納了來自“數(shù)據(jù)中臺”理念的數(shù)據(jù)資產(chǎn)層與數(shù)據(jù)服務(wù)層，從而形成“數(shù)據(jù)平臺-數(shù)據(jù)資產(chǎn)-數(shù)據(jù)服務(wù)”的三層架構(gòu)。
圖5：云數(shù)據(jù)平臺“平臺-資產(chǎn)-服務(wù)”三層架構(gòu)
數(shù)據(jù)基礎(chǔ)設(shè)施的性能特點
相比于大數(shù)據(jù)平臺，云數(shù)據(jù)平臺擺脫了以Hadoop為核心的技術(shù)體系的影響，克服了其在性能優(yōu)化和并發(fā)等方面的缺陷，對云平臺進(jìn)行了原生優(yōu)化，尤其是在分析型云數(shù)據(jù)倉庫方面，可以支持計算與存儲分離，彈性可擴(kuò)展，支持?jǐn)?shù)千節(jié)點規(guī)模集群，虛擬計算集群，湖倉一體，并對性能做了深度優(yōu)化，從而大幅度提升面向多張表、批量數(shù)據(jù)、復(fù)雜表關(guān)聯(lián)的復(fù)雜查詢性能。
02
企業(yè)數(shù)字化深入推進(jìn)，云數(shù)據(jù)平臺價值顯現(xiàn)
盡管數(shù)據(jù)基礎(chǔ)設(shè)施經(jīng)歷了漫長的演進(jìn)歷程，但從數(shù)據(jù)庫、數(shù)據(jù)倉庫到大數(shù)據(jù)平臺階段，數(shù)據(jù)基礎(chǔ)設(shè)施在擴(kuò)展能力、彈性能力、查詢性能、易遷移性等方面，始終受到技術(shù)路線繁雜、遺留問題重重的MPP、SQL-on-Hadoop等上一代數(shù)據(jù)倉庫技術(shù)的制約。
同時，企業(yè)數(shù)字化實踐的主戰(zhàn)場，已經(jīng)從過去的互聯(lián)網(wǎng)、創(chuàng)新型企業(yè)，全面轉(zhuǎn)到以集團(tuán)型、多分支企業(yè)為代表的大中型傳統(tǒng)企業(yè)，數(shù)字化需求的深度、廣度出現(xiàn)全面提升。
然而，時下的“數(shù)據(jù)中臺”解決方案，本質(zhì)上只是在大數(shù)據(jù)平臺的基礎(chǔ)上，融合了數(shù)據(jù)資產(chǎn)化與數(shù)據(jù)服務(wù)化的管理能力，并沒有對大數(shù)據(jù)平臺的原有技術(shù)路線進(jìn)行革命性升級。
因此，數(shù)據(jù)基礎(chǔ)設(shè)施需要對技術(shù)進(jìn)行徹底變革，變得更加統(tǒng)一與強大，而新一代數(shù)據(jù)基礎(chǔ)設(shè)施——“云數(shù)據(jù)平臺”的出現(xiàn)，則預(yù)示著數(shù)據(jù)基礎(chǔ)設(shè)施的未來變革方向。
2.1 四大新挑戰(zhàn)困擾企業(yè)數(shù)字化轉(zhuǎn)型
金融、能源、制造、零售等行業(yè)內(nèi)，存在著許多體量龐大、組織架構(gòu)復(fù)雜的集團(tuán)型、多分支企業(yè)。然而，這類企業(yè)在推進(jìn)數(shù)字化轉(zhuǎn)型過程中，數(shù)字化應(yīng)用逐步表現(xiàn)出了“大規(guī)?！?、“強敏態(tài)”、“高時效”、“智能化”等四大新特征，對數(shù)據(jù)基礎(chǔ)設(shè)施提出了相應(yīng)的四大挑戰(zhàn)，如下圖所示。
圖6：數(shù)據(jù)基礎(chǔ)設(shè)施面臨的四大挑戰(zhàn)
2.1.1 數(shù)據(jù)規(guī)模膨脹，數(shù)據(jù)基礎(chǔ)設(shè)施產(chǎn)生新“數(shù)據(jù)孤島”
金融、電力、電信等行業(yè)內(nèi)企業(yè)，普遍存在業(yè)務(wù)系統(tǒng)眾多、交易次數(shù)巨大、交易額度巨大、數(shù)據(jù)積累量巨大等特征。據(jù)公開數(shù)據(jù)顯示，2019年全國銀行卡交易總次數(shù)為3219.89億筆，日均8.82億筆，交易總金額886.39萬億元，日均2.43萬億元。
因此，企業(yè)內(nèi)的數(shù)字化應(yīng)用對數(shù)據(jù)基礎(chǔ)設(shè)施的計算并發(fā)量、存儲上限的要求越來越高，數(shù)據(jù)基礎(chǔ)設(shè)施的節(jié)點規(guī)模出現(xiàn)了急劇膨脹。比如，某國有大行需要分析數(shù)十PB級交易數(shù)據(jù)，需要3000以上的數(shù)倉節(jié)點才能滿足存儲需求。
圖7：數(shù)據(jù)規(guī)模膨脹對數(shù)據(jù)基礎(chǔ)設(shè)施的挑戰(zhàn)
在這樣的背景下，兩方面因素共同導(dǎo)致了數(shù)據(jù)基礎(chǔ)設(shè)施內(nèi)的“數(shù)據(jù)孤島”產(chǎn)生，進(jìn)一步拉高了企業(yè)的數(shù)據(jù)運維管理成本。
傳統(tǒng)交易型數(shù)據(jù)庫與MPP數(shù)倉的節(jié)點規(guī)模限制
目前，MPP憑借對SQL標(biāo)準(zhǔn)、ACID特性的良好支持，仍然是大型企業(yè)的核心數(shù)字化應(yīng)用的主流選擇。此外，許多企業(yè)還在采用Oracle、DB2等傳統(tǒng)的交易型數(shù)據(jù)庫來支撐數(shù)據(jù)分析業(yè)務(wù)。
面對膨脹的數(shù)字化應(yīng)用規(guī)模，企業(yè)內(nèi)的數(shù)據(jù)基礎(chǔ)設(shè)施一旦達(dá)到可擴(kuò)展的節(jié)點上限，必須采用多集群部署方式，即通過應(yīng)用級的多集群劃分來支撐更多的應(yīng)用帶來的并發(fā)計算，通過多集群間的數(shù)據(jù)分散存儲來支撐更高規(guī)模的數(shù)據(jù)存儲。
但是，傳統(tǒng)交易型數(shù)據(jù)庫、MPP數(shù)據(jù)倉庫的可擴(kuò)展節(jié)點上限僅在十幾到上百節(jié)點，在許多數(shù)字化較為領(lǐng)先的大型企業(yè)內(nèi)，節(jié)點需求已經(jīng)很容易突破上限，因而同時部署多個MPP集群，已經(jīng)成為大型企業(yè)數(shù)字化的必須。
比如，某國有大行需要分析10PB級交易數(shù)據(jù)，需要3000以上的數(shù)倉節(jié)點才能滿足存儲需求，因此只能建立40個MPP集群。但是，多集群間的數(shù)據(jù)共享十分困難，該行只能對部分?jǐn)?shù)據(jù)在多個集群進(jìn)行多份冗余存儲，導(dǎo)致最終的實際數(shù)據(jù)存儲量高達(dá)幾十PB，集群之間數(shù)據(jù)很容易產(chǎn)生不一致，給該行造成了極大的運維負(fù)擔(dān)。
由此可見，盡管數(shù)據(jù)基礎(chǔ)設(shè)施的出現(xiàn)與發(fā)展始終是為了實現(xiàn)數(shù)據(jù)共享利用，消除交易型數(shù)據(jù)庫之間的“數(shù)據(jù)孤島”，但是多集群的現(xiàn)狀，事實上在數(shù)據(jù)基礎(chǔ)設(shè)施內(nèi)部制造了新的“數(shù)據(jù)孤島”。
不同技術(shù)架構(gòu)的數(shù)據(jù)倉庫間的應(yīng)用易移植性問題
與傳統(tǒng)交易型數(shù)據(jù)庫、MPP數(shù)倉不同，Hive、SparkSQL等SQL-on-Hadoop數(shù)倉具備上千節(jié)點規(guī)模的擴(kuò)展能力，但其缺陷在于對SQL標(biāo)準(zhǔn)、ACID特性的支持能力不足，性能比MPP差多倍，并發(fā)支持有限，因此許多大型企業(yè)傾向于將更多地應(yīng)用在邊緣業(yè)務(wù)的數(shù)字化場景中，與MPP數(shù)倉并行使用，共同構(gòu)建數(shù)據(jù)基礎(chǔ)設(shè)施。
然而，傳統(tǒng)交易型數(shù)據(jù)庫、MPP數(shù)倉、SQL-on-Hadoop數(shù)倉在計算存儲架構(gòu)方面的差異，以及在SQL標(biāo)準(zhǔn)、ACID特性上的不兼容，意味著雙方之間的數(shù)據(jù)遷移和共享十分困難。
但是，未來大型企業(yè)的數(shù)字化，往往不再是過去由單個部門、單條業(yè)務(wù)線驅(qū)動的數(shù)字化，而是越來越多地由戰(zhàn)略層面進(jìn)行統(tǒng)籌規(guī)劃，全部門、全業(yè)務(wù)線協(xié)同推進(jìn)的數(shù)字化。在這種背景下，大型企業(yè)常常需要將過去獨立建設(shè)的數(shù)字化應(yīng)用進(jìn)行遷移，以同一套數(shù)據(jù)基礎(chǔ)設(shè)施支撐上層各個業(yè)務(wù)線的數(shù)字化應(yīng)用，不但實現(xiàn)了管理的統(tǒng)一，還可提升其擴(kuò)展能力。
因此，在將遺留的數(shù)字化應(yīng)用在不同技術(shù)架構(gòu)進(jìn)行遷移過程中，往往需要進(jìn)行大量的代碼重構(gòu)，移植成本較高，難以實現(xiàn)平滑遷移。
例如，某電網(wǎng)系統(tǒng)內(nèi)分公司搭建了基于Hive的大數(shù)據(jù)測試環(huán)境，但是擁有更多計算節(jié)點的Hive大數(shù)據(jù)分析性能對比Oracle幾乎沒有提升，且原有基于Oracle的眾多應(yīng)用系統(tǒng)向Hive遷移時，由于Hive不支持存儲過程等Oracle很多功能，需要改寫的代碼量巨大。
因此，大型企業(yè)在數(shù)字化過程中，亟需探索一套通過“大一統(tǒng)”方式來建設(shè)數(shù)據(jù)基礎(chǔ)設(shè)施的解決方案，消除數(shù)據(jù)基礎(chǔ)設(shè)施內(nèi)的“數(shù)據(jù)孤島”現(xiàn)象。
為了應(yīng)對這些挑戰(zhàn)，新一代數(shù)據(jù)基礎(chǔ)設(shè)施——“云數(shù)據(jù)平臺”應(yīng)具備以下能力：
計算存儲分離架構(gòu)，及其帶來的強擴(kuò)展性、強共享性：采取計算、存儲分離的技術(shù)架構(gòu)，支持?jǐn)?shù)千節(jié)點的集群規(guī)模，支持多虛擬計算集群；
強SQL標(biāo)準(zhǔn)支持、ACID特性、Hadoop原生支持（即支持傳統(tǒng)Hadoop生態(tài)系統(tǒng)），及其帶來的強兼容性：具備完善的SQL標(biāo)準(zhǔn)、ACID特性的支持能力，兼容過去采用Oracle、DB2等傳統(tǒng)交易型數(shù)據(jù)庫、MPP數(shù)據(jù)庫的數(shù)字化應(yīng)用，并支持對接訪問HDFS等Hadoop原生組件，從而兼容過去采用SQL-on-Hadoop數(shù)據(jù)庫的數(shù)字化應(yīng)用。
2.1.2 敏態(tài)特征凸顯，數(shù)據(jù)基礎(chǔ)設(shè)施彈性能力受挑戰(zhàn)
早在2014年，Gartner就提出了融合“穩(wěn)態(tài)IT”與“敏態(tài)IT”的“雙模IT”概念。對于傳統(tǒng)行業(yè)內(nèi)的集團(tuán)型、多分支企業(yè)來說，加強“敏態(tài)IT”能力建設(shè)，是推進(jìn)數(shù)字化轉(zhuǎn)型的重要組成部分。
在“敏態(tài)IT”模式下，企業(yè)需要更加關(guān)注業(yè)績增長、品牌營銷與客戶體驗，大幅增強面對不確定場景的響應(yīng)能力，這就要求企業(yè)IT團(tuán)隊在資源獲取、應(yīng)用迭代、系統(tǒng)運維等方面實現(xiàn)敏捷化轉(zhuǎn)型。
比如，國內(nèi)某大型航空公司，為了推進(jìn)全公司的IT敏捷化轉(zhuǎn)型，從團(tuán)隊、工具、方法、實踐等四個層面實踐敏捷理念。在工具層面，該航司依托云計算IaaS平臺，以及基于云數(shù)據(jù)庫、Docker、Kubernetes、AIOps等技術(shù)的PaaS平臺，構(gòu)建了一站式敏捷開發(fā)管理平臺，將過去基于傳統(tǒng)IT環(huán)境的應(yīng)用交付過程遷移到云上，有效提升了產(chǎn)品迭代速度，優(yōu)化了客戶體驗，促進(jìn)了業(yè)績增長。
由此可見，具備按需取用、快速彈性、自動化編排等優(yōu)勢的云計算、云原生技術(shù)，成為支撐“敏態(tài)IT”的新型IT基礎(chǔ)設(shè)施。
這一趨勢對數(shù)據(jù)基礎(chǔ)設(shè)施的影響表現(xiàn)為兩個層次，第一層是傳統(tǒng)業(yè)務(wù)上云帶來的數(shù)據(jù)的上云，第二層是數(shù)字化場景拓展帶來的數(shù)字化應(yīng)用上云。
傳統(tǒng)業(yè)務(wù)與數(shù)據(jù)上云
隨著數(shù)字化轉(zhuǎn)型的深入推進(jìn)，企業(yè)上云從互聯(lián)網(wǎng)企業(yè)逐步滲透到傳統(tǒng)企業(yè)，從創(chuàng)新業(yè)務(wù)、邊緣業(yè)務(wù)逐步滲透到傳統(tǒng)業(yè)務(wù)、核心業(yè)務(wù)。同時，隨著企業(yè)上云的推進(jìn)，全球范圍內(nèi)的數(shù)據(jù)的產(chǎn)生與存儲過程，越來越多地從傳統(tǒng)數(shù)據(jù)中心轉(zhuǎn)移到公共云環(huán)境中。
根據(jù)IDC報告顯示，到2025年，公共云中的數(shù)據(jù)百分比將接近50%。
數(shù)字化應(yīng)用上云
隨著數(shù)字化營銷與銷售、數(shù)字化生產(chǎn)制造、數(shù)字化采購、數(shù)字化協(xié)同辦公等新興數(shù)字化場景不斷出現(xiàn)，企業(yè)IT的“敏態(tài)”特征不斷增強，工作負(fù)載量、負(fù)載量的波動性相比過去都有明顯提升。
因此，數(shù)字化應(yīng)用上云也成為大勢所趨。另一方面，來自傳統(tǒng)業(yè)務(wù)、核心業(yè)務(wù)的交易數(shù)據(jù)的逐步上云，也為數(shù)字化應(yīng)用的上云鋪平了道路。
在這兩大背景之下，為了保證數(shù)字化應(yīng)用的高可用性，數(shù)據(jù)基礎(chǔ)設(shè)施同樣應(yīng)當(dāng)具備“敏態(tài)”特征，滿足資源快速取用、快速啟停的彈性能力。因此，對數(shù)據(jù)基礎(chǔ)設(shè)施進(jìn)行云化改造將成為必然趨勢。
圖9：數(shù)字化應(yīng)用的敏態(tài)化對數(shù)據(jù)基礎(chǔ)設(shè)施的挑戰(zhàn)
但是，數(shù)據(jù)基礎(chǔ)設(shè)施在進(jìn)行云化改造時面臨的兩大挑戰(zhàn)。
首先，共享存儲、MPP無共享、SQL-on-Hadoop等技術(shù)架構(gòu)對云環(huán)境的特性（如彈性能力）、組件（如云存儲）適應(yīng)性不足，存在彈性性能瓶頸，難以充分發(fā)揮云的彈性優(yōu)勢。
其次，共享存儲、MPP無共享等技術(shù)架構(gòu)的計算、存儲節(jié)點深度耦合，無法實現(xiàn)計算、存儲性能的非等量擴(kuò)容，對IT資源的高效利用帶來障礙。
再如，某制造型企業(yè)上線數(shù)字化的排產(chǎn)管理系統(tǒng)后，經(jīng)常會遇到兩種情況：首先，隨著應(yīng)用上線時間推移，數(shù)據(jù)存儲量呈快速的線性增長；其次，在生產(chǎn)高峰期內(nèi)，計算工作負(fù)載往往在短時間內(nèi)會出現(xiàn)波峰，但在生產(chǎn)高峰期結(jié)束后則會迅速恢復(fù)到正常水平。過去，該企業(yè)采用基于MPP架構(gòu)的Greenplum集群，計算、存儲節(jié)點完全耦合，不支持存儲和計算獨立擴(kuò)容。因此，當(dāng)該企業(yè)處于生產(chǎn)高峰期內(nèi)，如果選擇充分滿足計算性能需求，則存儲性能容易造成浪費，但如果選擇有限滿足計算性能需求，則會造成服務(wù)可用性不足。
圖10：計算存儲耦合與計算存儲分離架構(gòu)的對比
因此，企業(yè)數(shù)字化的新階段下，為了應(yīng)對應(yīng)用上云、數(shù)字化應(yīng)用比例增加的趨勢，“云數(shù)據(jù)平臺”應(yīng)具備以下能力：
云原生特性、計算存儲分離架構(gòu)，及其帶來的高彈性：利用云服務(wù)器、分布式存儲等云原生技術(shù)，對數(shù)據(jù)基礎(chǔ)設(shè)施的擴(kuò)展性能進(jìn)行深度優(yōu)化，充分適應(yīng)云上數(shù)字化應(yīng)用對高度彈性、無限擴(kuò)容能力的要求；采取計算、存儲分離的技術(shù)架構(gòu)，充分適應(yīng)數(shù)字化應(yīng)用對計算、存儲分別獨立擴(kuò)展的要求，增強彈性擴(kuò)展的靈活性。
圖11：云數(shù)據(jù)平臺應(yīng)對數(shù)字化應(yīng)用敏態(tài)化挑戰(zhàn)
2.1.3 數(shù)據(jù)時效性要求提升，數(shù)據(jù)基礎(chǔ)設(shè)施查詢性能受限
面對激烈的市場競爭，大型企業(yè)在決策效率方面的劣勢，同樣亟需通過數(shù)字化手段進(jìn)行改變。
在金融、零售等具有強烈營銷導(dǎo)向的行業(yè)內(nèi)，越來越多的企業(yè)決策者和業(yè)務(wù)人員，都期望能夠?qū)崿F(xiàn)T+1、甚至T+0的數(shù)據(jù)反饋，從而基于更有時效性的數(shù)據(jù)進(jìn)行業(yè)務(wù)決策，避免因決策周期過長而導(dǎo)致錯失商機，這意味著大型企業(yè)對數(shù)字化應(yīng)用的時效性要求將持續(xù)提升。
從技術(shù)原理來看，數(shù)字化應(yīng)用的時效性，主要依托于大數(shù)據(jù)平臺所提供的面向批處理、即席查詢等分析型場景（OLAP）的復(fù)雜查詢能力。但是，數(shù)據(jù)量的增長帶來的數(shù)據(jù)處理量的增長，以及基于SQL-on-Hadoop的數(shù)據(jù)基礎(chǔ)設(shè)施在OLAP復(fù)雜查詢場景的性能瓶頸，使得數(shù)字化應(yīng)用的時效性越來越難以得到保證。
圖12：數(shù)據(jù)時效性要求提升對數(shù)據(jù)基礎(chǔ)設(shè)施的挑戰(zhàn)
批處理的性能瓶頸：在批處理模式下，數(shù)據(jù)服務(wù)依托于構(gòu)建好的分層數(shù)據(jù)模型。Hive、SparkSQL、MPP等查詢引擎，對來自O(shè)DS（貼源數(shù)據(jù)層）的數(shù)據(jù)進(jìn)行批量計算，分層將數(shù)據(jù)抽取到DWD（明細(xì)數(shù)據(jù)層）、DWS（聚合數(shù)據(jù)層）、ADS（應(yīng)用數(shù)據(jù)層）/DM（數(shù)據(jù)集市層）中，最后由ADS或DM來為可視化大屏、報表分析、數(shù)據(jù)API等數(shù)據(jù)服務(wù)提供數(shù)據(jù)支撐。因此，批處理性能的瓶頸，將會導(dǎo)致數(shù)據(jù)基礎(chǔ)設(shè)施難以在T+1日內(nèi)完成批處理工作，從而影響數(shù)據(jù)服務(wù)的時效性。
即席查詢的性能瓶頸：在即席查詢模式下，數(shù)據(jù)服務(wù)不依托于數(shù)據(jù)模型，而是由用戶自行定義查詢維度，直接從數(shù)據(jù)庫中進(jìn)行關(guān)聯(lián)查詢。因此，即席查詢性能的瓶頸，將會導(dǎo)致用戶查詢時面臨較高的時間延遲，影響用戶體驗。
例如，某股份制商業(yè)銀行在Oracle、DB2傳統(tǒng)數(shù)據(jù)倉庫上，建設(shè)了管理會計系統(tǒng)、績效考核系統(tǒng)、監(jiān)管報送系統(tǒng)、數(shù)據(jù)集市系統(tǒng)等幾十個大型分析系統(tǒng)，數(shù)據(jù)在PB級以上，但是傳統(tǒng)數(shù)據(jù)倉庫的性能瓶頸造成了兩方面的困擾。一方面，管理會計系統(tǒng)、績效考核系統(tǒng)等分析系統(tǒng)全部無法全部滿足T+1時間需求，嚴(yán)重影響銀行領(lǐng)導(dǎo)的決策分析，以及各分行業(yè)務(wù)部門每日運營工作的安排部署。另一方面，大數(shù)據(jù)分析人員需要在海量歷史數(shù)據(jù)中進(jìn)行即席查詢，但隨著銀行數(shù)據(jù)量快速增加，每運行一條分析SQL都需要10分鐘以上時間。
因此，企業(yè)數(shù)字化的新階段下，為了應(yīng)對數(shù)字化應(yīng)用、數(shù)據(jù)服務(wù)的高時效性要求，“云數(shù)據(jù)平臺”應(yīng)具備以下能力：
高性能并行執(zhí)行能力，及其帶來的強復(fù)雜查詢性能：采取最新的SIMD指令集，實現(xiàn)指令內(nèi)并行技術(shù)，從而實現(xiàn)更高性能的并行執(zhí)行器，從而提供面向PB級大數(shù)據(jù)的，比MPP、SQL-on-Hadoop數(shù)據(jù)倉庫更快的復(fù)雜查詢性能，從而明顯降低批處理、即席查詢所需的時間，提升數(shù)據(jù)服務(wù)的時效性。
圖13：云數(shù)據(jù)平臺應(yīng)對數(shù)據(jù)時效性的挑戰(zhàn)
2.1.4 智能化場景逐步成熟，數(shù)據(jù)基礎(chǔ)設(shè)施AI支持能力不足
近些年來，金融行業(yè)作為數(shù)字化較為領(lǐng)先的行業(yè)，其客戶畫像、信貸信用評分、反欺詐、反洗錢、合規(guī)審計等智能化場景逐步成熟。由此，數(shù)據(jù)的價值逐步由“數(shù)據(jù)驅(qū)動問題發(fā)現(xiàn)”“數(shù)據(jù)驅(qū)動問題分析”走向“數(shù)據(jù)驅(qū)動趨勢預(yù)測”、“數(shù)據(jù)驅(qū)動業(yè)務(wù)決策”，這進(jìn)一步要求數(shù)據(jù)基礎(chǔ)設(shè)施能夠支撐智能化應(yīng)用的快速開發(fā)。
傳統(tǒng)的數(shù)據(jù)倉庫中通常會內(nèi)置In-Database機器學(xué)習(xí)庫，但對于使用者的AI知識水平要求較高，而許多傳統(tǒng)行業(yè)企業(yè)缺乏AI人才，如果選擇從零開始構(gòu)建AI團(tuán)隊、建設(shè)AI平臺，投入成本十分高昂。
圖14：智能化應(yīng)用對數(shù)據(jù)基礎(chǔ)設(shè)施的挑戰(zhàn)
因此，企業(yè)數(shù)字化的新階段下，為了應(yīng)對數(shù)字化應(yīng)用的智能化需求，“云數(shù)據(jù)平臺”應(yīng)具備以下能力：
自動化機器學(xué)習(xí)支持：基于AutoML技術(shù)，允許業(yè)務(wù)人員通過托拉拽、低代碼的方式，實現(xiàn)自動化AI建模；融合云數(shù)據(jù)平臺的數(shù)據(jù)模型，構(gòu)建從業(yè)務(wù)理解、數(shù)據(jù)接入與處理、特征工程、模型選擇、優(yōu)化算法選擇、參數(shù)調(diào)優(yōu)、模型評估、模型部署與發(fā)布、模型優(yōu)化等AI全生命周期管理流程。
2.2 新一代數(shù)據(jù)基礎(chǔ)——云數(shù)據(jù)平臺
為了滿足以集團(tuán)型、多分支企業(yè)為代表的大中型企業(yè)數(shù)字化轉(zhuǎn)型的新挑戰(zhàn)，新一代數(shù)據(jù)基礎(chǔ)設(shè)施應(yīng)當(dāng)通過底層技術(shù)變革，推動技術(shù)能力變革，最終滿足上層業(yè)務(wù)的變化。
為此，愛分析從底層技術(shù)變革、技術(shù)能力變革、業(yè)務(wù)場景變革三個層次，對新一代數(shù)據(jù)基礎(chǔ)設(shè)施“云數(shù)據(jù)平臺”進(jìn)行定義。
2.2.1 云數(shù)據(jù)平臺的定義
愛分析認(rèn)為，“云數(shù)據(jù)平臺”是新一代的數(shù)據(jù)基礎(chǔ)設(shè)施，它能夠依托云原生特性、計算存儲分離架構(gòu)、強ACID特性、強SQL標(biāo)準(zhǔn)支持、Hadoop原生支持、高性能并行執(zhí)行能力等一系列底層技術(shù)的變革，實現(xiàn)高彈性、強擴(kuò)展性、強共享性、強兼容性、強復(fù)雜查詢能力、自動化機器學(xué)習(xí)支持等上層技術(shù)能力的變革，最終幫助企業(yè)有效應(yīng)對大規(guī)模、強敏態(tài)、高時效、智能化等愈發(fā)明顯的數(shù)字化趨勢。
圖15：云數(shù)據(jù)平臺的概念
云原生特性、計算存儲分離架構(gòu)，及其帶來的高彈性：利用云服務(wù)器、分布式存儲等云原生技術(shù)，對數(shù)據(jù)基礎(chǔ)設(shè)施的擴(kuò)展性能進(jìn)行深度優(yōu)化，充分適應(yīng)云上應(yīng)用對高度彈性、無限擴(kuò)容能力的要求，并采取計算存儲分離架構(gòu)，進(jìn)一步提升數(shù)據(jù)基礎(chǔ)設(shè)施的擴(kuò)展靈活性；
計算存儲分離架構(gòu)，及其帶來的強擴(kuò)展性、強共享性：采取計算、存儲分離的技術(shù)架構(gòu)，充分適應(yīng)數(shù)字化應(yīng)用對計算、存儲分別獨立擴(kuò)展的要求，增強了彈性能力，并能夠支持?jǐn)?shù)千節(jié)點的集群規(guī)模，盡可能避免多集群部署，并可低成本地支持跨集群的數(shù)據(jù)共享；
強ACID特性、SQL標(biāo)準(zhǔn)支持、Hadoop原生兼容，及其帶來的強兼容性：具備完善的SQL標(biāo)準(zhǔn)、ACID特性的支持能力，兼容過去采用Oracle、DB2等傳統(tǒng)交易型數(shù)據(jù)庫、MPP數(shù)據(jù)庫的數(shù)字化應(yīng)用，并支持對接訪問Hive、HDFS等Hadoop原生組件，從而兼容過去采用SQL-on-Hadoop數(shù)據(jù)庫的數(shù)字化應(yīng)用，實現(xiàn)數(shù)字化應(yīng)用在數(shù)據(jù)基礎(chǔ)設(shè)施間的平滑遷移；
高性能并行執(zhí)行能力，及其帶來的強復(fù)雜查詢性能：面向PB級大數(shù)據(jù)，具備比MPP、SQL-on-Hadoop數(shù)據(jù)倉庫更快的復(fù)雜查詢性能，從而明顯降低批處理、即席查詢所需的時間，保證數(shù)據(jù)處理能力的高時效；
自動化機器學(xué)習(xí)支持：具備對自動化機器學(xué)習(xí)技術(shù)的支持能力，基于AutoML等技術(shù)，為業(yè)務(wù)人員提供自動化AI建模能力，實現(xiàn)AI模型全生命周期管理，降低AI研發(fā)與管理成本。
數(shù)據(jù)資產(chǎn)管理能力：具備數(shù)據(jù)標(biāo)準(zhǔn)管理、數(shù)據(jù)質(zhì)量管理、元數(shù)據(jù)管理、數(shù)據(jù)資產(chǎn)目錄（敏感數(shù)據(jù)/業(yè)務(wù)術(shù)語表關(guān)聯(lián)/數(shù)據(jù)標(biāo)簽/血緣分析）等數(shù)據(jù)資產(chǎn)化管理能力，從而更好地賦予數(shù)據(jù)以價值，實現(xiàn)數(shù)據(jù)的資產(chǎn)化管理與運營。
數(shù)據(jù)服務(wù)管理能力：通過數(shù)據(jù)API管理模塊提供的低門檻、可視化的操作方式，以及分組、權(quán)限管理、服務(wù)上下線、計量與計費等管理功能，幫助數(shù)據(jù)分析人員將各類數(shù)據(jù)查詢語句封裝為API服務(wù)，供各業(yè)務(wù)部門和業(yè)務(wù)系統(tǒng)調(diào)用，從而實現(xiàn)數(shù)據(jù)的價值變現(xiàn)。
2.2.2 云數(shù)據(jù)平臺對數(shù)字化技術(shù)的“有機統(tǒng)一”
作為新一代的數(shù)據(jù)基礎(chǔ)設(shè)施，“云數(shù)據(jù)平臺”實現(xiàn)了兩方面的“大一統(tǒng)”，即對多種數(shù)據(jù)基礎(chǔ)設(shè)施技術(shù)架構(gòu)、多種數(shù)字化技的有機統(tǒng)一。
一方面，“云數(shù)據(jù)平臺”本質(zhì)上是對傳統(tǒng)的數(shù)據(jù)庫、數(shù)據(jù)倉庫、大數(shù)據(jù)平臺階段遺留的一系列底層技術(shù)、技術(shù)能力的升級與替代。
圖16：云數(shù)據(jù)平臺是對數(shù)據(jù)庫、數(shù)據(jù)倉庫、大數(shù)據(jù)平臺的升級與替代
另一方面，“云數(shù)據(jù)平臺”實現(xiàn)了對云、大數(shù)據(jù)、AI等多種數(shù)字化技術(shù)價值的有機統(tǒng)一。在實際的數(shù)字化項目落地過程中，以云能力、數(shù)據(jù)能力、AI能力為中心的數(shù)字化轉(zhuǎn)型往往相互割裂，未能實現(xiàn)充分協(xié)同。
以云能力為中心的數(shù)字化轉(zhuǎn)型：通過云基礎(chǔ)設(shè)施建設(shè)及組織架構(gòu)的變革，推動企業(yè)IT資源管理能力的數(shù)字化轉(zhuǎn)型；缺乏數(shù)字化能力的IT組織難以充分支撐業(yè)務(wù)部門數(shù)字化的需求，同時又是企業(yè)更好地沉淀、利用數(shù)據(jù)的基礎(chǔ)；
以數(shù)據(jù)能力為中心的數(shù)字化轉(zhuǎn)型：通過數(shù)據(jù)基礎(chǔ)設(shè)施建設(shè)及組織架構(gòu)的變革，推動企業(yè)數(shù)據(jù)利用能力的數(shù)字化轉(zhuǎn)型；既是對云基礎(chǔ)設(shè)施價值的進(jìn)一步提升，也為AI應(yīng)用的開發(fā)建立良好的數(shù)據(jù)基礎(chǔ)，在整個企業(yè)數(shù)字化轉(zhuǎn)型中居于承上啟下的地位；
以AI能力為中心的數(shù)字化轉(zhuǎn)型：通過AI平臺建設(shè)、智能化應(yīng)用的落地應(yīng)用及組織架構(gòu)的變革，推動企業(yè)分析決策能力的智能化轉(zhuǎn)型，也是對數(shù)據(jù)基礎(chǔ)設(shè)施價值的進(jìn)一步挖掘。
整體來看，“云數(shù)據(jù)平臺”充分整合了云原生特性，更統(tǒng)一、更強大的數(shù)據(jù)能力，以及對AI應(yīng)用的支持能力，為企業(yè)提供了“更統(tǒng)一、更強大”的數(shù)字化技術(shù)能力，未來將進(jìn)一步推動企業(yè)數(shù)字化深度、廣度的全面升級。
圖17：云數(shù)據(jù)平臺的價值
2.2.3 以云數(shù)據(jù)平臺為核心的企業(yè)數(shù)字化轉(zhuǎn)型方案
近些年來，隨著企業(yè)數(shù)字化深度、廣度的全面升級，國內(nèi)外分別崛起了一系列典型的“云數(shù)據(jù)平臺”提供商。
國外較為領(lǐng)先的云數(shù)據(jù)平臺提供商Snowflake，在2020年9月17日于紐交所上市當(dāng)天，市值突破700億美元。截止2020年11月底，Snowflake的市值更是已高達(dá)830億美元。
國內(nèi)較為領(lǐng)先的云數(shù)據(jù)平臺提供商偶數(shù)科技，核心創(chuàng)始團(tuán)隊來自EMC數(shù)據(jù)庫團(tuán)隊，其核心產(chǎn)品為新一代云原生數(shù)據(jù)倉庫Oushu Database。
偶數(shù)科技基于云數(shù)據(jù)平臺的企業(yè)數(shù)字化方案
偶數(shù)科技除了具備核心產(chǎn)品新一代云原生數(shù)據(jù)倉庫Oushu Database，還提供了包括數(shù)據(jù)管理平臺Oushu Lava、自動化機器學(xué)習(xí)平臺Oushu LittleBoy等一系列配套產(chǎn)品，共同構(gòu)成一套完整的云數(shù)據(jù)平臺解決方案，從而有效支撐金融、能源、制造等行業(yè)的大中型企業(yè)客戶的全面數(shù)字化轉(zhuǎn)型。
圖18：偶數(shù)科技云數(shù)據(jù)平臺解決方案
新一代云原生數(shù)據(jù)倉庫Oushu Database：Oushu Database（簡稱OushuDB）是由新一代云原生數(shù)據(jù)倉庫，具備ANSI-SQL標(biāo)準(zhǔn)兼容、ACID特性支持、Hadoop原生支持等特性，兼容Oracle、Greenplum Database、PostgreSQL和Hadoop原生技術(shù)體系，采用了存儲與計算分離和虛擬計算集群技術(shù)架構(gòu)，實現(xiàn)彈性伸縮、秒級擴(kuò)容和超大規(guī)模集群（幾千節(jié)點級別）的支持。OushuDB在業(yè)界首次解決了大數(shù)據(jù)量下跨數(shù)據(jù)中心的數(shù)據(jù)存儲和分析問題，并設(shè)計了新一代SIMD執(zhí)行器，性能比傳統(tǒng)數(shù)倉快大約5-10倍，提供PB級數(shù)據(jù)交互式查詢能力，提供對主要BI工具的描述性分析和AI支持，對于金融等行業(yè)的吸引力進(jìn)一步增強。
數(shù)據(jù)管理平臺Oushu Lava：Oushu Lava是一款定位于幫助企業(yè)構(gòu)建云數(shù)據(jù)平臺的工具集，包括數(shù)據(jù)接入工具、數(shù)據(jù)開發(fā)工具、數(shù)據(jù)資產(chǎn)管理工具、數(shù)據(jù)服務(wù)管理工具等部分，支持客戶進(jìn)行敏捷數(shù)據(jù)應(yīng)用開發(fā)，助力企業(yè)實現(xiàn)數(shù)字化轉(zhuǎn)型。
自動化機器學(xué)習(xí)平臺Oushu LittleBoy：Oushu LittleBoy是一個通用的自動化機器學(xué)習(xí)平臺，可以幫助企業(yè)級用戶輕松實現(xiàn)人工智能落地。Oushu LittleBoy可通過內(nèi)置的AutoML從上億個模型中自動挑選出優(yōu)化的模型，讓用戶在不了解算法原理的情況下自動選出最優(yōu)配置，提升業(yè)務(wù)效率。
愛分析認(rèn)為，“云數(shù)據(jù)平臺”未來將成為以集團(tuán)型、多分支企業(yè)為代表的大中型企業(yè)數(shù)字化的堅實底座。
03
以云數(shù)據(jù)平臺為中心的企業(yè)數(shù)字化落地方法論
正如章節(jié)2.2.2所述，云數(shù)據(jù)平臺在數(shù)據(jù)基礎(chǔ)設(shè)施的基礎(chǔ)上，實現(xiàn)了對云、AI能力的無縫融合，是企業(yè)數(shù)字化落地的一種更先進(jìn)的技術(shù)形式。
但是，以云數(shù)據(jù)平臺為中心的企業(yè)數(shù)字化轉(zhuǎn)型，需要更加完善和體系化的落地方法論。一般來講，數(shù)字化方法論包括戰(zhàn)略規(guī)劃與落地實施兩個維度。
按照章節(jié)1.1中的描述，企業(yè)數(shù)字化的戰(zhàn)略規(guī)劃應(yīng)當(dāng)包括數(shù)字化戰(zhàn)略、數(shù)字化場景、數(shù)字化技術(shù)、數(shù)字化組織等四個層次。
從落地實施維度上看，企業(yè)數(shù)字化實施過程包括：路徑規(guī)劃、需求分析、方案設(shè)計、方案實現(xiàn)、方案支持與迭代等五個步驟。
圖19：企業(yè)數(shù)字化實施過程
3.1 路徑規(guī)劃
路徑規(guī)劃階段的主要目標(biāo)是確立數(shù)字化轉(zhuǎn)型路徑。為此，企業(yè)首先需要確立數(shù)字化愿景與整體目標(biāo)，梳理業(yè)務(wù)場景、數(shù)字化現(xiàn)狀，并構(gòu)建數(shù)字化實施團(tuán)隊，最終交付現(xiàn)狀調(diào)研報告與數(shù)字化轉(zhuǎn)型路線圖。
圖20：路徑規(guī)劃
數(shù)字化愿景與整體目標(biāo)確立
確立企業(yè)數(shù)字化愿景與整體目標(biāo)的主要價值，在于使得企業(yè)上下達(dá)成對數(shù)字化的同一認(rèn)知，從而有助于協(xié)調(diào)資源，降低數(shù)字化推行阻力。為此，企業(yè)高層領(lǐng)導(dǎo)需要對數(shù)字化轉(zhuǎn)型進(jìn)行統(tǒng)籌規(guī)劃，提出宏觀層面的方針與指示。
應(yīng)用場景梳理
梳理數(shù)字化場景的主要價值，在于使企業(yè)能夠正確認(rèn)識數(shù)字化帶來的潛在價值，明確數(shù)字化轉(zhuǎn)型項目的波及范圍及投入規(guī)模。為此，企業(yè)需要對應(yīng)用系統(tǒng)現(xiàn)狀進(jìn)行梳理，并對現(xiàn)有的痛點及業(yè)務(wù)價值進(jìn)行判斷。
應(yīng)用系統(tǒng)現(xiàn)狀梳理：各應(yīng)用系統(tǒng)的產(chǎn)品名稱、版本、開發(fā)商、使用者、運維方，應(yīng)用系統(tǒng)的對接方式（接口類型、模板、語言、工具）及數(shù)據(jù)庫對接方式；
痛點及業(yè)務(wù)價值判斷：對用戶在使用各應(yīng)用系統(tǒng)過程中存在的痛點進(jìn)行調(diào)研與收集，對潛在的數(shù)字化價值進(jìn)行初步判斷。
數(shù)字化現(xiàn)狀梳理
梳理數(shù)字化現(xiàn)狀的主要價值在于幫助企業(yè)判斷業(yè)務(wù)場景數(shù)字化的當(dāng)前階段。為此，企業(yè)需要對源系統(tǒng)數(shù)據(jù)存儲、現(xiàn)有大數(shù)據(jù)平臺、BI平臺、人工智能、基礎(chǔ)設(shè)施及架構(gòu)的現(xiàn)狀進(jìn)行系統(tǒng)性梳理。
源系統(tǒng)數(shù)據(jù)存儲現(xiàn)狀：交易型數(shù)據(jù)庫產(chǎn)品名稱、版本、應(yīng)用情況、使用者、運維方；對外數(shù)據(jù)接口方式、負(fù)載現(xiàn)狀、元數(shù)據(jù)信息；
數(shù)據(jù)基礎(chǔ)設(shè)施現(xiàn)狀：分析型數(shù)據(jù)庫產(chǎn)品名稱、版本、使用者、運維方、應(yīng)用場景、數(shù)據(jù)存量；用戶規(guī)劃、權(quán)限分配等情況；運維、監(jiān)控、預(yù)警平臺現(xiàn)狀；schema數(shù)量、名稱、作用；主題域、邏輯模型和物理模型；表、視圖、函數(shù)數(shù)量；
比如，數(shù)據(jù)基礎(chǔ)設(shè)施往往存在多種負(fù)面現(xiàn)狀，如集群數(shù)量過多、不利于數(shù)據(jù)共享與維護(hù)，計算存儲耦合、彈性能力受限，數(shù)據(jù)跑批與即席查詢性能不足、數(shù)據(jù)報表與查詢結(jié)果產(chǎn)出時效性差等；在云數(shù)據(jù)平臺的實施過程中，企業(yè)對這些現(xiàn)狀應(yīng)當(dāng)予以重點解決；
BI平臺現(xiàn)狀：BI產(chǎn)品名稱、版本、使用者、運維方；BI報表數(shù)量、BI是否支持自助式報表；
人工智能現(xiàn)狀：AI平臺產(chǎn)品名稱、版本、使用者、運維方；AI模型的應(yīng)用場景；AI模型的名稱、數(shù)量及算法；建模任務(wù)現(xiàn)有運行時間；特征工程建立方式；
比如，企業(yè)往往以使用規(guī)則引擎、傳統(tǒng)機器學(xué)習(xí)算法來實現(xiàn)AI預(yù)測，且僅面向少量應(yīng)用系統(tǒng)，無法實現(xiàn)對深度學(xué)習(xí)AI模型的敏捷開發(fā)；在云數(shù)據(jù)平臺的實施過程中，企業(yè)對該現(xiàn)狀應(yīng)對予以重點解決；
基礎(chǔ)設(shè)施及架構(gòu)現(xiàn)狀：現(xiàn)有系統(tǒng)架構(gòu)圖、現(xiàn)有系統(tǒng)組件構(gòu)成、現(xiàn)有集群數(shù)量及系統(tǒng)部署情況、現(xiàn)有服務(wù)器單節(jié)點硬件配置。
數(shù)字化轉(zhuǎn)型實施團(tuán)隊構(gòu)建
構(gòu)建數(shù)字化轉(zhuǎn)型實施團(tuán)隊主要價值在于為企業(yè)數(shù)字化戰(zhàn)略提供人才支撐，因為缺乏人才支撐的數(shù)字化轉(zhuǎn)型，在啟動階段就會遇到重重障礙。數(shù)字化轉(zhuǎn)型實施團(tuán)隊主要包括以下三類人才。
數(shù)據(jù)戰(zhàn)略和數(shù)據(jù)治理類：數(shù)據(jù)戰(zhàn)略顧問、數(shù)據(jù)治理專家、數(shù)據(jù)項目經(jīng)理；
數(shù)據(jù)科學(xué)和數(shù)據(jù)工程類：數(shù)據(jù)科學(xué)家、人工智能機器學(xué)習(xí)算法工程師、大數(shù)據(jù)工程師、數(shù)據(jù)測試工程師、數(shù)據(jù)運維工程師；
數(shù)據(jù)管理和數(shù)據(jù)應(yīng)用類：數(shù)據(jù)建模顧問、數(shù)據(jù)分析顧問。
在一系列現(xiàn)狀梳理工作過程中，數(shù)字化轉(zhuǎn)型實施團(tuán)隊可通過交付《現(xiàn)狀調(diào)研報告》來作為中間成果，從而幫助企業(yè)高層明確企業(yè)現(xiàn)狀，并為未來的需求分析工作積累文檔素材。
在戰(zhàn)略規(guī)劃階段結(jié)束時，數(shù)字化轉(zhuǎn)型實施團(tuán)隊需要交付《數(shù)字化轉(zhuǎn)型路線圖》作為階段性成果，以確定企業(yè)數(shù)字化轉(zhuǎn)型階段劃分，從而幫助企業(yè)高層合理安排資源投入，并確定項目排期。
3.2 需求分析
需求分析階段的主要目標(biāo)，是將路徑規(guī)劃階段制定的整體目標(biāo)拆解到具體業(yè)務(wù)場景中，以制定更加具體的數(shù)字化實施排期方案。為此，企業(yè)需要首先對應(yīng)用場景進(jìn)行定義與分析，并對數(shù)字化需求進(jìn)行分析，從而進(jìn)行初步的系統(tǒng)演示，并交付數(shù)字化需求分析報告。
從這一階段開始，企業(yè)可與有大量成功實施經(jīng)驗的數(shù)字化廠商（如偶數(shù)科技）展開密切合作，從而有效降低學(xué)習(xí)成本，提升實施效率，降低失敗風(fēng)險。
圖21：需求分析
應(yīng)用場景定義與分析
應(yīng)用場景定義與分析的主要價值，在于使得企業(yè)更加明確各個場景內(nèi)數(shù)字化的潛在價值、所需投入，并有效指導(dǎo)數(shù)字化需求分析過程的分析范圍與最終目標(biāo)。為此，企業(yè)需要確定應(yīng)用場景對應(yīng)的業(yè)務(wù)目標(biāo)，并對場景內(nèi)的流程與需求功能進(jìn)行分析。
數(shù)字化需求分析
數(shù)字化需求分析的主要價值，在于對數(shù)字化解決方案架構(gòu)中的各個系統(tǒng)、模塊與組件應(yīng)達(dá)成的目標(biāo)與效果進(jìn)行確認(rèn)，包括對數(shù)據(jù)存儲與計算、數(shù)據(jù)資產(chǎn)、數(shù)據(jù)服務(wù)、數(shù)據(jù)平臺、硬件部署、人工智能等各個模塊的需求分析。
數(shù)據(jù)存儲與計算需求：未來數(shù)年數(shù)據(jù)量增長、存儲需求、災(zāi)備需求及批處理、實時查詢性能需求；數(shù)據(jù)存儲和計算需求功能列表；
比如，業(yè)務(wù)部門需要在T+1完成跑批結(jié)果，同時希望進(jìn)一步擴(kuò)大跑批所分析的數(shù)據(jù)量，從PB級到十PB級以上；業(yè)務(wù)部門希望將長達(dá)數(shù)分鐘的即席查詢周期，提升到秒級獲取查詢結(jié)果；
數(shù)據(jù)資產(chǎn)管理需求：數(shù)據(jù)治理的目標(biāo)分析，元數(shù)據(jù)管理、數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)質(zhì)量規(guī)則需求，數(shù)據(jù)治理需求功能列表；數(shù)據(jù)資產(chǎn)目錄需求，數(shù)據(jù)資產(chǎn)管理需求功能列表；
數(shù)據(jù)服務(wù)管理需求：數(shù)據(jù)服務(wù)接口需求，數(shù)據(jù)服務(wù)部署需求；數(shù)據(jù)集市需求，數(shù)據(jù)可視化需求，數(shù)據(jù)報表需求；
現(xiàn)有數(shù)據(jù)平臺需求：現(xiàn)有大數(shù)據(jù)平臺存在的優(yōu)勢，以及與源數(shù)據(jù)系統(tǒng)、外圍應(yīng)用系統(tǒng)的適配性分析；數(shù)字化轉(zhuǎn)型對大數(shù)據(jù)平臺的新需求，現(xiàn)有大數(shù)據(jù)平臺對業(yè)務(wù)需求及數(shù)據(jù)需求的不滿足之處，以及所需的需求功能列表；
硬件部署需求：業(yè)務(wù)增長及數(shù)字化轉(zhuǎn)型對新型平臺硬件的變更需求，平臺硬件部署拓?fù)浣Y(jié)構(gòu)變化需求分析，平臺硬件部署需求功能列表；
人工智能需求：AI模型最終用戶確認(rèn)；AI模型需求分析，如業(yè)務(wù)應(yīng)用準(zhǔn)確率與召回率，樣本庫數(shù)據(jù)，模型指標(biāo)庫，AI模型更新頻率等；AI工具需求分析，如AI模型生命周期管理，應(yīng)用系統(tǒng)調(diào)用AI模型方式；AI模型開發(fā)運維團(tuán)隊分配；現(xiàn)有AI模型問題匯總。
在需求分析階段結(jié)束時，數(shù)字化廠商可基于測試環(huán)境，對數(shù)字化轉(zhuǎn)型方案進(jìn)行系統(tǒng)安裝演示，并與企業(yè)客戶密切配合，共同交付《業(yè)務(wù)及數(shù)據(jù)需求分析報告》。
3.3 方案設(shè)計&方案實現(xiàn)
方案設(shè)計階段的主要任務(wù)，是對數(shù)字化轉(zhuǎn)型方案中的各個系統(tǒng)、模塊與組件的技術(shù)實現(xiàn)方式進(jìn)行設(shè)計，提前發(fā)現(xiàn)實施中可能存在的難點，指導(dǎo)各個實施小組的具體分工協(xié)作方式，以保證方案實現(xiàn)階段的工作能夠合理、有序進(jìn)行。
方案實現(xiàn)階段的主要任務(wù)，是按照方案設(shè)計階段輸出的交付物，通過實際的編碼、實施，將設(shè)計方案進(jìn)行落地交付。
在理想狀態(tài)下，方案設(shè)計與方案實現(xiàn)的內(nèi)容能夠完全一一對應(yīng)，而且不會交替進(jìn)行。但是，在許多情況下，由于設(shè)計階段考慮的不周，或者項目排期的客觀原因，這兩個階段可能是交替進(jìn)行的，即在方案實現(xiàn)過程中或階段完成后，方案設(shè)計仍需要重復(fù)進(jìn)行。
在方案設(shè)計與實現(xiàn)階段，企業(yè)需要對應(yīng)用場景、數(shù)字化技術(shù)方案進(jìn)行設(shè)計與實現(xiàn)。
圖22：方案設(shè)計&方案實現(xiàn)
應(yīng)用場景設(shè)計與實現(xiàn)
應(yīng)用場景設(shè)計與實現(xiàn)的主要價值，在于保證云數(shù)據(jù)平臺與企業(yè)業(yè)務(wù)場景的良好適配，從而實現(xiàn)其最大化的業(yè)務(wù)價值。
業(yè)務(wù)架構(gòu)設(shè)計與實現(xiàn)：對應(yīng)用場景下，企業(yè)自有的業(yè)務(wù)流程體系、業(yè)務(wù)運營模式、組織結(jié)構(gòu)及其對應(yīng)IT應(yīng)用系統(tǒng)架構(gòu)進(jìn)行設(shè)計與實現(xiàn)，該工作一般需要企業(yè)或相應(yīng)的外部服務(wù)商來完成；
平臺功能設(shè)計與實現(xiàn)：對應(yīng)用場景下，云數(shù)據(jù)平臺自身的交互流程、功能界面及接口進(jìn)行設(shè)計與實現(xiàn)；
數(shù)據(jù)流設(shè)計與實現(xiàn)：對應(yīng)用場景下，數(shù)據(jù)在云數(shù)據(jù)平臺、BI平臺及外部系統(tǒng)的流動方式進(jìn)行設(shè)計與實現(xiàn)。
數(shù)字化技術(shù)方案設(shè)計與實現(xiàn)
數(shù)字化技術(shù)方案的設(shè)計與實現(xiàn)，是整個數(shù)字化轉(zhuǎn)型項目的核心內(nèi)容，其時間與人力成本投入在整個項目中占據(jù)較高比重。
數(shù)據(jù)模型設(shè)計與實現(xiàn)：數(shù)據(jù)模型的設(shè)計規(guī)范；邏輯數(shù)據(jù)模型的設(shè)計與實現(xiàn)，包括主題域分析，建立實體模型，建立實體間依賴關(guān)系；物理數(shù)據(jù)模型的設(shè)計與實現(xiàn)，包括轉(zhuǎn)換邏輯數(shù)據(jù)模型為物理數(shù)據(jù)模型，對模型設(shè)計進(jìn)行優(yōu)化；
數(shù)據(jù)處理設(shè)計與實現(xiàn)：通過ETL、任務(wù)調(diào)度等工具進(jìn)行數(shù)據(jù)轉(zhuǎn)換與加載，包括數(shù)據(jù)抽取、轉(zhuǎn)換和加載策略的設(shè)計與實現(xiàn)，以及自動化調(diào)度依賴關(guān)系的設(shè)計與實現(xiàn)；
比如，企業(yè)可應(yīng)用Oushu Lava，以O(shè)ushuDB高性能云數(shù)據(jù)倉庫替代Hive引擎，基于同樣的PB級數(shù)據(jù)和僅一半服務(wù)器節(jié)點數(shù)，跑批性能提升幾十倍，復(fù)雜即席查詢分析可在秒級完成；
數(shù)據(jù)資產(chǎn)管理設(shè)計與實現(xiàn)：元數(shù)據(jù)管理的設(shè)計與實現(xiàn)，包括元數(shù)據(jù)功能、元數(shù)據(jù)提取規(guī)則及周期、元數(shù)據(jù)變更；數(shù)據(jù)標(biāo)準(zhǔn)的設(shè)計與實現(xiàn)；數(shù)據(jù)質(zhì)量檢查的設(shè)計與實現(xiàn)；錯誤數(shù)據(jù)處理的設(shè)計與實現(xiàn)；數(shù)據(jù)資產(chǎn)目錄的設(shè)計與實現(xiàn)，包括數(shù)據(jù)權(quán)限分配等；
數(shù)據(jù)服務(wù)管理的設(shè)計與實現(xiàn)：數(shù)據(jù)服務(wù)接口的設(shè)計與實現(xiàn)；數(shù)據(jù)服務(wù)部署的設(shè)計與實現(xiàn)；數(shù)據(jù)集市模型的設(shè)計與實現(xiàn)；數(shù)據(jù)可視化、數(shù)據(jù)報表、圖形可視化的設(shè)計與實現(xiàn)；
AI模型設(shè)計與實現(xiàn)：AI模型特征工程設(shè)計與實現(xiàn)；AI模型算法/參數(shù)設(shè)計與實現(xiàn)；AI模型指標(biāo)庫設(shè)計與實現(xiàn)；AI模型服務(wù)設(shè)計與實現(xiàn)；AI應(yīng)用場景數(shù)據(jù)寬表設(shè)計與實現(xiàn)；
比如，應(yīng)用LittleBoy自動化機器學(xué)習(xí)系統(tǒng)深度學(xué)習(xí)算法自動化完成關(guān)于客戶畫像、電信反欺詐等應(yīng)用場景的模型訓(xùn)練、發(fā)布、生命周期管理，顯著提升預(yù)測準(zhǔn)確率、召回率。
基于企業(yè)與數(shù)字化廠商的密切配合，在方案設(shè)計階段結(jié)束時，雙方需要交付《數(shù)字化轉(zhuǎn)型方案設(shè)計報告》，而在方案實現(xiàn)階段結(jié)束時，雙方需要交付《數(shù)字化轉(zhuǎn)型方案交付報告》，并由企業(yè)對項目進(jìn)行驗收測試與試運行。
3.4 方案支持與迭代
在方案支持與迭代階段的主要目的，是保持?jǐn)?shù)字化轉(zhuǎn)型方案的生命力，讓其產(chǎn)生更加持久的業(yè)務(wù)價值。為此，企業(yè)需要與數(shù)字化廠商配合，對現(xiàn)有方案進(jìn)行培訓(xùn)與推廣，對已完成的數(shù)字化轉(zhuǎn)型項目的業(yè)務(wù)價值進(jìn)行復(fù)盤，對數(shù)字化技術(shù)方案進(jìn)行持續(xù)迭代，對潛在業(yè)務(wù)場景進(jìn)行持續(xù)探索。
圖23：方案支持與迭代
用戶培訓(xùn)與應(yīng)用推廣：對業(yè)務(wù)場景、操作規(guī)范、云數(shù)據(jù)平臺相關(guān)技術(shù)進(jìn)行培訓(xùn)；制定應(yīng)用推廣計劃，包括應(yīng)用準(zhǔn)備、應(yīng)用推廣啟動、業(yè)務(wù)需求交流、專題應(yīng)用開發(fā)、專題結(jié)果分析、應(yīng)用評估總結(jié)、應(yīng)用跟蹤提升等環(huán)節(jié)；
業(yè)務(wù)收益復(fù)盤：通過業(yè)務(wù)部門的持續(xù)反饋以及對項目前后的業(yè)務(wù)指標(biāo)的統(tǒng)計，通過定性判斷、定量計算等多種方式，對數(shù)字化轉(zhuǎn)型項目的業(yè)務(wù)價值與收益進(jìn)行復(fù)盤，發(fā)現(xiàn)不足并尋找原因，從而指導(dǎo)未來的方案優(yōu)化迭代；
數(shù)字化技術(shù)方案迭代：基于業(yè)務(wù)收益復(fù)盤的結(jié)果，對數(shù)據(jù)存儲和計算進(jìn)行性能調(diào)優(yōu)，對數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)服務(wù)管理進(jìn)行回顧與優(yōu)化，對AI模型進(jìn)行持續(xù)迭代與優(yōu)化；
新應(yīng)用場景探索：通過業(yè)務(wù)部門的持續(xù)反饋，確定企業(yè)新的業(yè)務(wù)場景、業(yè)務(wù)需求，并重復(fù)需求分析、方案設(shè)計、方案實現(xiàn)等環(huán)節(jié)，最終實現(xiàn)業(yè)務(wù)價值的驗證。
04
典型行業(yè)實踐案例
4.1 銀行行業(yè)案例
企業(yè)概況
某銀行是12家全國性股份制商業(yè)銀行之一，以四大業(yè)務(wù)板塊（公司、小微、零售、同業(yè)）作為品牌支柱。該行于2016年在香港聯(lián)交所上市，于2019年在上海證券交易所上市，系全國第13家“A+H”上市銀行。
截至2019年末，在全國19個?。ㄖ陛犑校┘跋愀厶貏e行政區(qū)設(shè)立了260家分支機構(gòu)，實現(xiàn)了對長三角、環(huán)渤海、珠三角以及部分中西部地區(qū)的有效覆蓋。
面對經(jīng)濟(jì)新常態(tài)，該行順應(yīng)互聯(lián)網(wǎng)信息技術(shù)發(fā)展新趨勢和客戶價值創(chuàng)造新需求，確立了“兩最”總目標(biāo)和平臺化服務(wù)戰(zhàn)略，堅持“服務(wù)實體經(jīng)濟(jì)、創(chuàng)新轉(zhuǎn)型、合規(guī)經(jīng)營、防化風(fēng)險、提質(zhì)增效”五項經(jīng)營原則，打造平臺化服務(wù)銀行，為客戶提供開放、高效、靈活、共享、極致的綜合金融服務(wù)。
數(shù)字化愿景與整體目標(biāo)
為實現(xiàn)全行數(shù)字化轉(zhuǎn)型，打造行業(yè)領(lǐng)先的零售銀行、普惠金融，該行需要通過建立云數(shù)據(jù)平臺滿足業(yè)務(wù)創(chuàng)新應(yīng)用敏捷開發(fā)、大數(shù)據(jù)數(shù)據(jù)資產(chǎn)價值最大化、人工智能深入應(yīng)用的需求，從而不斷提升客戶體驗，進(jìn)一步加強在股份制銀行中的地位。
應(yīng)用場景梳理
該行現(xiàn)有應(yīng)用系統(tǒng)包括管理會計系統(tǒng)、績效考核系統(tǒng)、風(fēng)險預(yù)警系統(tǒng)、客戶畫像系統(tǒng)、反電信詐騙系統(tǒng)、反欺詐系統(tǒng)、監(jiān)管報送系統(tǒng)等幾十個基于全行數(shù)據(jù)分析完成的應(yīng)用。
數(shù)字化現(xiàn)狀梳理
該銀行已建設(shè)大數(shù)據(jù)智能平臺來推動數(shù)字化轉(zhuǎn)型，其基本現(xiàn)狀如下：
Oracle、DB2傳統(tǒng)數(shù)據(jù)倉庫幾百TB級數(shù)據(jù)，幾萬張表、上萬個ETL作業(yè)任務(wù)，全行大數(shù)據(jù)在快速增長；
ODS區(qū)是采用文本文件的方式從源系統(tǒng)獲取數(shù)據(jù)；標(biāo)準(zhǔn)數(shù)據(jù)集市區(qū)為統(tǒng)一交換平臺，為分行大數(shù)據(jù)平臺服務(wù)；總行大數(shù)據(jù)平臺區(qū)實現(xiàn)數(shù)據(jù)粘帖、數(shù)據(jù)匯總、數(shù)據(jù)應(yīng)用；分行大數(shù)據(jù)平臺區(qū)實現(xiàn)數(shù)據(jù)粘帖、數(shù)據(jù)匯總、數(shù)據(jù)應(yīng)用；沙盤演練區(qū)：開發(fā)測試環(huán)境區(qū)域，供開發(fā)測試以及各種演示使用
只有少數(shù)場景使用規(guī)則引擎加手工修改腳本參數(shù)的方式實現(xiàn)人工智能預(yù)測。
數(shù)字化需求分析
該行現(xiàn)有的數(shù)據(jù)基礎(chǔ)設(shè)施存在大量痛點，難以支撐數(shù)字化轉(zhuǎn)型的進(jìn)一步推進(jìn)：
由于傳統(tǒng)數(shù)據(jù)倉庫存儲及計算性能接近上限：無法滿足全行數(shù)據(jù)未來幾年的增長；
數(shù)據(jù)孤島依然存在：沒有沉淀數(shù)據(jù)資產(chǎn)，缺少數(shù)據(jù)治理系統(tǒng)工具及完備的數(shù)據(jù)標(biāo)準(zhǔn)；
無法快速賦能業(yè)務(wù)應(yīng)用創(chuàng)新；對于某個分析業(yè)務(wù)的需求，用戶從準(zhǔn)備數(shù)據(jù)，匯集數(shù)據(jù)，建立模型，生成報表整個過程需要的周期太長，效率低下；
規(guī)則引擎預(yù)測準(zhǔn)確率比較低、缺少自動化機器學(xué)習(xí)模型預(yù)測。
數(shù)字化技術(shù)方案設(shè)計與實現(xiàn)
偶數(shù)科技為了幫助該行應(yīng)對數(shù)字化中存在的痛點，從數(shù)據(jù)戰(zhàn)略、云數(shù)據(jù)平臺整體架構(gòu)、數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)治理、人工智能建模平臺建設(shè)等方面為該行完成了詳細(xì)的設(shè)計與實施方案：
圖24：新一代云數(shù)據(jù)平臺方案
數(shù)據(jù)來源：偶數(shù)科技
應(yīng)用Oushu Lava，以基于HDFS的OushuDB高性能云數(shù)據(jù)倉庫替代Oracle、DB2數(shù)據(jù)倉庫，現(xiàn)有上百個節(jié)點可以支持PB級數(shù)據(jù)、可動態(tài)擴(kuò)容，單一集群支持上千節(jié)點，滿足行方未來十年數(shù)據(jù)高速增長，且跑批性能是之前傳統(tǒng)數(shù)據(jù)倉庫的數(shù)倍；
應(yīng)用Lava數(shù)據(jù)治理套件實現(xiàn)數(shù)據(jù)治理，完成數(shù)據(jù)標(biāo)準(zhǔn)管理、元數(shù)據(jù)管理、數(shù)據(jù)資產(chǎn)管理；
應(yīng)用LittleBoy自動化機器學(xué)習(xí)系統(tǒng)完成風(fēng)險預(yù)警、反洗錢、反欺詐等應(yīng)用場景的模型訓(xùn)練、發(fā)布、生命周期管理，顯著提升預(yù)測準(zhǔn)確率、召回率；
應(yīng)用Lava數(shù)據(jù)服務(wù)套件，將數(shù)據(jù)資產(chǎn)、AI模型發(fā)布為數(shù)據(jù)與AI Rest API服務(wù)實現(xiàn)上層共享。
業(yè)務(wù)收益復(fù)盤
在偶數(shù)科技的方案成功實施之后，該行獲得了以下方面的業(yè)務(wù)收益：
Oushu Lava實現(xiàn)上層應(yīng)用敏捷開發(fā)、數(shù)據(jù)資產(chǎn)價值最大化，使得數(shù)據(jù)及時賦能業(yè)務(wù)，提升用戶體驗 、提高業(yè)務(wù)部門效率；
OushuDB實現(xiàn)了傳統(tǒng)數(shù)據(jù)倉庫所無法處理的海量數(shù)據(jù)、且系統(tǒng)遷移時間短；其在秒級時間內(nèi)給出交互式分析結(jié)果，為業(yè)務(wù)人員針對重點問題及時決策分析提供了強有力的工具保障；
LittleBoy自動化機器學(xué)習(xí)系統(tǒng)提供的模型預(yù)測增強了全行風(fēng)險管控能力、智能獲客能力。
4.2 保險行業(yè)案例
企業(yè)概況
某保險公司屬國家大型金融保險企業(yè)。2018年，該保險公司的集團(tuán)公司合并營業(yè)收入7684億元；合并保費收入6463億元；合并總資產(chǎn)近4萬億元。
該保險公司已連續(xù)17年入選《財富》世界500強企業(yè)，排名由2003年的290位躍升為2019年的51位；連續(xù)12年入選世界品牌500強。該保險公司所屬股份有限公司繼2003年12月在紐約、香港兩地同步上市之后，又于2007年1月回歸境內(nèi)A股市場，成為全球第一家在紐約、香港和上海三地上市的保險公司。
目前，集團(tuán)公司下設(shè)8家一級子公司、1家全國性股份制銀行，業(yè)務(wù)范圍全面涵蓋壽險、財險、企業(yè)和職業(yè)年金、銀行、基金、資產(chǎn)管理、財富管理、實業(yè)投資、海外業(yè)務(wù)等多個領(lǐng)域多家公司和機構(gòu)；2016年開啟保險、投資、銀行三大板塊協(xié)同發(fā)展新格局。
近年來，該保險公司堅持高質(zhì)量發(fā)展，扎實推進(jìn)保險主業(yè)價值和規(guī)模協(xié)調(diào)發(fā)展，努力提升投資板塊貢獻(xiàn)，積極做好銀行金融服務(wù)，有序開展綜合化經(jīng)營、科技化創(chuàng)新、國際化布局，全面推進(jìn)國際一流金融保險集團(tuán)建設(shè)。
數(shù)字化愿景與整體目標(biāo)
該保險公司在戰(zhàn)略層面，確立數(shù)字化轉(zhuǎn)型的“四大行動”：客戶體驗數(shù)字化、運營管理數(shù)字化、商業(yè)模式數(shù)字化和全面夯實數(shù)字化基礎(chǔ)平臺。
該保險公司通過科技化創(chuàng)新，持續(xù)深化業(yè)務(wù)與科技融合、數(shù)據(jù)融合、平臺融合、線上線下融合、科研融合、生態(tài)融合，不斷提升科技創(chuàng)新能力和賦能水平，提供企業(yè)級數(shù)據(jù)資產(chǎn)管理平臺，統(tǒng)一數(shù)據(jù)標(biāo)準(zhǔn)，通過數(shù)據(jù)標(biāo)準(zhǔn)體系與數(shù)據(jù)指標(biāo)系統(tǒng)建設(shè)，統(tǒng)一數(shù)據(jù)指標(biāo)口徑，統(tǒng)一數(shù)據(jù)服務(wù)，實現(xiàn)數(shù)字化平臺、智能服務(wù)與運營服務(wù)。
應(yīng)用場景梳理
該保險公司現(xiàn)有包括綜合業(yè)務(wù)處理系統(tǒng)、個人渠道銷售人員管理信息系統(tǒng)、團(tuán)體銷售人員管理信息系統(tǒng)、中介代理短險銷售系統(tǒng)、客戶主數(shù)據(jù)管理系統(tǒng)等幾十個業(yè)務(wù)應(yīng)用及分析系統(tǒng)。
數(shù)字化現(xiàn)狀梳理
該保險公司已建設(shè)傳統(tǒng)數(shù)據(jù)倉庫來推動數(shù)字化轉(zhuǎn)型，其基本現(xiàn)狀如下：
幾十個SQL Server、Oracle傳統(tǒng)數(shù)據(jù)倉庫，累計近PB級數(shù)據(jù)，上萬張表、幾千個ETL作業(yè)任務(wù)，集團(tuán)大數(shù)據(jù)在快速增長；
數(shù)據(jù)龐雜而分散，前臺和后臺、內(nèi)部與外部、全景匯聚數(shù)據(jù)、結(jié)構(gòu)化與非結(jié)構(gòu)化的數(shù)據(jù)，分散在不同大數(shù)據(jù)平臺來分別進(jìn)行加工處理；
面向少數(shù)應(yīng)用系統(tǒng)使用規(guī)則引擎、傳統(tǒng)機器學(xué)習(xí)算法實現(xiàn)人工智能預(yù)測，但是無法實現(xiàn)對模型的敏捷開發(fā)，上層各應(yīng)系統(tǒng)無法便捷獲取模型/數(shù)據(jù)服務(wù)。
數(shù)字化需求分析
該保險公司現(xiàn)有的數(shù)據(jù)基礎(chǔ)設(shè)施存在大量痛點，難以支撐數(shù)字化轉(zhuǎn)型的進(jìn)一步推進(jìn)：
集團(tuán)與各省分公司業(yè)務(wù)指標(biāo)一致性不理想，急需建立統(tǒng)一的數(shù)據(jù)模型與數(shù)據(jù)標(biāo)準(zhǔn)，提高數(shù)據(jù)一致性；
公司系統(tǒng)的數(shù)據(jù)質(zhì)量問題，而數(shù)據(jù)差錯的溯源比較困難；急需建立數(shù)據(jù)治理的閉環(huán)和數(shù)據(jù)質(zhì)量體系；
數(shù)據(jù)孤島依然存在，沒有沉淀為全集團(tuán)共享的統(tǒng)一的數(shù)據(jù)資產(chǎn)；
無法快速賦能各省業(yè)務(wù)應(yīng)用創(chuàng)新；對于某個業(yè)務(wù)創(chuàng)新的需求，從分析數(shù)據(jù)，匯集數(shù)據(jù)，建立AI模型，完成自動打標(biāo)簽，直至生成報表整個過程需要的周期太長，效率低下。
數(shù)字化技術(shù)方案設(shè)計與實現(xiàn)
偶數(shù)科技為了幫助該保險公司應(yīng)對數(shù)字化中存在的痛點，從數(shù)據(jù)戰(zhàn)略、云數(shù)據(jù)平臺整體架構(gòu)、數(shù)據(jù)治理、數(shù)據(jù)資產(chǎn)、數(shù)據(jù)標(biāo)準(zhǔn)、元數(shù)據(jù)管理等方面上為此保險公司完成詳細(xì)的規(guī)劃設(shè)計和實施方案：
圖25：某保險公司方案
數(shù)據(jù)來源：偶數(shù)科技
應(yīng)用Ouhshu Lava，以O(shè)ushuDB高性能分析型云數(shù)據(jù)庫替代SQL Server、Oracle傳統(tǒng)數(shù)據(jù)倉庫，現(xiàn)有近百個節(jié)點可以支持PB級數(shù)據(jù)、可動態(tài)擴(kuò)容，滿足未來數(shù)據(jù)高速增長需求，且跑批性能是之前傳統(tǒng)數(shù)據(jù)倉庫的數(shù)倍；
應(yīng)用Lava數(shù)據(jù)治理工具數(shù)據(jù)治理，完成數(shù)據(jù)標(biāo)準(zhǔn)管理、元數(shù)據(jù)管理、數(shù)據(jù)資產(chǎn)管理；
應(yīng)用Lava標(biāo)簽和指標(biāo)管理套件，完成標(biāo)簽和指標(biāo)體系的可視化定義、建模、自動化打標(biāo)簽、標(biāo)簽展示、上線、權(quán)限管理、訪問監(jiān)控、統(tǒng)計分析、全生命周期管理；
應(yīng)用Lava數(shù)據(jù)服務(wù)模塊，將數(shù)據(jù)資產(chǎn)、AI模型發(fā)布為數(shù)據(jù)與AI Rest API服務(wù)實現(xiàn)上層共享。
業(yè)務(wù)收益復(fù)盤
在偶數(shù)科技的方案成功實施之后，該保險公司獲得了以下業(yè)務(wù)收益：
Oushu Lava實現(xiàn)數(shù)據(jù)指標(biāo)一致性管理、數(shù)據(jù)質(zhì)量管理、標(biāo)簽和指標(biāo)體系管理、數(shù)據(jù)資產(chǎn)價值最大化，為降本增效、實現(xiàn)精細(xì)化管理、賦能保險業(yè)務(wù)等起到重要支撐作用
OushuDB實現(xiàn)了傳統(tǒng)數(shù)據(jù)倉庫SQL Server、Oracle所無法處理的海量數(shù)據(jù)、且跑批任務(wù)所用時間大幅縮短近50%；并同時支持在秒級時間內(nèi)為業(yè)務(wù)人員提供交互式即席分析結(jié)果。
4.3 電信行業(yè)案例
企業(yè)概況
某國內(nèi)電信運營商在國內(nèi)31個?。ㄗ灾螀^(qū)、直轄市）和境外多個國家和地區(qū)設(shè)有分支機構(gòu)，并在香港、北美、歐洲、日本和新加坡設(shè)有境外運營公司，是中國唯一一家在紐約、香港、上海三地同時上市的電信運營企業(yè)，連續(xù)多年入選“世界500強企業(yè)”。
該電信運營商提供電話業(yè)務(wù)、互聯(lián)網(wǎng)接入及應(yīng)用、數(shù)據(jù)通信、視訊服務(wù)、國際及港澳臺通信等多種類業(yè)務(wù)，能夠滿足國際、國內(nèi)客戶的各種通信需求，主要經(jīng)營GSM、WCDMA和FDD-LTE制式移動網(wǎng)絡(luò)業(yè)務(wù)，固定通信業(yè)務(wù)，國內(nèi)、國際通信設(shè)施服務(wù)業(yè)務(wù)，衛(wèi)星國際專線業(yè)務(wù)、數(shù)據(jù)通信業(yè)務(wù)、網(wǎng)絡(luò)接入業(yè)務(wù)和各類電信增值業(yè)務(wù)，與通信信息業(yè)務(wù)相關(guān)的系統(tǒng)集成業(yè)務(wù)等。
該電信運營商在英國《銀行家》雜志“2019年全球銀行1000強”榜單上，按一級資本位列第107位、按總資產(chǎn)位列第98位。
數(shù)字化愿景與整體目標(biāo)
近年來，該電信運營商實施聚焦創(chuàng)新合作戰(zhàn)略，開展“一型兩化”布局，聚焦非傳統(tǒng)鏈接、平臺型、應(yīng)用集成型創(chuàng)新領(lǐng)域，快速提升自主研發(fā)、自主集成、自主運營、自主維護(hù)能力。
該電信運營商通過云數(shù)據(jù)平臺建設(shè)實現(xiàn)“1+2”大數(shù)據(jù)管理模式，即“數(shù)據(jù)運營方+管理方+審計方”，在加強數(shù)據(jù)隱私保護(hù)的基礎(chǔ)上，增強大數(shù)據(jù)數(shù)據(jù)資產(chǎn)價值及業(yè)務(wù)創(chuàng)新應(yīng)用，擴(kuò)展運營商大數(shù)據(jù)在客戶畫像、智能推薦等人工智能應(yīng)用領(lǐng)域的深入發(fā)展。
應(yīng)用場景梳理
該電信運營商現(xiàn)有包括話務(wù)流量分析系統(tǒng)、通訊費用管理系統(tǒng)、銀行對賬系統(tǒng)、綜合維修系統(tǒng)、客戶服務(wù)管理系統(tǒng)、反電信詐騙系統(tǒng)、客戶畫像系統(tǒng)等幾十個基于全集團(tuán)數(shù)據(jù)分析的應(yīng)用。
數(shù)字化現(xiàn)狀梳理
該電信運營商已建設(shè)大數(shù)據(jù)智能平臺來推動數(shù)字化轉(zhuǎn)型，其基本現(xiàn)狀如下：
現(xiàn)有大數(shù)據(jù)平臺基于Hadoop Hive 集群近2000個節(jié)點，存儲全國幾十PB級數(shù)據(jù)，上萬張表、上萬個ETL作業(yè)任務(wù)，全集團(tuán)大數(shù)據(jù)隨著5G的發(fā)展增長迅猛，日均數(shù)據(jù)增長量幾百TB；
Hadoop Hive通過讀取大量文本文件每日多次定時從源系統(tǒng)批量獲取源端導(dǎo)出的數(shù)據(jù)；Hive集群每天幾乎不間斷的基于PB級數(shù)據(jù)為幾十個應(yīng)用分析系統(tǒng)的上萬個作業(yè)任務(wù)進(jìn)行跑批運算分析，目前一般在T+3得到跑批結(jié)果，隨著數(shù)據(jù)量的增加，跑批時間在不斷延長；業(yè)務(wù)部門基于大數(shù)據(jù)分析的即席分析時間長達(dá)數(shù)分鐘；
大數(shù)據(jù)平臺中的數(shù)據(jù)資產(chǎn)尚未實現(xiàn)服務(wù)化管理為業(yè)務(wù)人員其他應(yīng)用系統(tǒng)提供數(shù)據(jù)服務(wù)；
只有少數(shù)場景使用規(guī)則引擎和傳統(tǒng)機器學(xué)習(xí)算法實現(xiàn)人工智能預(yù)測。
數(shù)字化需求分析
該電信運營商現(xiàn)有的數(shù)據(jù)基礎(chǔ)設(shè)施存在大量痛點，難以支撐數(shù)字化轉(zhuǎn)型的進(jìn)一步推進(jìn)：
各業(yè)務(wù)部門需要在T+1完成跑批結(jié)果，同時希望進(jìn)一步擴(kuò)大跑批所分析的數(shù)據(jù)量--從現(xiàn)在的PB級到十PB級以上；
業(yè)務(wù)部門需要基于大數(shù)據(jù)分析秒級獲取查詢即席分析結(jié)果，但是目前即席分析時間長達(dá)數(shù)分鐘；
缺少數(shù)據(jù)治理系統(tǒng)工具及完備的數(shù)據(jù)標(biāo)準(zhǔn)，沒有沉淀為統(tǒng)一的數(shù)據(jù)資產(chǎn)；
規(guī)則引擎預(yù)測準(zhǔn)確率比較低、新模型開發(fā)周期長，缺少自動化機器學(xué)習(xí)模型預(yù)測系統(tǒng)和自動打標(biāo)簽系統(tǒng)。
數(shù)字化技術(shù)方案設(shè)計與實現(xiàn)
偶數(shù)科技為了幫助該電信公司應(yīng)對數(shù)字化中存在的痛點，從數(shù)據(jù)戰(zhàn)略、云數(shù)據(jù)平臺整體架構(gòu)、數(shù)據(jù)倉庫及維度模型建設(shè)、數(shù)據(jù)治理和數(shù)據(jù)標(biāo)準(zhǔn)建設(shè)、自動化機器學(xué)習(xí)平臺建設(shè)、標(biāo)簽和指標(biāo)平臺建設(shè)等方面，分別為集團(tuán)本部及省分機構(gòu)完成詳細(xì)的規(guī)劃設(shè)計和實施方案：
圖26：某電信運營商方案
數(shù)據(jù)來源：偶數(shù)科技
應(yīng)用Oushu Lava，以基于HDFS與Hive共享數(shù)據(jù)的OushuDB高性能云數(shù)據(jù)倉庫替代Hive 引擎，基于同樣的PB級數(shù)據(jù)和僅一半服務(wù)器節(jié)點數(shù)（幾百個節(jié)點），跑批性能較Hive提升幾十倍，復(fù)雜即席查詢分析可在秒級完成；
應(yīng)用Lava數(shù)據(jù)治理套件實現(xiàn)數(shù)據(jù)治理，完成數(shù)據(jù)標(biāo)準(zhǔn)管理、數(shù)據(jù)資產(chǎn)管理，與AI Rest API服務(wù)實現(xiàn)上層共享；
應(yīng)用LittleBoy自動化機器學(xué)習(xí)系統(tǒng)深度學(xué)習(xí)算法自動化完成關(guān)于客戶畫像、電信反欺詐等應(yīng)用場景的模型訓(xùn)練、發(fā)布、生命周期管理，顯著提升預(yù)測準(zhǔn)確率、召回率；
應(yīng)用Lava標(biāo)簽和指標(biāo)管理系統(tǒng)，便捷實現(xiàn)標(biāo)簽定義、標(biāo)簽引擎計算、自動打標(biāo)簽、標(biāo)簽展示 、標(biāo)簽統(tǒng)計等。
業(yè)務(wù)收益復(fù)盤
在偶數(shù)科技的方案成功實施之后，該電信運營商獲得了以下業(yè)務(wù)收益：
OushuDB對比原有Hive數(shù)據(jù)分析實現(xiàn)了幾十倍的性能提升，可以滿足業(yè)務(wù)部門T+1獲得跑批結(jié)果的及秒級獲得即席查詢結(jié)果的需求，為業(yè)務(wù)人員針對重點問題及時決策分析提供了強有力的工具保障；
LittleBoy自動化機器學(xué)習(xí)系統(tǒng)提供的模型預(yù)測增強了集團(tuán)客戶畫像、客戶挖潛的能力；
Oushu Lava實現(xiàn)數(shù)據(jù)治理、數(shù)據(jù)資產(chǎn)管理和數(shù)據(jù)服務(wù)化全生命周期管理，實現(xiàn)數(shù)據(jù)價值最大化，使得數(shù)據(jù)及時賦能業(yè)務(wù)部門和數(shù)據(jù)科學(xué)家團(tuán)隊，提高了業(yè)務(wù)部門基于集團(tuán)大數(shù)據(jù)開發(fā)智能推薦的效益。
