亚洲精品无码AV中文字幕,久久久久人妻精品专区,日韩综合无码一区二区

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

數據爆炸時代面臨的困境及突破口

清醒

2022-11-08

2 評論 4850 瀏覽 4 收藏

31 分鐘

在大數據時代，更為核心的不是如何采集數據，而是應該聚焦在“數據應用”上，數據產品的根源應該是業務。本文作者根據自身的經驗，對數據時代面臨的困境和突破口做了分析總結，一起來看一下吧。

停更很久了，近期臨近年度大考雙十一，忙碌之前突發奇想對自己也對整個部門一路走過的經歷做個總結。換句話說對我們2022年做個年度總結，也希望分享一些實際業務歷程中遇到的問題場景，及面對問題該如何思考，如何落地，如何做效果評估等。

文章開始前再補充下背景，筆者所在的公司所處互聯網行業，性質為toB，產品面向企業服務，首先感謝您的閱讀，讓我們開始吧。

一、面臨的處境

筆者目前所處的部門成立于2020年，部門定位是基礎數據服務部門，所謂基礎數據服務也就是職能屬性，例如銷售部門所屬直接產能部門。對于我們當初搭建時的初衷則和大多數數據產品成立的愿景一樣：“用數據賦能業務”，只有真正從事數據服務相關工作的同學才能明白這短短7個字的含義。

DT時代以來，大數據殺熟，數據冗余，海量的數據已經讓使用者應接不暇。擁有數據從來不是可以使用好數據的理由，只是基礎，當然我不是指數據采集不重要，只是在大數據時代我理解更為核心的并不是如何采集數據，目光更應該聚焦在“數據應用”，再龐大的數據中臺，數據產品的根源也應該是業務，拋開業務數據只是DB中的一行明細，它并不能為公司，為業務帶來增益。

整個公司的業務涉及到面對上下游的海量企業商家，同時也面臨著商家所使用的第三方平臺，如上游平臺：阿里，字節，拼多多等；如下游物流：順豐、京東、三通一達等。我們需要為商家提供資源管理能力，這部分資源包含但不限于交易數據、成本數據、進銷存數據等，這時首單其中的問題則是系統打通，單從國內市場來看需要接入的平臺數量超過100，物流服務商也有大幾十，總結下來就是我們需要承擔數據的“進出口”，“進出口”進行業務拆解可以分為以下。

1. 數據定義

根據業務定義所需的數據源為哪些，如電商平臺交易單、物流承運商快遞單、商品成本數據。

根據數據渠道定義屬性，如交易類、商品類、成本類、庫存類。
根據屬性定義數據指標如交易單量、發貨量、上行成功率、業務滲透率。

2. 數據采集

明確數據源后如何獲取，如開放式API，私有數據交互協議等。

3. 數據轉換

數據源的多樣性造就數據格式的復雜性、數據形態的多樣性，需定義屬于我們的標準數據結構。

4. 數據存儲

海量數據如何選擇存儲方式：

數據格式考慮：結構化數據 or 非結構化數據；行存儲 or 列存儲
性能考慮：批插，讀寫等性能指標（可以以業務容忍度定義,如響應需控制在50ms）
成本考慮：預估數據量大小，是否需要持久化存儲，能否建立歸檔庫，歸檔數據保留時間等

5. 數據分析

根據多維度定義分析模型，定義算法對數據做加工解析，得到可產生業務價值的指導數據
根據業務屬性建立分析模型，可定時定量輸出分析結果
穩定性，易用性分析等

6. 數據應用

用數據引導業務，反哺業務，詮釋業務價值，協助業務做效果評估。

7. 數據治理

海量的數據需約定規范，建立數據血緣關系；打造可持續發展的生態，才能打下扎實基礎，未來承載更多的業務量。

8. 數據開放

可復用、易用的數據如何打造生態，對外賦能更多的商家，賦能更多業務域。

以上為職能的簡易拆解，拆解思路基本為按人員劃分（團隊人員搭建的目標也是按以上節點進行組成）。說完了職能描述再來看下每種職能背后所面對的真實問題，結合實際場景才能讓讀者身臨其境，通過冰冷的文字感覺到價值或思路。

1）數據定義

這一步驟分為兩階段，一階段是團隊搭建初期，數據需求則是企業需求，驅動力完全來源于使用者，企業需要什么數據我們就去接入什么數據，截止到2022年11月已接入了371家上游平臺100余家下游服務商（快遞公司、貨代）為企業獲取到他們分布在各個渠道的交易數據、商品數據、庫存數據、價格數據、成交數據等等。

第二階段則為本年度的狀態，驅動力更多地傾向于團隊自身、功能迭代、性能調優、存儲降本、引入流式計算等存儲&計算引擎來提高我們自身系統的健壯性、穩定性、及時性等。

