資料管理的演進：從響應業務到創造業務
企業對資料的利用有三個階段：響應運營，響應業務，創造業務。資料中臺解決的是響應業務的問題 ，第三階段“創造業務”，則需要AI中臺。
資料中臺的意義
資料中臺對一個企業，起著至關重要的作用。在資料中臺這個稱謂成型之前，各個企業也都在用不同的方式來儘可能地利用資料產生價值。只是在這個過程中，也不得不處理著資料帶來的各種問題，比如各個業務系統經年累月以煙囪架構形式存在而導致的資料孤島、資料隔離、資料不一致等等。因為這些問題實在是過於繁雜，企業開始建立資料團隊，或者資料部分開始繼續資料整頓工作，因此資料倉庫、資料湖、主資料治理等一系列的工作職能應運而生。
本質上，這些工作都是因為業務需要不得不進行的一系列資料治理的動作，對於如何利用資料來發力，並沒有形成一個強有力的底座。有點像“頭痛醫頭、腳痛醫腳”：各個業務系統規範不一致了，於是開展了元資料治理；資料分析的時候資料關聯不上了，於是不得不進行主資料治理。
這樣的資料治理工作在進行了很多年後，資料中臺這個概念逐漸有人提出了，阿里的《企業IT轉型直到：阿里巴巴中臺戰略思想與架構實踐》這本書更是把用中臺戰略把這個概念推向了一個極致。中臺戰略中，人們常說：大中臺，小前臺。 在這種模式下，頻繁出現的字眼是：共享。那麼，到底共享的是什麼？答案便是資料的服務。 中臺戰略，並不是搭建一個數據平臺，但是中臺的大部分服務都是圍繞資料而生，更加巧妙的地方是中臺戰略讓資料在資料平臺和業務系統之間形成了一個良性的閉環。於是，資料和業務系統融為了一體。
（圖1 資料中臺所解決的問題）
過去，資料依賴於手工進行，沒有軟體；有了資料中臺，以功能驅動，固定的資料輸入，得到固定的資料輸出，構建出能用的服務變得更快速、更加的標準化，解決了業務側的“能用”問題。但是，如何以固定的輸入，以產生更靈活多變的輸出，提供比如個性化的服務，做到“好用”，資料中臺並沒有給出答案。
在建立了資料中臺架構之後，我們逐步認識到，原來資料的價值並不只是個運營出個參考的分析報表，做一系列的預算。資料中臺為大型企業資料利用最大化提供了一個初始的參照方向。當我們發現，深度學習、機器學習等等一系列技術開始在這個平臺下施展拳腳的時候，我們可能已經清晰地認識到：中臺並不是資料分析利用的終點。
企業利用資料的三個發展階段
如果回顧資料分析的歷程，可以歸納發現數據利用大概有如下三個階段：
-
響應運營
-
響應業務
-
創造業務
（圖2 企業對資料的利用，有三個發展階段）
第一階段：響應運營
響應運營是資料分析最直接也是最原始的訴求。沒有誰不不會關心自己的使用者留存率，沒有誰不關心自己的營收額；出現了故障、如何分析定位，如何預測預防，運用資料分析自然不過。但是在運營分析過程中，也發現了另外一系列的問題，比如各個業務系統的資料儲存格式、儲存介質都不相同，在進行基本的運營分析的時候，無法流暢的進行。此時，不得不進行一系列的資料治理。 常見的主資料、元資料治理就是發生在這個階段，只是資料倉庫將主資料和元資料治理進行了規範化。
第二階段：響應業務
資料分析停留在運營階段的時候，對企業來講最大的感受就是投入產出比不對稱。這個問題在大資料爆發的時間點上，更為凸顯。例如在今天的業務場景下，傳統的資料倉庫已經解決不了海量資料、異構資料等一系列問題，而大行其道的大資料分析技術，硬體要求高、學習門檻高。要實施一個大資料平臺，成立一個大資料團隊，這是一個不小的成本開銷，更何況現在有不少資料分析團隊要藉助機器學習等手段，來對資料做分析來響應運營，這導致基礎設施成本、整體門檻進一步提高。
於是像資料中臺這樣的思想就被提了出來：既然資料是從業務系統產生的，那麼是否業務系統也需要資料分析結果呢？對於資料平臺來說，資料平臺本身提供兩大能力：資料儲存和資料計算的能力。那麼業務系統的資料儲存和資料計算能力是否可以剝離到資料平臺，僅僅讓業務系統很輕量的維護自己的業務流程操作？所以利用中臺剝離了複雜的業務環境，再配合微服務等技術，一下子讓人感受到了“資料服務的共享”。
而對業務場景來說，很多時候是需要資料服務的，例如使用者的基本資訊管理、使用者的行為資料分析，這些資料不但可以暴露給業務系統使用，甚至可以直接丟給終端使用者自行使用。類似這種契合點，讓資料平臺變成了一個服務，提供給業務系統。 而對資料服務的使用者來說，在消費資料的同時也在繼續產生資料，這樣在資料平臺和業務系統之間就構成了一個良性的閉環。
第三階段：創造業務
業務不會總停滯不前，因為人的生活會改變，想要的體驗會改變。過去，大家到視訊平臺看視訊，利用通用的資料服務，不同的使用者看到的視訊推薦都是一樣的；很快，我們就會發現根據使用者的偏好，推薦個性化的視訊幾乎是必不可少的體驗要求。然後，我們就開始思考：資料是否可以變成個性化服務提供給終端使用者？這是一個非常簡單、常見的例子。當這樣的個性化資料服務越來越多之後，各種服務不斷組合，就會創造出很多可能性，進而提供創新的個性化體驗和新的業務模式，這就是資料服務用於創造業務的階段。
雖然有了資料中臺，但是當有大規模的、基於智慧演算法的資料服務需要落地實現時，依然會碰到以下挑戰。
-
如何對規模化的智慧服務進行管理：當只是零星三兩個智慧服務的時候，通過手動人工管理等方式，不會有太大的問題；然則， 當智慧服務成千上萬的時候，如何管理、如何構建、如何高效維護，就會成為很大的麻煩。
-
沒有良好的工程實踐來保證質量和流暢性：對於常規的應用軟體開發我們有TDD、自動化測試、CI/CD等成熟的工程實踐做保障；但是在智慧服務這一塊，無論是程式設計開發、還是服務構建，都沒有成熟的工程實踐，也沒有良好的基礎設施支撐，非常依賴於構建這個服務的資料工程師的個人能力，導致在實施過程中，問題難以復現，難於定位。
-
資料安全、治理和資料量不充分：資料中臺的價值點，在於提供了資料的計算和儲存的能力，但是在智慧服務構建下，光有計算和儲存還不夠。治理到什麼程度的資料，才能較好的支撐服務的構建？個性化的服務與資料安全衝突的時候，如何抉擇？資料量不足導致演算法模型泛化能力太差，怎麼辦？
（圖3 創造業務階段，資料中臺面臨的挑戰）
從資料中臺到AI中臺
什麼是AI中臺？
資料中臺本身還是圍繞資料服務來進行的，而非圍繞智慧服務來進行的。未來的作業系統，一定會越來越個性化，甚至每一個人看到的登入介面都不一樣，系統可以根據對應的終端使用者自行呈現符合該使用者習慣的系統介面。那麼 對於這樣的場景和服務，我們需要怎樣的平臺？整個軟體開發架構和流程是否也都會相應重造？
回到創造業務的需求。以簡單的銷售業務為例，資料中臺提供的服務本質如下圖所示：
（圖4 軟體平臺的業務模式）
這是目前最常見的軟體平臺的運作方式，開發人員開發出了對應的軟體服務後，提供給終端使用者使用，雖然會有銷售售賣該服務。這種方式，好比是拿著一個錘子找釘子，而不是給釘子快速製作一把合適的錘子再去售賣。
能不能這樣：將整個軟體組裝出來的服務，包裝成個性化的產品一樣去售賣，提供量身定做的服務？那麼整個運營模式就變成：平臺提供了一種快速構建智慧服務的過程，服務售賣者利用這個平臺，自己動手構建出服務，拿出去售賣，類似一個提供“智慧業務服務的PaaS”。
（圖5 引入AI中臺的軟體平臺業務模式）
如果嘗試給AI中臺下個定義：
AI中臺是一個用來構建大規模智慧服務的基礎設施，對企業需要的演算法模型提供了分步構建和全生命週期管理的服務，讓企業可以將自己的業務不斷下沉為一個個演算法模型，以達到複用、組合創新、規模化構建智慧服務的目的。
藉助一個平臺，將軟體的服務個性化的創造，這將是未來的發展趨勢。在麥肯錫的分析報告中，我們可以看到，各個企業或者行業，都在第三個階段做了不同的探索和努力。
從資料中臺演進到AI中臺
從AI中臺落地實施的方式來看，AI中臺可以是資料中臺的進一步延伸，從資料中臺一步一步演進過去。
首先，從基礎設施角度，可以將資料中臺智慧化
所謂的智慧化，是指將在資料中臺進行的一系列的資料服務構建操作進行智慧化實現，讓資料的接入、儲存、分析展現、訓練、到構建管道（pipeline）都更加自動化。例如，對於通用的CI/CD來說，測試不過則會構建失敗，那對於AI中臺下，就要考慮一個推薦模型構建失敗的條件是什麼？答案可能是“本次模型的準確率低於上一次構建的準確率”的時候，CI應該被構建失敗。在實踐中，這可能是CI構建過程的維度之一，還會有很多其他指標和維度。我們就需要在現有的資料平臺的CI中，實現並自動化這些指標和維度，使之更加智慧化。
其次，對於中臺使用者來說，將煙囪式模型構建過程改造為可複用的模型構建過程
目前基於資料中臺的一個智慧服務模型開發來說，流程如下：
（圖6 煙囪式模型構建過程）
這基本類似於一個橫向的煙囪架構，導致目前對一個基於演算法模型產生的服務進行拆分的時候，都不是特別地順暢。如果大部分業務場景依舊以流程為主還好，如果新業務需要引入多的智慧服務，那麼一系列的問題就會暴露出來：
藉助於現有資料平臺手工進行資料操作
煙囪架構開發，對人員能力要求高
環節無法有效拆分，響應週期慢
智慧場景規模化，管理複雜
訓練，部署，釋出依賴於手工部署缺乏有效的流水線
和資料平臺孤立，缺乏統一的資料服務介面
基礎設施隔離，無法動態進行資源的分配和管理
AI中臺需要具備構建智慧服務的能力，就要求我們對服務構建的過程進行如下拆分：
（圖7 可複用的模型構建過程）
首先需要從基礎設施層面進行整合。常規的資料中臺依賴於大量的CPU和記憶體，相反，機器學習模型對GPU的依賴反而更高，但是又不能脫離資料中臺，因為它依舊需要利用資料中臺的儲存和計算能力來處理大量的資料。所以如何通過一個介面、一個排程器、一個管道pipeline來整合整個工作流，就成了需要考量的事情了。
AI中臺至少應該分為以下幾個層級：
基礎設施：對CPU做虛擬化的技術已經相對成熟，但是智慧服務依賴的更多的是GPU，那麼GPU如何做虛擬化，演算法模型訓練和資料是否需要共同使用相同的機器，還是叢集相互隔離，都是需要在一開始設計好的。
資源管理：一切都是資源，無論是網路、記憶體，還是資料、服務，都是資源。對於模型構建者，關注的只是演算法本身，如果該構建者需要資料，那這樣的資料就是一個資源而已，無論資源是以環境變數的方式提供、還是以服務的方式提供，構建者本身並不需要關心。此時，必須一個資源管理系統，對資料服務進行統一管理。
中臺和模型：中臺有資料的計算和儲存能力外，還應該具備算模型的能力，這裡的模型指的是一些業界通用的、或者企業級通用演算法模型。它可能是一個演算法、可能是一個別人已訓練好的模型，可以使用遷移學習的方式去使用。對於中臺來說，它都是一個數據集的體現，不應該和一個表，一個檔案有特別的區分。
流水線：流水是構建規模化智慧服務非常重要的一個環節，工作如其名，讓我們構建智慧服務的時候，可以像流水線工作一樣，達到這樣的效果，則需要對整個任務進行非常詳細的分解。
智慧應用層 ： 智慧應用層直接面向終端，怎麼利用元資料等功能，組合各自不同模型提供的服務，構建出組合效應的創新服務。
（圖8 AI中臺的架構層次）
在資料中臺的基礎上，擴充套件對GPU級別資源的管理和整合能力，排程層提供統一的任務、服務、智慧CI/CD等服務，來實現AI中臺。這樣以來，就可以達到：
和資料平臺結合，利用資料平臺的能力作為資料支撐，最大化的發揮資料平臺的價值
拆分服務構建環節，智慧服務開發流程化，快速響應業務需求
利用元資料管理方式，提供統一的標準格式，場景可以多人協同配合開發
基礎設施共享化，模型的訓練和釋出與資料平臺有效繫結，服務的構建自動化
統一的元資料管理系統，模型的全生命週期可管理
通用AI能力平臺化，降低人員要求，提升協作效率
也即，利用算、模型、框架，動態、快速地組裝服務，創造出新的個性化體驗和新的業務新的業務模式，解決“好用”的問題。
結語
資料中臺提供的是儲存和計算的能力，基於不同的業務場景，構建出了用來支撐不同業務的資料服務，依託於強大的計算力，可以快速縮短獲得結果的週期。而AI中臺則是將演算法模型融入進來構建為服務，讓構建演算法模型服務，更加快速高效，以更加面向業務。但無論是資料中臺還是AI中臺，都是一層基礎設施，做好基礎設施只是第一步，如何讓它的價值最大化，還要依託於AI中臺不斷結合業務來持續優化，做到“持續智慧”。
銀行與金融科技融合的理想境界是什麼？是銀行即服務。 伴隨著開放銀行在國外愈演愈烈 ，中國作為全球金融科技的領先力量與深度參與者，迅速燃起了對開放銀行這種平臺化商業理念的研究與試錯。
銀行、網際網路巨頭、金融IT服務商、金融科技創新公司、消費金融公司、保險機構等都迅速入局， 試圖通過與商業生態系統共享資料、演算法、交易、流程和其他業務功能 ，為商業生態系統的客戶、員工、第三方開發者、供應商和其他合作伙伴提供服務，使合作雙方創造出新的價值，構建新的核心能力。金融科技作為以新技術為核心的創新，立足於新理念、新政策將形成澎湃的力量，重塑中國金融產業新生態。
2019年6月14日，億歐智庫研究院將在“2019丨全球新經濟年會·金融科技峰會”上釋出《 2019開放銀行與金融科技發展研究報告 》，深度解讀金融科技賦能開放銀行的融合與落地應用——上海·虹橋·世貿展館邀您見證！搶票連結： https://www.iyiou.com/post/ad/id/792
本文已標註來源和出處，版權歸原作者所有，如有侵權，請聯絡我們。