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

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

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

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

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

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

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

數(shù)據(jù)產品離不開三步驟，數(shù)據(jù)挖掘、數(shù)據(jù)清洗、數(shù)據(jù)分析

上圖來源于某技術博文

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

一、接口調度（即API）

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

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

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

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

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

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

上圖取自某電商開放平臺數(shù)據(jù)傳輸示意圖

二、異構系統(tǒng)異常分析

如果說請求調度的邏輯有理解的話，那下面要考慮的也就是請求過程中的不確定因素（沒有絕對穩(wěn)定的接口）；如請求失?。ó悩嬒到y(tǒng)網(wǎng)絡層面失敗或業(yè)務失敗）會直接導致你的落庫數(shù)據(jù)有差異，這里會涉及到數(shù)據(jù)治理的其中一大要素：數(shù)據(jù)一致性。

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

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

這里提到了接口的不穩(wěn)定性和值守，簡單提及一下，因為接口的不穩(wěn)定性所以一般后端會加入監(jiān)控系統(tǒng)、值守系統(tǒng)。

三、數(shù)據(jù)存儲

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

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

上圖取自知乎某博文

四、監(jiān)控系統(tǒng)

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

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

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

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

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

最后提供一個監(jiān)控系統(tǒng)搭建的幾個要素：

• 及時性
• 準確性
• 緊急性
• 重要性
• 真實性
• 可執(zhí)行性

五、值守系統(tǒng)

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

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

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

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

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

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

本文由 @清醒 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議