大前台是一個容易自然發展成的樣子，業務需求一着急，如果沒有輪子，隻要有人力，自己造一個是最快的，重度貼合應用場景。因為無需考慮太多适配，最大程度、最快的滿足業務需求，确保業務不會等着技術評估合理性。這種現象是自然進化的優勝劣汰？還是熵增導緻的無序混亂？

大中台的概念，第一次接觸是在關于架構的思考 - 評《阿裡巴巴中台戰略思想與架構實踐》這本書裡。Supercell 可以快速開發一款新遊戲，原因是因為研發、數據能力的快速複用，阿裡借鑒了這個思路，提出了中台的概念并且受到追捧。

但我們也無法忽略當時的背景：阿裡原有淘寶，又新發展了天貓，兩者有很多相似之處，數據上共享能夠獲利、技術上沉澱能夠降低人力成本，所以自然的想法是有一個基礎部門統一支撐。然而事與願違，這個部門根本做不起來，大概會有以下這些問題吧：

1. 做誰的需求、不做誰的？優先級怎麼排？
2. 部門的核心價值就是實現需求麼？哪些需求接，哪些需求不接？怎麼融合用戶當前需求與長期計劃？
3. 需求排期多久是合理的？業務方抱怨怎麼辦
4. 人是淘寶原有的部門過來的，接需求時，怎麼合理、公平的對需求而不對人

最重要的，站在業務方的角度：如果有可能不支持/支持慢，那前台為什麼要通過中台？

印象特别深刻的是這張圖：

直到聚劃算出現，天貓、淘寶都紛紛要求接入，阿裡決策層強勢要求必須通過中台，算是給了中台一個強力的政策扶持。

所以可以得到這個結論，能否建成大中台，取決于幾個條件：

1. 多個前台的現狀或者發展趨勢，比如 Supercell 有多款遊戲，阿裡有淘寶、天貓、1688、閑魚
2. 決策層的支持：避免隻是停留在口頭上
3. 業務抓手：避免沒人跟你玩兒，中台成了空中樓台

首先中台不是一個舶來品，是阿裡造出來的，為了解決煙囪式開發、孤島、各自為戰的問題。我在讀那本書的時候，其中有兩點印象深刻：

1. 理想很豐滿：中台是一個中場發動機，能夠随時派遣出來多隻先鋒隊，負責在各個方向開疆拓土，中台提供裝備（已有的研發能力、各部門數據、統一沉澱的規範）
2. 現實很骨感（最初）：淘寶、天貓兩個部門，完全不鳥中台，直到行政命令必須通過中台接入聚劃算

矽谷的大數據平台基本等價于阿裡宣傳的中台，都是避免重複造輪子、快速疊代、數據驅動、業務驅動。 但是由于阿裡運營中台的概念太成功了，所以很多文章都會介紹中台、平台的差異。

所以僅在溝通時避免混了中台、平台即可，實際上目标都一樣：統一、規範、共享、複用。

數據倉庫是數據中台的一部分，數據中台責任更大：提供數字化運營的能力，能夠指導企業下一步該怎麼做，在市場競争中獲得優勢，通過數據比對手更了解用戶、成本更低、洞察市場等等。

然而知易行難，大家都知道這些能力的好處。但是也有很多問題：

1. 公司現在沒有那麼多煙囪開發，有必要提前統一麼？
2. 我們業務的數據自給自足，開放出來浪費人力
3. 業務自身開發排期都滿了，沒空配合大數據
4. 我們并不是想要重複造輪子，隻是業務部門不給數據、大數據部門也産出不了，所以隻能自己再開發一遍

這幾個已經超出了技術的範疇，是想法不一緻、理解也不統一，單純靠中台解決不了，就像是阿裡中台最開始的窘境。

但是多想想也有好處，那就是大數據中台相比其他中台，我覺得有兩點特殊性：

1. 幾乎涉及公司所有部門，以及要跟CEO、CMO、CIO、COO一起探讨如何用數據為企業産生價值。
2. 各部門之間通過數據中台共享數據，既是數據的使用者，又是數據的提供者，既有數據需求，又有數據産出。因此不能簡單的認為業務部門是需求方。 所以跟各部門的牽扯确實是更深一些。

書裡給了一套方法論，按照我的理解介紹一下：

