編輯導語：這幾年不少企業都做起了中臺業務，搭建自己的數據中臺；數據中臺把數據統一之后，會形成標準數據，再進行存儲，形成大數據資產層，進而為客戶提供高效服務；本文作者分享了關于輕量級數據中臺構建思路，我們一起來看一下。

好久沒寫文章了，一來是為了雙11大考在做長期的優化、迭代，確實無力靜下來寫；二來想了很久這篇文章該寫數據產品，數據中臺還是寫接口；最后決定把兩種業務結合一下，后續會投入精力做新的業務，所以整理了下思路，寫了這篇文章，也算是給自己這一年的工作暫畫一個句號

大部分同學可能涉及業務層偏多，再一些做c端的同學甚至工作內容更依賴運營思維；不過我相信互聯網公司里隨處可聽到接口這個詞，我也隨機問了身邊的一些同行朋友，可能大家對接口這個詞的定義就停留在了數據傳輸這個層面，往深層次考慮的話就會覺得api與產品關聯不大“那不是技術該做的事嗎？”——實則這話也沒錯，當然筆者因為是負責整體部門所以也必須要從產品角度去深挖api的實現邏輯。

今天我們不提偏技術的話題，比如http、tcp協議等，網絡交互層面的邏輯有興趣的同學可以自行百度，這方面的技術軟文還是比較全面的，挑選寫作方式更易自己理解的文檔去閱讀。

還是那句話——做產品，對于一個業務的入門很重要，往往決定你個人能力的天花板和整條業務線的走勢，一定要有深挖底層實現的精神，樹根扎實枝葉才能伸到更遠更高的地方。

廢話不多說，我們今天就從感知最明顯的實現層來聊聊api，其實我個人剛接手這個業務時也有這個疑問，接口部門需要產品嗎？產品能做什么呢？接口不就是獲取數據嗎？等疑惑。

其實換一種思路你可能會考慮的更容易，你可以把你的定義放在偽“數據產品”；相信這個詞大多數同學也都有所耳聞，畢竟整個時代正在從it向dt發展，很多同學都想從事進來但覺得門檻過于神秘并不知道如何入手；市面上更不乏有各種文章提到國內各個大廠對于數據產品經理的職責要求，會讓人覺得自己對數據產品是可望不可即的。

數據產品離不開三步驟，數據挖掘、數據清洗、數據分析

上圖來源于某技術博文

當然數據獲取目前也有很多輕量化便捷化的來源方式，最簡單的是大家熟知的表格導入、爬蟲等方式，以上方式第一是有數據安全的風險其次是不滿足大型企業級項目的數據動力，提高個人工作效率是可以參考的；面對TB，EB乃至ZB，YB級別的數據量及各種大型分布式系統的數據治理場景，人工介入的能力顯得是那么粉粉拳；面對這種場景會更偏向自動化，最普遍的應該就是通過接口達成數據傳輸的需求。

一、接口調度（即API）

通常接口離不開請求方和響應方，即request和response，面對時效性要求更強的場景會考慮到DTS等方式，也就是數據傳輸服務。

如何更高效更及時的傳輸數據也決定著后續數據分析的產出效率，從產品角度分析數據傳輸最直觀的就是如何提高獲取數據的時效和如何提高獲取到的數據準確性；如果上游數據方是固定模型，最常見的是各大開放平臺：往往上游會約定好固定的數據結構，將各種業務接口封裝成不同開發語言的SDK提供給調用方使用。

那如何獲取數據的問題就交給數據的獲取方了，比較常見的也就是定時任務；如獲取電商平臺的訂單數據，定時任務有很好的兼容性；搭建一套job集群，由一套調度集群來控制，如調度頻次，并發量，調度周期等因素；根據不同的使用場景來控制job集群，從不同的上游接口獲取到屬于上游數據結構的不同數據集。

部分業務可能需要同步的處理機制，多數場景可能都需要異步消費結果，你可以選擇建立屬于適應自己公司的數據模型去承載結構不一的數據集，化“無序”為“有序”；將不同的數據結構歸一為自己的數據結構，通過標準數據結構提供給下游系統方便下游做對應的數據分析需求，或者以結果為導向，以下游數據分析部門制定的數據模型去承接上游數據——當然這樣復雜度較高，如下游系統較多也許場景復雜你可能會維護多套模型，最好的就是建立屬于自己的標準數據模型；至于調度方式最基礎的是定時請求的方式，如條件允許可以考慮“服務上云”等方式實現DTS的場景；根據接口流控、風控等因素來制定請求方式，以目前的資源情況做參考，選擇合適的調度邏輯最大化實現業務部門的數據挖掘需求。

上游流控及自身資源允許的情況下考慮多線程的方式請求提高時效性，說起請求離不開的是接口冪等，關于冪等的邏輯也可自行百度（一般接口提供方就會兼容冪等，最常見的是支付系統）控制好請求參數也是學問；比如獲取前一整年的訂單數據，可參考接口性能及預估響應數據量和自身消費數據的能力來評判請求方式，也并不是一味的增加線程數據就是好的，一來會命中上游流控規則，二來對于自身負載也是負擔；適度考慮調度邏輯時同時考慮接口自身的流控規則，在現有流控內將調度控制在最合理的范圍，考慮到調度層以后需要兼容的是數據安全的問題。