關于所謂的數據定義還是比較好理解，背后隱晦的問題在于如何降低維護成本，做過接口開發的同學應該清楚維護接口的成本，特別是接入的外部系統數量增長到某個程度后接口參數發生微調，或字段語義的不確定性就會到自身業務造成不可逆的影響。

2）數據采集

采集面臨的問題是渠道多樣性，數據格式多樣性等；渠道及格式多樣性意味著需要固定人力長期維護，關注數據完整度，及時性等核心關鍵指標。

3）數據轉換

ETL中比較復雜耗時的節點，初期人力有限的情況下接入一個渠道獲取一個渠道的數據，再針對該渠道數據做相對應的轉換，轉換為所需的業務格式。

4）數據存儲

相信每一家互聯網公司的同學多少遇到過存儲相關的問題（有可能在您公司當前階段并未暴露出來）公司起步初期，數據量小、多樣化少，不會遇到太大的寫入讀取壓力。

在當前階段保留固定的數據入口及出口反而更能提高效率（針對每一種接入數據做相對應的轉換，向指定DB進行存儲，向指定DB進行統一讀?。?，相信這個階段也并不會遇到成本壓力，一開始我們便是采取這種方式，伴隨市場發展及拓張，在20-21年面臨數據量爆發式增長。

為了迎合市場產研部門按照不同的需求商家做了不同的數據源接入，多樣性已經接近無法管理，多業務向DB進行的讀寫也面臨著各種性能壓力，保證讀寫時序又做了大批量加鎖的行為導致各種表死鎖情況，年度成本數千萬。

5）數據分析

缺少分析經驗，面對格式不一的數據更是無從下手，數據存儲量高到驚人，可惜都是冷數據，長期以來并未讓數據產生與之對應的價值。

6）數據應用

缺少了分析的過程也就無從得知應用，團隊成本也并未養成“用數據說話”的習慣，更多業務決策更多的依賴人員的經驗，也就是所謂的“閉門造車”。很頻繁地聽到各位同學脫口而出“我認為xxxx”“我認為客戶應該xxxxx”，要善于用數據輔助我們做決策。

7）數據治理

多數互聯網企業可能并未經歷過數據治理的過程，沒有體會過數據治理所帶來的價值，也并未理解為什么要投入大量的人力財力去做數據治理。“治理”顧名思義是一種通過某種途徑做調節的機制，日常作業中可能會出現各種“數據不知道往哪里存”“數據不知道從哪里取”“這份數據誰在用”“改動此數據的影響評估無法做”等等問題。

8）數據開放

這一步可能聊的比較不切實際了，多數公司基本數據內驅，在內部做循環，能使自身業務做增量已經是比較理想的情況。距離做生態、治理生態還有一些距離，在自身已產生價值的情況下可以考慮將數據包裝后豐富自身的開放生態，賦能更多的協同或上下游，完善整個行業。

9）價值

這一步算補充條款了，上面并沒有提及到，相信這一節也能引起很多朋友的共鳴，要知道基礎數據服務部門應該都存在這個共性問題“如何做價值”無論是業務決策性產品或數據產品，難道我們只能被動接受來自業務部門的數據需求嗎？

總是一味地聽從別人的“你把xxx數據轉換為xxxx輸出給我”“我要xxxx 你需要清洗好提供給我”，數據的價值并非止步于此，在不沖突的情況下，我們有沒有突破口去做出價值，或許在清洗數據提供給業務部門后我們也能提供到數據角度的效果評估？這份評估結果也可以表現為一種價值，一種左右業務方向的價值。

二、如何思考解決方案

面臨上述遇到的問題后，需要解決的問題也比較多，涉及到的業務域跨度比較廣。人力有限的情況下沒有辦法齊頭并進，只能對改造點做了列舉，列出優先級和影響范圍劃定了整個部門Q1-Q4的目標。這些任務多為內驅，同時需要保持來自業務團隊的需求任務，所以部門討論后得到了60%外部需求40%自驅的節奏。

這里羅列下簡易的拆解過程：

拆解過程簡單分為五步

簡單概述為痛點，或者可以理解為核心目標，比較迫切在中短期內解決或完善的內容（居多的圍繞部門職能及核心價值），如我們屬于數據基礎部門，因而指標多為數據相關。比較典型的就是數據幾個特性：穩定性、及時性、完整性、易用性、成本。

1. 穩定性

這里描述的是集群穩定性，規模龐大的商家群體意味著會存在規模龐大的數據鏈路，為了減免宕機等穩定因素對業務產生不可逆的影響，也是業務的基石。