1. 業務驅動、快速落地：能讓業務嘗到甜頭、感受到大數據的技術深度和解決問題的能力，這個有點一線實踐智慧的感覺。
2. 頂層架構設計及數據規範：架構即流程，數據怎麼流轉，用哪些技術棧；規範即條文，數據怎麼定義，類型、名字、注釋等等。但是我們面對的是一個變化的環境，可能有些數據最開始很難判斷是否要沉澱到數據中台，怎麼辦？要有流程支撐，比如Twitter通過自身的數據架構委員會來衡量哪些數據能力可以複用
3. 平台管理：底層的平台和工具要好用，這是最起碼的立身之本。比如實時、離線計算平台；任務調度平台；監控報警通知等，避免人為操作，大家用了都覺得省事省力省心
4. 權責明确：牽扯方衆多，先明後不争，事前說好，别事後甩鍋埋坑推诿，搞的大家不痛快
5. 安全、高效、穩定、可擴展：老生常談了

如果要定義數據中台的話：

數據中台是企業數字化運營的統一數據能力平台，能夠按照規範彙聚和治理全局數據，為各個業務部門提供标準的數據能力和數據工具，同時在公司層面管理數據能力的抽象、共享和複用。

4. 數據中台的例子

書裡介紹了 Airbnb、Twitter 的例子，重點說下 Uber。Uber 開源了非常多的優秀框架，比如我們在最開始做 SQL 實時計算平台的時候，就參考了 AthenaX1

摘抄部分 Uber 大數據平台的演進曆程2:

上圖為第二代架構，通過引入 Hadoop 生态，所有數據服務都支持橫向擴展，能夠支持到數百 PB 的數據量。

上圖 2017 年開始搭建的第三代架構，主要解決的不足：

1. HDFS 可擴展性：大量小文件、數據量d逐漸增大（50~100PB），雖然有一些簡單方案可以解決這個限制。
2. Hadoop 中的數據的時效性：T 1不能滿足時效性需求
3. Hadoop 和 Parquet 中的數據如何更新：如果不支持，就隻能 T 1 merge 一次。（3 其實是分析問題 2 之後的原因之一？）
4. 更快的 ETL 建模：為了降低延遲，因此引入增量模式

其中核心點在于引入了Hudi(Hadoop Upserts anD Incremental)

5. 選型：自研、開源、雲原生

如何選型考慮的因素非常多，所以經常看到同一個問題不同公司的不同解法。

自研主要是提供個性化的支持，例如對接公司的 passport/代碼庫，審計的需求、使用習慣等等。

開源比較适合項目初期，穩定性要求不高，個性化需求也不多，主要用來快速構建，甚至不用讀代碼，看看 ReadMe 就能搭建一個服務出來。但是出來混，遲早要還的。項目有 case，性能要提升，還是得去深入了解。所以開源軟件并不是“萬應靈藥”，也有很多問題和陷阱，我們經常會看到“（開源）×××實戰蹚坑”之類的文章。矽谷的很多大數據公司，如Confluent（Kafka）、Cloudera（Hadoop）、Databricks（Spark），都是建立在為用戶解決此類問題的商業模式上的

很多開源軟件的模式是讓不付費的用戶使用，在這個過程中由社區不斷完善軟件，付費用戶向開源軟件公司購買高質量和高保證的服務，實現三赢。但是，開源軟件不等于免費軟件，不付費用戶實際上也付出了一定的成本：決策風險、機會成本、人力成本、管理風險、運行風險等等

進一步的，我覺得另外一個隐藏的風險點，就是即使使用了付費版，可能能夠解決穩定性兜底、性能提升的問題，但是：

1. 付費版是統一版本，能夠适配到現有的使用習慣麼？比如是否接入 LDAP、如何對接公司其他自建平台
2. 對方支持的力度有多大

很多成熟的開源軟件，已經被大公司主導，主要是：

1. 從 issue、discussion、code review 都需要已有的 commiter/PMC 參與以控制代碼質量，而很多 commiter 本身是雲廠商的人
2. 雲廠商已經支持了一些付費功能，這些逐漸的、部分的釋放到開源社區裡，本身是需要也是受歡迎的 所以這種共赢的方式，為雲廠商構建了一層越來越堅實的技術壁壘。

雲原生架構是一種利用雲計算優勢來構建和運行應用程序的方法。它是一個技術和方法論的集合，包含4個要素：微服務、容器、DevOps、持續集成和持續交付（CI/CD）。

當面臨自研、開源的難題時，雲原生似乎成了一個絕佳的選擇，但是也要考慮好，面對大數據的衆多組件時，這三者不應該是隻選其一的關系。

6. 參考資料

1. AthenaX
2. Uber 大數據平台的演進（2014~2019）

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部