寫數據中臺第一帖，首先來個開篇明義，希望不要閉門造車。
由於很多同行在聊中臺，那麼這裏我們聊中臺需要做到有差異和有真實背景。這個帖子是基於建設銀行廣州開發中心、廣發行數據中心的一些情況來聊的。目前各個國有大行、股份制銀行在大數據方面的投入很大，寄予希望通過數據產業推動業務升級、推動生產和管理上的改革和進步、促使效率提升和產業結構變化。
建行廣開申請下來大量服務器，搭建起很多組件的集羣，CDH集羣、FI集羣、storm集羣、ES集羣、spark集羣、ELK集羣、Redis集羣、Flink集羣等，並且有些集羣還有多套（AB角），例如FI集羣就有多套。
然而這些集羣似乎沒有完全應用起來，存在空置狀態。但並不意味着大數據的應用已經做到盡頭，而相反的是，基於大數據的很多應用的成效並未達到銀行的預期，還沒有做到通過數據化運營來推動業務的快速升級。
大數據還在一個“變現”的階段，多年來年的積累和努力集中在於建立一個大數據平臺（相當於池子），積蓄和儲存數據（相當於水）。而數據的應用比較多的是在銀行風控和銀行營銷方面的實踐。目前發展空間還是比較大。那麼下一個階段的大數據究竟是怎麼樣的形態。
參考阿里提出了“雙中臺”規劃，一個是業務中臺，一個是數據中臺，銀行又應該如何建立中臺。這就是寫這個文章的出發點，並且努力做到不空談不妄言，把銀行的實際情況分享出來。那麼我們就以此爲引子，來開展關於數據中臺的探討。
與數據中臺相對應的銀行內部架構應該怎麼樣
把具體的中臺的規劃、目標都放到後邊去聊。這裏先想想一個問題。當數據中臺和業務中臺都構建好了之後，銀行的內部架構會變成怎樣。想想康威定律，這必然是一個很有趣的話題。
廣發行的混亂
廣發行的開發中心和數據中心都在廣東佛山千燈湖的金融中心。數據中心做大數據平臺的建設和基於大數據的應用，而開發中心做各個業務渠道，包括對公、個人、信用卡等的應用系統。
然而這個過程並不無混亂。
前端時間傳出，開發中心已經在構建自己的大數據平臺，和數據中心的大數據平臺存在一定的重疊。另外原本劃分在數據中心的風控應用系統及其開發團隊，因爲各種原因被劃分到了開發中心。因爲風控劃分在數據中心時，整個風控的調用鏈路過長而不好控制響應時間；也因爲數據中心存在需求響應速度和質量控制不好的問題而備受業務部門的非議。所以才存在這種業務上的調整。
然而其中肯定是有值得商榷的地方的。因爲風控的數據來源於大數據的風險畫像，很多指標和標籤的計算都在大數據離線批次中完成。並且風控過程也可能存在實時流的計算和加工。這些就是數據開發能力的一部分。所以劃分到開發中心後，就存在了業務邊界模糊的情況了。
幸好這個過程還是比較良性的，相信調整的方向是往更好的協作方式去走。
建行的混亂
建設銀行的開發中心劃分爲北開（北京開發中心，位於稻香湖附近）、廣開（廣州開發中心，位於科韻路）、廈開（廈門開發中心）。
也許是建行總行的鼓勵內部競爭策略或其他的出發點，各個開發中心之間的業務是存在相互爭搶的。例如廈開偏重數據倉庫（EDW）的建設，而廣開偏重於渠道上的應用建設和維護，但廈開會做應用、廣開也會建設數倉和大數據平臺。相互之間既是建行這個大架構中的重要組成部門而完成整個銀行的業務，但又爭搶着基於大數據的應用建設業務。這是不利於架構調整的。
而中臺的構建能不能作爲一把錘子，重錘打破這種格局。
理想中的銀行架構
基於上述總總，我們聊聊，銀行的企業架構的理想狀態是怎麼樣的。業務部門-開發中心-數據中心應該如何分工。然後我們再去聊中臺應該怎麼開展。
無論中農工建交這些國有大行，或如廣發、興業、浦發這些股份制商業銀行，又或者是城商行、農信等，都需要清晰劃分數據中心的業務邊界和開發中心的業務邊界。數據中心對應的是數據中臺、開發中心對應的是業務中臺。
按照不同銀行的合規要求，對行內各部門各渠道的數據採集可採取離線或實時的方式，而對行外第三方數據的採集，出於安全的要求，可通過開發中心的接口進行透傳採集。那麼就可以做到統一的全行性的採數。
然後進行ETL、然後存入大數據分層中。
然後就是數據探索、數據開發。而數據開發加工分爲批量離線加工、內存計算加工、實時流計算加工。
之後是數據模型建設，包括建模過程管理、統一模型管理、模型驗證等。
之後是對數據資產的管理。包括依賴管理和血緣管理。
最後，數據通過統一的服務中間價對外提供數據和消費數據。產生數據的價值。
如果，這裏是說如果，銀行的分工真做到丁是丁卯是卯，數據中心只管理數據，開發中心只管理應用。那麼數據中臺和業務中臺就可以真的定義好各自的邊界了。
待續。