國家也已發出過公告再者隨著這個數據時代的洪口，數據安全是個嚴肅的命題，在擁有海量數據流的數據中臺如何合理的控制數據存儲的安全及數據流出入的安全性；一些普遍的加密算法應該是多數上游接口已經實現的，如加入token、sign等策略來提高數據獲取時的門檻，同時在一定層面上控制數據的輸出是給定到某些擁有合法“授權”的數據需求方。

上圖取自某電商開放平臺數據傳輸示意圖

二、異構系統異常分析

如果說請求調度的邏輯有理解的話，那下面要考慮的也就是請求過程中的不確定因素（沒有絕對穩定的接口）；如請求失?。ó悩嬒到y網絡層面失敗或業務失?。苯訉е履愕穆鋷鞌祿胁町?，這里會涉及到數據治理的其中一大要素：數據一致性。

如出現以上情況需要考慮補償機制，補償時你需要考慮為什么補？

怎么補的問題，數據在什么場景產生的缺失，缺失的是哪部分數據，通過什么方式來補償最為合理，值守化的補償機制是必要的，自動化的補償機制來最大化確保數據完整性、一致性。

這里提到了接口的不穩定性和值守，簡單提及一下，因為接口的不穩定性所以一般后端會加入監控系統、值守系統。

三、數據存儲

本段落簡單概述下存儲方面的思路，考慮存儲方式前請先分析清楚你的數據流來源及來源方式，考慮清楚前置條件才能清楚對于你數據存儲系統的要求，考慮到易用性或成本方面會涉及到考慮適用的數據庫；數倉和所謂的“數據湖”數據庫方面在評估未來業務增長量，數據量及數據使用需求模式等因素可以合理制定分庫分表規則，合理完成數據隔離數據一致性，災備等一系列保障措施；保證業務庫宕機或者上游服務停滯時無縫切換備用庫及備用服務能力，保證主業務的正常運行。

數據完成存儲后根據數據分析需求考慮引入數倉技術，市面上也有很多提供laas能力的第三方平臺，提供云存儲云計算等基建能力；服務上云或許可以從一方面降低企業自身的維護成本，數倉內提供持久化數據存儲及根據各個bu制定其適用的數據模型，以便業務需要時能及時更準確的提供數據分析服務。

上圖取自知乎某博文

四、監控系統

最后監控系統和值守系統準備單獨出來說，有同學會覺得監控系統很容易實現，這話不假，實現很容易，但是做好很難——全鏈路的監控體系是必要的，便于掌握系統健康狀態；監控系統需要考慮的緯度簡化后得出，你需要明確被監控的對象是什么？如何監控？監控后需要做什么？

我們一步一步來，被監控的對象大到整套系統以及接口交互的環節，小到某個job，在前期的產品流程圖接口交互圖上很容易定位到節點——哪些節點是業務依賴的往往優先級會被提高？哪些節點是有容錯率的？

舉個例子一般互聯網系統都需要日志庫，海量的日志寫入如果都在你的監控范圍內，那一定是個不成熟的監控程序；有些非核心流程日志，如部分用戶行為日志寫入失敗即可丟棄，并不影響正常業務流轉，如支付日志寫入失敗會直接對后續的業務造成影響那這個節點就值得被監控。

如果你一定找到了需要被監控的節點那你可以考慮第二步通知方式，通知方式最普遍的是群消息、短信、郵件或者更及時的電話；不同場景的監控需要推送給不同的處理人員，如服務器異常需要推送給運維人員；業務異常需要推送給業務線產品技術人員，選擇合理的推送渠道和推送方式會讓整個作業流程更順暢，以達到異常能夠及時得到對應人員的處理，也不至于影響到處理人員的正常生活。

可以考慮一下如果監控系統每天推送10條給到研發人員，可能他可以很高效的處理掉每一個異常；如果每天推送100條消息給到研發人員，作為心智的角度考慮人遲早會倦怠處理，就形成了惡性循環；異常越推越多，異常無人處理那監控系統也喪失了能力。

最后提供一個監控系統搭建的幾個要素：

• 及時性
• 準確性
• 緊急性
• 重要性
• 真實性
• 可執行性

五、值守系統

如果還有更多的資源可以考慮搭建值守程序配合監控體系使用，頻繁且單一的操作可以交給自動值守程序來處理；值守程序包告不同場景的異常收集能力也會對應不同場景的處理機制，如異常A該使用A策略來處理，異常B該使用B策略來處理提高效率降低人的依賴度，值守程序不再贅述。

再提供一個思路，如果你成功搭建起來了監控及值守程序可以考慮搭建知識庫體系，建立完整的異常處理鏈路，知識庫可覆蓋至值守程序乃至人員培訓；根據前置條件來判斷最終的決策行為，整條鏈路也可加入數據分析的范疇，用數據驅動業務改造更為高效。

以上兩段主要提及數據挖掘和前置的根據數據的決策，往后的bu就是數據清洗及數據分析，本來準備下面單獨寫一篇文章，這里給一些靈感：

• 根據你的數據產品類型來考慮清洗、存儲、分析邏輯（用戶數據產品，商用數據產品，企業數據產品）；
• 數據分析的過程：采集清洗，計算管理，分析展示，挖掘應用；
• 數據產品衡量：準確性，及時性，全面性，易用性；

文章寫的很倉促，非技術博文，只能提供一些思路給到各位有數據系統搭建需求的產品同學們，屬于雨露均沾但都未提及到細節。

有興趣的同學可以共同交流或者對于哪些業務感興趣，后續可以單獨篇幅來描述，個人喜歡從實際使用層面出發，知識只有共享才能發揮最大的價值，大家共同加油！

本文由 @清醒 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議