再談資料中臺是什麼以及MLSQL為什麼可以作為資料中臺
昨天還是前天，正好看到朋友圈裡大家都在發AI前線推的一篇文章。 資料中臺已成下一風口，它會顛覆資料工程師的工作嗎？ , 個人認為風口談不上，但是確實是技術發展到一定程度的產物。這裡的技術不僅僅是大資料，也是後端，前端技術前進的共同產物。N年前我們是想都不會想這件事情的，因為技術上很難達到。
文章認為資料中臺出現的原因是為了彌補資料開發和應用開發嚴重不匹配而出現的。這其實只是一方面，資料中臺真正出現的原因其實是因為人們對資料的渴望，但是這種渴望超出了傳統大資料模式（響應式需求，把渴望轉化為需求，傳達給資料研發，演算法，分析師等）能夠承受的範圍。我個人認為傳統大資料的服務模式嚴重壓制了人們對資料的需求，甚至連最簡單的【取數】都要以天響應時間計算，所以很多模式要重構。而中臺的產生則是這種模式重構的產物。
資料中臺我認為應該有如下幾個特點
-
資料中臺整合一切內外資料。中臺底層的資料組織不再侷限於集中式的資料倉庫，資料倉庫只是中臺的一個數據源。中臺表現層面的資料形態是聯邦制的，大家可以參考我這篇文章： 資料部門起步階段需要建立數倉麼？ ，這裡面對資料的整合做了比較詳細的描述。
-
資料中臺整合一切內外服務，這種服務形態可以是UDF函式，可以是ET(MLSQL術語，Estimator/Transformer縮寫)。在資料中臺中，除了傳統資料部提供的服務以外，還包括公司內外一切API服務，你可以利用這些API服務幫助你進行資料的探索，加工。這也得益於後端的微服務化，以及類似k8s排程的興起，讓後端抗壓能力越來越水平。印證了我前面說的，資料中臺是前端，後端，資料發展的共同產物。
-
資料中臺是可程式設計的。任何托拉拽最終的結局都是無法滿足新的需求，需要根據需求開發，所以在中臺提供了一個可以涵蓋批處理，流式計算，機器學習，提供API開發等統一一致的語言是必要的。同樣的，這個語言還要能很好的和其他語言，比如Scala/Java, Python等進行互動和整合。同時，這個程式語言要足夠簡單，才能面向產品，運營，商務等非技術體系的同仁。
-
資料中臺不僅僅與人互動，還可以和機器互動。這是什麼意思的呢？ 資料中臺是產品，運營，商務，分析師，後端，前端，演算法，資料研發們的日常工作臺，同時他們也可以把自己的寫的指令碼（工作）在資料中臺裡直接對外提供成API,簡單的form表單，從而實現和其他的服務互動。
當然，從資料中臺要解決的問題，我是認同前文作者提到的三點的：
- 效率問題：為什麼應用開發增加一個報表，就要十幾天時間？為什麼不能實時獲得使用者推薦清單？當業務人員對資料產生一點疑問的時候，需要花費很長的時間，結果發現是資料來源的資料變了，最終影響上線時間。
- 協作問題：當業務應用開發的時候，雖然和別的專案需求大致差不多，但因為是別的專案組維護的，所以資料還是要自己再開發一遍。
- 能力問題：資料的處理和維護是一個相對獨立的技術，需要相當專業的人來完成，但是很多時候，我們有一大把的應用開發人員，而資料開發人員很少。
所以我認為資料中臺並不是前臺，中臺，後臺裡這樣的中臺概念，而是一個”中軍“的概念。 實際應該是這麼一個東西：
image.png
摒棄傳統模式，我們應該把前臺，後臺，以及所有的非研發序列的人，都劃分為業務層。 再下面是資源層，包含內外資料，內外計算，所謂內外計算包括前臺，後臺已經有的API介面，也包括大資料部的各種演算法，資料介面。
也就是說，資源層其實是前臺，後臺，還有人的積累下來的東西，現在我們通過資料中臺，以極高的效率重新反哺前臺，後臺，非研發序列。我們希望前臺更加敏捷創新，不依賴後臺，而是依賴中臺。我們希望後臺能進行更好的資料積累，穩步前進，不受前端影響太大，同時從中臺獲取幫助，從中臺獲取前臺傳導的訴求。我們也希望人能更好的和資料，和計算進行互動，並且通過中臺更加高效的和前臺，後臺協作。
MLSQL高度滿足前面提到的四個點，並且是按照中太的概念進行設計的一些列產品（目前是三套件）。大家可以參看最新的一些內容：
- 一鍵體驗MLSQL產品 http://docs.mlsql.tech/zh/installation/docker.html
- 手動部署MLSQL三套件 http://docs.mlsql.tech/zh/installation/compile.html
- 產品和運營如何利用MLSQL完成excel處理 http://docs.mlsql.tech/zh/action/mlsql-excel.html
- MLSQL初學者常見問題集錦 http://docs.mlsql.tech/zh/qa/
- MLSQL Console介紹 https://www.jianshu.com/p/b75e1a510a76