集群分布也可以拆解為web集群（B/S架構的網頁）和任務集群（Job調度集群），在云資源逐步增加的基礎上對集群做一定的“資源瘦身”。web集群比較好理解主要是監控高并發的請求，及一些核心業務操作的穩定性（如訂單操作，報表操作多為DB增刪改查操作），加入監控體系。這也是我們搭建的第一組監控系統，凌駕于整個部門所涉及的全業務之上，這里想到了監控系統設計的幾個核心：

報警的觸達應當是緊急的、重要的、可執行的、真實的。
規則應當表示為服務處于過程中或者即將發生的問題。
為了保持報警項的精確、有效，寧可過度移除報警噪音，因為過度監控比監控不足更難解決。
你應該總是能夠將問題分為以下幾種：基本功能的可用性問題；延遲；正確性（數據的完整性、新鮮性和持久性）；以及特定功能問題。
規則描述癥狀是更好的方法，可以更輕松、更全面、更可靠地捕獲更多的問題。
在基于癥狀的頁面或儀表板中包含基于原因的信息，但要避免直接針對原因發出警報。
報警越往上層的服務走，在一個報警規則中可以抓住的明顯問題就越多。但不要走得太遠，無法充分區分發生了什么。
如果你想在值班時，報警系統保持安靜, 那么需要有一套系統和標準化的流程能夠自動處理那些需要被盡快處理的事情，但不至于讓你半夜三點鐘爬起來上線的情況。

這里簡單說下監控系統搭建的心路歷程。預警的目的不是為了預警，所以預警內容必須具備緊急且可執行的特性，這個指標很重要，很多監控系統的設計從最初就開始拆解各個業務指標，往往幾十個指標，報警一大堆，處理人員沒有頭緒無從下手。

寧可過渡移除報警噪音這一點也需多多關注，報警并不是越多越好，也并不一定是越細越好，將最重要的內容在合適的時間報向正確的人才是合理的；報警規則盡量貼近業務，脫離現實的報警只會讓你增加無盡的煩惱。

最后一條相信搭建過監控系統的同學都感同身受（報警滴滴響，時間長了人員也開始疲勞，疏忽落實報警內容）這時就引出了配套能力之一：值守系統，何謂值守（自動化值班）可以抽出統一的數據交互錯誤格式，也就是標準異常碼，參與過接口開發的同學應該比較清楚一個接口的響應信息一般都存在兩層（code，msg）msg即消息主體，code即描述碼；

如code = 200即成功 code = 500001 即業務錯誤，再進行細分的話可以做到二級code，如code = 500001 & sub_code = 9999 等于系統宕機，需要調度系統重試，這就是抽象出code映射關系后就可以建立自動化值守系統，根據code定義的決策結果進行自動化不間歇的”值班”從一定程度上釋放了產研人員的壓力。

此處可以深挖的細節還有很多，例如可以根據code搭配AI機器人，從移動端接收產研人員的操作指令，完成權限分配、OA流程審批、資源購置等。亦或者根據預設code完成線程分配，調整任務集群步頻、步長、步幅等動作。

有了監控 + 值守后當然少不了預警系統，也就是所謂的消息分發系統，經過值守系統自動化處置后依然有一些關鍵性異常是系統無法自動消化的，需要人為介入，那這時需要用到分發系統。

可以與多種消息渠道打通，如企業微信、釘釘、飛書、短信，更甚至可以電話，可根據預警等級推送至可執行的人員或組里（需提前按照職責劃分對應的接收組或接收人）預警通知需要建立固定的處理流程，個別高優異常需建立駐留時間達到xx時問題上升，讓更多更專業的同學參與進來協助處理。

2. 及時性

做數據基礎服務避免不了的就是降低數據交互耗時，內外部系統交互的RT值，需要把整體數據鏈路的耗時降下來。那么在調度資源不變的情況下需要如何做到，思路也比較明確，“讓資源在合適的時間用到合適的地方”服務器資源會存在高負載及低負載的時間段，如高頻計算的白天，多條數據鏈路需公用資源，那我們可以將資源量化后區分業務或商家的優先級，將更多的資源分配至更高優的業務鏈路。

在凌晨負載降下來以后可以去執行一些海量數據的離線計算服務，如日報、歸檔、大規模業務數據重算等操作，可以在這些時間點做一些兜底的業務策略，一些數據稽核的過程可以放置于此，一方面資源沒有浪費，一方面也可以提升整體鏈路的健壯性，另一方面提高響應。

降低耗時的另一個思路就是“瘦身”，這個瘦身不止在資源上，對業務也一樣，一些涉及到與存儲介質交互的業務，例如對數據庫的讀寫操作，是否可以支持批量，是否會出現表鎖行鎖等情況，業務代碼是否會出現大量的逐條循環逐條更新的操作等等；扣業務細節，通過各種細節做持續的優化以達到一個良性循環。

