智領雲第六次技術直播如約而至。智領雲科技解決方案架構師文徵就數據中臺的行業應用與實踐與與會的觀衆進行了深入細緻的交流。
在前五次的直播中，智領雲科技的諸多技術大咖們分別對數據中臺的一些概念、方法論以及底層所涉及到的技術，都做了很詳細的講解，也介紹了一部分智領雲的產品。在本次直播中，文徵力圖結合數據中臺在各行業落地的具體應用實踐，把前五次直播所講的內容做一個總結，然後就一些大家始終存在疑惑的問題，例如數據中臺與大數據平臺的區別，數據中臺與傳統的主數據的區別等進行結合實例的詳細講解，以幫助大家真正捋清數據中臺的概念。
數據中臺不只是一個技術平臺
根據阿里對數據中臺的定義，數據中臺包含了三項核心能力OneModel、OneID、 OneService。OneModel負責統一的數據結構、管理；OneID負責將核心的商業要素資產化； OneService負責向上提供統一的數據服務，而智領雲認爲數據中臺的核心能力是數據能力的抽象、共享和複用。這兩種對數據中臺核心能力的定義看似有很大差異。但如果仔細分析，就會發現兩者其實殊途同歸，只不過阿里定義的數據中臺的核心能力是智領雲定義的數據中臺的核心能力的結果而已。如果不抽象，如何達成OneModel？如果不共享，爲何要做OneID？如果功能不復用，OneService就無意義。所以說智領雲對數據中臺的定義沒有限制於某一個具體的產品形態或者實現方式，可能更通用一點，可以說是對阿里數據中臺概念的一個更深層次的拓展與詮釋。
那麼，數據中臺主要解決什麼問題？從阿里官網來看，數據中臺主要致力於解決以下問題：
1）各個部門數據重複開發，浪費存儲和計算資源
2）數據標準不統一，數據使用成本高
3）業務數據孤島嚴重，數據利用效率低。
對於這三個問題，我們要先來思考一下。
首先，數據重複開發，浪費存儲和計算資源的問題難道只有數據中臺可以解決嗎？大數據平臺不就是爲了解決這個問題?包括主數據，也是在解決這個問題。
其次，數據標準不統一、數據使用成本高的問題難道不應該也是大數據平臺需要解決的問題嗎？
第三，對於業務數據孤島問題嚴重，數據效率低的問題，難道有了大數據之後，還會有數據孤島麼？還是會有數據利用低效的問題嗎？
這些問題的答案都是肯定的。所以說爲什麼會有數據中臺的概念，主要還是因爲雖然建設了大數據平臺，但上述這些問題卻依然存在。因此，從這個意義上來說，數據中臺本質上還是一個大數據平臺，是個可以實現數據能力的抽象、共享和複用的新型大數據平臺。
但雖然如此，我們還是要思考數據中臺“新”在哪裏？首先，關於抽象。無論是重複利用或者是共享，那到底是何種類型的數據才值得我們去抽象，纔有可能抽象之後去共享、複用？是不是隻要是把數據抽象上來，就能夠做到OneModel、OneID、OneService？就可以成爲數據中臺的一部分？
第二，數據中臺是隻爲共享而服務嗎？共享複用只是數據中臺的最初級階段，通過共享和複用以後，實際上我們可以創造更快、更高、更新的商業模式。所以說數據中臺的作用，不只是爲了共享複用，它還可能會創造更高的價值。
第三，做一個能解決上述這些問題的大數據平臺就可以了嗎？回答是“不僅僅是“。數據中臺不僅僅是能夠解決這些問題，應該還要能從更高，更廣泛的領域和角度去理解數據中臺。
同樣，大數據平臺加主數據等於數據中臺，這也是經常誤導我們的一個概念。但實際上並沒這麼簡單，這是因爲，數據中臺並不僅僅只是一個技術平臺，而是一種思想。
數據中臺是一種思想
就像我們多次重申的那樣，在國外並沒有數據中臺的概念。但其中的原因可能很多人沒有仔細思考過。我們認爲，之所以國外沒有數據中臺的說法，並不是他們不存在我們在數據中臺中要解決的三個問題，而是因爲國外大廠從一開始，就嘗試要去解決這些問題，因此，他們已經經歷瞭解決這些問題的階段，而且是在他們的大數據平臺中就解決了這些問題，而在中國經歷這個階段的時候，由於前期建設大數據平臺時考慮得不夠全面，因此，現有大數據平臺無法完善解決這些問題，纔會在中國出現數據中臺的概念。
那麼，我們應該如何看待一個大數據平臺或者是一款大數據/數據中臺的產品？智領雲認爲，首先就要看這些平臺和產品究竟是如何去實現這種抽象、共享、複用的能力，用什麼樣的方法論、什麼樣的組織架構、什麼樣的產品線去支撐這種能力。如果一開始就是用這種思想去構建系統，數據中臺就應該是自然而然的產生。實際上，我們看到，許多數據中臺的功能其實是爲了彌補以前建設的大數據平臺的不足。爲什麼阿里在做了如此優秀的大數據平臺之後，還要去做數據中臺？這肯定是因爲原來的大數據平臺存在不足。那麼，爲什麼我們建設的大數據平臺會出現這種情況？這纔是我們真正需要進行反思的。如果大數據平臺也出現了煙囪，也形成了孤島。那我們之前所倡導的建設大數據平臺可以打破煙囪、實現數據共享的目標不就是空談了麼。
數據中臺的思想，其實是引導我們用另外一種視角去重新審視我們的大數據平臺，去審視底層資源利用情況，去審視我們自己的業務，審視什麼東西最應該去共享，什麼東西最應該去抽象，它是不是和我們的戰略相關，是不是和我們的主營業務相關。這就是我們最需要思考的問題。
現在，在國外，有一些大廠的大數據或者是雲部門，已經從一個成本部門開始轉變成了一個利潤部門，各部門所消耗的資源已經完全是與產生的效益相關，而他們之所以能夠完成這樣的蛻變，則很大程度上歸功於國內所說的“數據中臺”思想。也就是從更高層次的抽象、共享、複用角度去思考，只有這樣，纔可以更快的去爲前端提供服務，更高效的利用現有的資源。
總結來說，首先，數據中臺不是一種技術，而是一種思想。如果我們還是以大數據或者是大數據倉庫思想去思考數據中臺，肯定是做不好的。其次，數據中臺思想無處不在，爲什麼這麼說？因爲抽象、共享、複用這幾個詞在沒有大數據的時代，甚至是代碼時代就已經存在。難道中間件、封裝的類、方法、庫，不是共享、抽象和複用嗎？數據中臺無非是在更高的層面，從組織、戰略角度去考慮問題，去抽象現在已有的一些組件、功能或者是數據。舉一個餐飲的例子，我們把做菜的師傅暫且理解爲後臺，把收錢的夥計理解爲前臺。我們嘗試着用數據中臺的思想去看一下，在這個體系中是否存在中臺，首先說後臺，做菜的師傅，先把菜切好，前臺報菜單的時候，他就可以快速的通過拼裝的方式，生成一道菜。這裏面的切好的菜、準備好的調料，其實就實現了共享和複用。而菜譜上的微辣、特辣、中辣等信息，其實是對菜的特性的一個抽象，是對放多少鹽，多少辣椒的抽象。而前臺的夥計，除了傳遞做菜信息以外，他還可能要做其他一些事情，比如端茶倒水，傳菜上菜等，如果用中臺的思想，把這些行爲、能力抽象一下，其實就是服務員這樣一個角色。從中臺思想來看，這就是一個數據中臺，起到了承上啓下的作用。因此，當餐飲企業越做越大，服務員羣體就會自然出現，也就是說所謂的數據中臺就會自然而然的出現。
通過這個例子，我們對數據中臺做一個總結，第一，數據中臺無處不在，我們需要用中臺的思想去思考問題。第二，中臺要做的事，其實我們一直在做，只不過大多數人沒有注意，我們只要注意它、抽象它、放大它，就能夠形成一個數據中臺。第三，中臺是一種思想，是一種分析問題的視角，不建設不代表不存在、不需要。
數據中臺的行業建設方法論
那麼，對於需要建設數據中臺的各行業的用戶，到底應該怎樣去做數據中臺？怎樣通過抽象、共享、複用，最後達到OneModel、OneID，OneService這種境界呢？這肯定需要一套完整的方法論。
從智領雲的角度，我們認爲這個方法論有三點非常重要的地方：
首先，是從上至下，先思考的戰略。
我們反覆強調，只有從上至下的思考，你纔不會被一些細節和業務形態所困惑。
其次，要通過戰略，尋找服務主體。
其實，無論是做中臺也好，還是做其他什麼事情也好。如果我們沒有依次思考過它的服務主體，服務內容，服務資源以及服務方式，就倉促的去做，效果肯定不會太好。我們需要以這種思考方式，找出動詞和名詞，從而構建數據中臺。
第三，數據中臺不是一撮而就的。
我們說中臺是一種思想，是從新的角度去重新認識自身的資源和能力，最後將之落在實體之上的過程。而認識也是一個過程，因此，需要採取循序漸進的貫徹始終的迭代思想來進行數據中臺的建設。
直播問答精選
1.對於政府客戶，建成了繁雜多樣的業務系統（100+個系統），怎麼快速實現全域數據彙集和OneID的拉通？
我們的數據門戶產品就是解決這個問題的，數據門戶可以將業務數據庫，數倉，分析程序，數據請求的信息抽取出來，經過整理後形成一整套的數據匯聚和展示。
2. 如何看待數據中臺和數據治理的關係
數據中臺的建設過程中的數據治理是一個關鍵流程，但是數據中臺的數據治理一定是面向全局的，與傳統的單業務域的數據治理是有一定區別的。我們認爲數據中臺的數據治理不一定是一蹴而就，也是可以通過業務驅動，逐漸迭代的。
3. 抽象的對象到底是數據還是能力？
都是必須的，可以抽象數據，也可以抽象能力。中臺思想是需要思考什麼東西可以抽象，可以共享，複用。這是個思考角度。能力包括技術能力、技術能力等。
4. 數倉工程是ETL，數據中臺是ELT，這個技術選型有什麼差異？
之所以有這個ELT的說法是因爲數據中臺一般都涉及到數據湖的建設，在這個過程中一般會先Extract (採集，提取）然後不經修改的 Load(加載）到數據湖，在數據湖之上再來（Transform)到數倉。但是如果考慮從數據湖到數倉的流程，其實還是一個Extract (從數據湖）到 Transform (轉換，匯聚，分析），到Load（加載到數倉）的過程。而且，數據倉庫的建設也是數據中臺建設很重要的一部分，我們認爲ELT和ETL都用得到。
5. 數據中臺和傳統大數據平臺區別，能否理解爲SaaS模式和傳統項目模式？
有這種說法，數據中臺可以理解爲企業內部的一種DaaS（Data-infra as a Service）。但是我們認爲數據中臺的建設實際上也是需要各個業務部門參與和持續維護的，與一個拿來就用的SaaS模式還是有一定區別的。
6. 數據資產或標籤體系有沒有方法論？
在數據中臺時代，不是簡單的元數據管理，應用、API都算資產，什麼用戶用了什麼應用產生了什麼數據，中間加載的過程等，這一切都是數據資產。數據中臺的範圍更廣，只有這樣才能做到將OneID、OneService抽象出來。
7. 傳統數倉服務的對象是數據分析，數據中臺服務於業務系統，能否這麼理解？
首先數據中臺的功能應該是包含數倉服務的，甚至可以說阿里所說的數據中臺的核心就是一個全局的統一的數倉（OneID, OneModel)，然後在上面加上一個OneService。所以準確一點來講，應該是數據中臺可以在統一數倉服務的基礎上服務業務系統。
8. 數據中臺和業務一定相關，那邊界在哪裏？即數據中臺和業務中臺的邊界？
經營活動中的動作（也就是我們說的動詞）是業務中臺提供和實現的，業務所產生的數據是由數據中臺統一管理的（也就是我們所說的名詞）。比如，用戶畫像就是一個名詞，如何使用用戶畫像來實現個性化服務就是動詞。
9. 爲什麼中臺這個概念在中國比較流行，而在硅谷卻沒有這麼盛行？
阿里用這個名詞定義了這個階段，但是這個事情在國外也同樣發生過，硅谷公司在早期就碰到過同樣的問題，國外已經走在前面解決了這些問題，只是阿里把這個階段定義了一個新名詞。但是阿里也是在實際中遇到這些問題，所以才提出中臺去解決這些問題，從而讓國內去重視。大家都會經歷這個階段，所以需要感謝阿里把這個階段用新名詞的方式提出。
11. 有很多企業建立了數據中臺，但是失敗的案例也不少，那失敗的原因可能是什麼？
按阿里的中臺架構圖，就是一個大數據架構，如果按這種理解去做，就是在做大數據平臺，失敗就有可能了。這樣一個架構圖可能令大家有些誤解。業務數據、業務域等並沒有在架構中畫出，但是在背後是非常重要的支撐。也可能是沒有真正理解中臺、或者用大數據架構在套用，從而導致的失敗。
12. 智領雲怎樣幫助用戶建設數據中臺，在中臺落地中起到什麼幫助？
智領雲可以幫助客戶在沒有大數據平臺的情況下從0-1快速落地、持續迭代，或者是基於現有大數據平臺建設中臺的一整套方案，並結合硅谷方法論，幫助企業用戶建設數據中臺，發揮數據價值。