1
中臺化前的產品現狀
在項目早期我們公司提供的服務就是在線酒店預訂，這種業務模式的整個流程也不復雜，主要分為這幾個環節：
BD進行拓店 -> 邀請酒店入駐平臺 -> 平臺上架 -> 用戶下單 -> 分傭
重點來看第一個環節，BD拓店實際就是將線下的酒店住宿服務當做商品“進貨”至公司的後臺中，從而為後面整個服務奠定基礎，這裡也是整個業務的核心與數據唯一進口。
在這個環節中公司由BD與商務團隊維護並積累的大量底層“商品”數據，而初期這些底層數據在數據庫中，就是簡單的以“Key=Value”形式進行存儲。
圖：存儲字段截取
當經過一段時間的積累後，這種數據存儲方式由於維度簡單導致的結果，就是整個數據庫的數據量在很短時間內出現猛增。
但是雖然看著每天都有“商品”數據入庫，慢慢的我們卻發現這些數據很多都是沒有辦法進行二次使用的，只能供特定的業務方進行獨立使用。
具體來說，在公司內部我們通常會有多個業務團隊，每個業務團隊往往都會根據自己的業務需求在數據庫中建立一張屬於自己的數據庫表（這裡為了行文方便我們視作一個表），這些表的業務數據字段與定義方式都是按照業務方定製化進行的。
例如在當時我們的酒店預訂就分為兩個業務團隊：
- 非標住宿預定，也就是民宿；
- 標準酒店預定；
所以此時在後臺我們有了兩套業務數據體系，這些數據都是這兩個業務方進行自主定義的。
2
挑戰：業務線
這樣的數據看似很尋常，目前很多企業也是這樣對內部團隊管理的。但是對於這種我稱之為依託於前端統一團隊的業務來說（兩個業務方由統一的一群BD去進行掃街），我們實際上去做的就是將已經標準化了的數據（酒店錄入數據）再次人為進行了割裂，變成了兩個獨立的業務數據庫，如下圖所示。
圖：人為數據分流
我們要知道很多企業平時日常所做的工作大多數都是在進行數據的遷移與整合，如：將用戶行為數據與用戶唯一標識數據結合，從而唯一確定分析這個用戶的喜好。
那麼也就意味著我們每破壞一次數據之間的關聯性就意味著，為後期增加了一次需要進行反向操作，也就是將數據進行合併的工作負擔。特別是我們將酒店天然性以業務牆進行了阻攔，更是破壞了數據的強關聯性（同類數據）。
同時這樣的數據也使得對於既屬於民宿又屬於標準酒店業務庫中的數據成為總庫的冗餘數據，曾帶來的一個很嚴重隱患就是當民宿業務線的運營同學發現酒店名稱發生改變並變更後，我們另一端的運營同學很難去即時發現並處理，此時在標準酒店業務端出現了多次用戶下單後，該酒店因為店名與實際店名不統一，而旅客無法入住的情況，並多次投訴平臺。
當然這只是若干次業務數據管理中的一個小小的縮影，正是因為這樣的意外挑戰出現，讓我們對於現有的數據管理方式產生了要去進行變革的意圖。
3
挑戰2：創新業務
我們知道絕大多數互聯網的產品本質就是以不同的展示形式、遞進次序陳列出不同的數據，滿足用戶的信息需求。如新聞網站與今日頭條都是在展示新聞數據，而陳列的次序一個是按編輯維度，一個是按讀者的閱讀習慣維度。
那麼也就是說只要有了數據源，我們在這基礎上就可以衍生出不同的產品。我們原公司業務也不例外，在我們收集了一段時間市場的酒店信息後我們就想著可以用這些數據來組織些新的產品，以此來滿足不同細分市場人群。
如將酒店的基本信息數據（照片，介紹等）與第三方遊記攻略類數據共享，提供數據輸出服務。和想分析現有的數據的數據預測服務：根據不同地區的新增房源數據進行旅遊真實熱門景區排行。
這個時候面對之前分散的非標住宿預定與標準住宿預定兩個獨立業務，我們更想要看的兩個業務線彙總後的全維度數據，而在現有條件下這個變得必須要逾越兩個業務線的阻隔。
4
業務中臺解決方案
面對這樣的幾個挑戰，我們的選擇就是利用中臺去進行解決，此時中臺1.0是這樣構建的：
步驟1：中央集權
將酒店數據剝離各業務線團隊，把酒店數據存儲至獨立的數據中心（也就是中臺1.0）進行維護，打破各團隊隔離，此時將原有的環節改為：
BD進行拓店 -> 邀請酒店入駐平臺 -> 數據中心 -> 平臺上架 -> 用戶下單 -> 分傭
而在新增數據中心進行統一維護後，面對各自團隊的數據需求我們可以在數據中心劃分為虛擬數據源用以進行支撐。
圖：改版後的虛擬數據源
酒店數據與各個業務線生成的訂單等數據都彙總到數據中心中，數據中心是整個企業的基礎服務提供全局的數據。
步驟2：特異性管理
接下來讓我們來分析下整個業務運作流程，在原有兩個產品線的業務模式與創新產品的業務模式中，當我們以數據流轉的整個視角來看，本質上這些業務就是下圖所示的數據流（此處的客戶終端也稱之為前臺）。
圖：未中臺化前的前後臺系統
不難發現，在這裡作為數據源的提供方為業務方做了兩個步驟的工作：
- 數據取用：根據業務方所要的數據範圍提供數據（如：本次業務需要讀取會員ID，會員姓名這兩個字段）；
- 數據業務格式化 ：根據業務方所要的數據格式進行特定數據格式/順序生成返回（如：業務方A返回數據格式：會員ID=“12311”+會員姓名=“張三”；業務方B返回數據格式：會員姓名->“張三”and會員ID->“12311”）。
對比這兩個步驟的工作我們就能發現第二個步驟實際上是原來整個後臺支撐系統額外的工作的罪魁禍首，像上文提到的每次數據接口只能為一個業務方提供服務，這個接口由於數據返回格式是特定的所以具有很強的特異性，導致後臺同學需要不斷進行新的提供數據的接口的開發。
對於不懂技術的同學，我們可以理解為後臺同學在提供同樣的信息而先後順序不一樣時，需要設計不同的傳輸通道。
大家可以看到這無疑就是巨大的浪費。大家可以回想下在自己的日常工作中這樣的情況是不是也相當常見，例如：產品迭代中每次版本更新導致的需要重新設計接口（新舊產品就同一數據的不同封裝形式的取用）；老版本數據接口與新版本的同一數據接口不同，需要分別維護。
所以當時我們是這樣解決的，這兩個步驟中第一個服務共性很高，很容易抽取成公共服務，我們就數據中心提供了一個標準的取數據接口，各個業務方只需要傳輸需要什麼字段名稱，我們的統一數據返回接口就把數據返回至業務方。
這樣在所有的版本中我們始終對同一批相同功能的接口進行維護（為了負載均衡），各個接口沒有任何特異性都是標準的取數據接口，只根據請求內容進行內容返回，這樣大大減少了開發量。
對第二步驟由於特異性特別高，我們將這種與業務強相關的東西下放到業務端，由業務方進行數據處理，加工成他們需要的組織形式再返回給客戶方。
此時後臺人員只需要開發面向數據源的數據輸入接口，也就是將BD採集的數據進行清洗成為中颱的原材料。
而數據中心也就是中臺，將各個業務數據彙集到這裡並提供統一的取數方法，前臺業務人員根據需要去申請數據。
最後將原來數據後臺統一處理這一動作劃分為：數據獲取（中臺）與數據業務端組合（前臺）兩部分。
而整個系統的架構也就變成了如下圖的樣子：
圖：1.0中臺系統架構
5
最後
在最後給大家一個個人理解中臺戰略，特別是業務中臺的搭建是一個高度定製化的戰略，如果我們想要發揮中臺化戰略的最大價值，就需要依據不同公司、不同業務、不同階段的特徵去定義與動態調整中臺演進方向。
就像本文的酒店數據中心案例一樣，只有最適合當前業務的中臺框架，才是真正的解決方案。
作者：三爺 產品經理進階指南