3. 完整性

這一步的背景是這樣的，在存在大量的數據入口時，很多數據來自于上下游系統、服務商。數據口徑不同不易維護，外部數據字典發生變更會影響到我們自身業務，如反序列化等步驟，這時為了保證業務可以獲得完整且結構明確的數據，我們可以封裝統一的數據模型校驗能力，根據我們抽象出的業務模型（符合業務預期的）對實時數據做校驗。

如果擔心對性能有壓力可以選擇性將一些比對工作做成異步操作，保證主鏈路順暢的同時如果比對出一些邊角數據可以通過第二步的預警體系完成回流，人工介入去確認情況，更及時有效的感知數據變更，從而降低對業務系統的影響。

4. 易用性

這一步更多的需要用到工程思維，在業務沉淀的過程中更多的考慮如何抽象，如何封裝統一方法、接口讓內外部的協同更好更高效地使用數據?，F在微服務的概念越來越普及，很多模塊化、碎片化、服務化的系統更利于后期的業務拓展、業務重構。

通過封裝統一數據接口的方式降低數據的使用門檻，通過抽象模塊，服務的設計使得系統得到高可用的后期空間。在此基礎上，業務系統需要使用數據時，可以更多地把目光放在賦能業務上而不需要過多考慮數據使用問題。

在此基礎上建立數據治理系統，對數據血緣關系做完整鏈路記載，便于后續我們做追溯，更多的服務化也使得業務耦合度降低，降低迭代所帶來的影響范圍及灰度成本。

5. 成本

最后這一段有關成本，歸根到底降本增效這條路是需要持續走下去。特別是互聯網行業，除去人力這一最昂貴的成本之外，資源成本也讓人頭痛，各種技術棧所帶來的成本數不勝數。

存儲成本如服務器資源成本，DB、數倉的存儲成本，中間件及計算引擎所帶來的計算成本等都是大頭，對于這個問題，我們初步的方案是在調度分配的策略優化基礎上，對底層存儲結構做了調整，即分庫分表規則，將數據&資源流量合理的分配后可以壓縮出更多的使用空間，將低負載的集群都合理分配到更多的業務，減少集群閑置的頻率。

當然機器的使用空間不單單只是我們自身的業務，在亞馬遜云初期的時候就是因為自身龐大的集群閑置了很多資源，才想到對外租賃一部分云資源并提供一系列的云服務，這些高效的存儲、算力都可以為一些中小企業提供很好的基礎，半托管&全托管的服務也隨之而來，總之合理利用現有資源來達成更多的業務目的就是關鍵。

說了這么多，也簡單畫了個草圖，描述了下當前我們的一套系統架構圖，內容不是很全面，不過也概括了目前基本的分布情況。

從上至下可分為一層接口層，采用API、導入、數據推送等技術手段完成對外部數據的采集。

二層為模型轉換層，數據格式校驗、模型校驗等皆在于此。

三層多為一些中間件服務，如消息隊列、集中式&分布式緩存、流失數據計算引擎、即席查詢報表等。

四層為業務層，按業務域做了拆分，如交易、商品、庫存、財務等；按服務做了拆分，如交易服務：多為處理交易數據，對交易數據做清洗等，商品服務、發貨服務等。伴隨著業務則會有規則類服務進行輔助，完成更多業務的限制，如綁贈規則、風控策略等。規則服務之外會有業務系統權限管理，這里的權限類則做了抽象，是可以對業務層的上下游提供能力。

五層為基礎數據存儲層，如關系型數據庫Mysql，非關系型數據庫MongoDB、數據倉庫等。

在1-5層的基礎上提供了內部網關，多用于承載內部業務接口，做一些流控策略、風控策略、鑒權策略等，保障業務的穩定性及安全性。

在五層之外貫穿整體系統的有外部網關，即內部數據對外的網關，可通過外部開發者身份進駐在我們平臺之內，完成一些自研系統的開發數據獲取工作。

調度中心即自行搭建的基于主從關系（Master-Slave）的調度集群，掌管著系統內外部一些資源調度及分配?？山Y合后續的日志服務及監控中心完成一些健康度檢測，心跳檢測等自我健康策略，保證系統的核心足夠的穩定。

監控中心及日志服務則滿足絕大多數環節的可植入性，通過封裝內部接口使得全業務域均可低成本完成日志寫入，包括業務日志、用戶操作日志、用戶行為日志，更能使業務低成本地完成業務埋點，并指定分析策略完成后續的數據復盤，及提供迭代的數據支持。