越來越多的數(shù)據(jù)采集需求, 幾乎每家公司都標配類似如下結構的系統(tǒng).

標準日志采集系統(tǒng)結構

• 其中客戶端可以是 mobile/web, 也可以是其他系統(tǒng)

然后就好了? 其實沒有. 還有一些 non-functional 的需求要考慮一下, 其中最重要的就是:

如何保證數(shù)據(jù)質量?

而且保證數(shù)據(jù)質量就像是健身: 關鍵在堅持.

If you're not thinking about how to keep your data clean from the very beginning, you're fucked. I guarantee it.
-- From Everything We Wish We'd Known About Building Data Products

那上述系統(tǒng)設計過程中, 如何提高系統(tǒng)在數(shù)據(jù)質量方面的保障?

1. 每條消息中攜帶唯一 request id
2. 每個 session 的消息攜帶自增型序列號
3. 客戶端識別
4. 實時數(shù)據(jù)收集驗證系統(tǒng)

1. 每條消息中攜帶唯一 request id

• 分布式系統(tǒng)中冪等性, 參考 HTTP 冪等性概念和應用
• 放心讓客戶端失敗重試, server 端容易做消息去重
• 開發(fā)過程中容易定位唯一消息
• 如果做到了客戶端的識別, request id 也可以僅需保證一個客戶端內唯一

2. 每個 session 的消息攜帶自增型序列號

• session 的定義就是一段時間內生成一個唯一id ,可以結合 request id 一并設計, 解決消息存儲空間
• sn 從0開始, 每發(fā)送一條消息自增1
• 目的是容易驗證一個 session 內數(shù)據(jù)中間沒有丟失, 驗證方法:

-- session_id: session 的唯一ID
-- client_id: 客戶端唯一ID
-- sn: session 中的序列號
-- 篩選出中間丟失數(shù)據(jù)的session_id, client_id
SELECT session_id,
       client_id,
       sum(1) AS message_count,
       max(sn) AS max_sn
FROM test.data_table 
HAVING message_count <(max_sn + 1)
GROUP BY session_id,
         client_id

• 無法驗證一個 session 內尾部數(shù)據(jù)是否丟失

3. 客戶端識別

如果是 mobile/web, 想辦法計算客戶端指紋作為客戶端 ID, 如果是內網(wǎng)中其他系統(tǒng), 可以使用客戶端 IP.
識別客戶端有助于測試和定位問題. 完全沒有客戶端信息, 在后續(xù) troubleshooting 過程中會非?？鄲? 依舊可以在 request id 中添加客戶端信息, 比如把內網(wǎng)系統(tǒng)的 IP 編碼到 request id 中

4. 實時數(shù)據(jù)收集驗證系統(tǒng)

數(shù)據(jù)收集系統(tǒng)不一定會實時將數(shù)據(jù)落地到文件系統(tǒng)(HDFS), 因此 Hive 等系統(tǒng)無法及時查詢到已經(jīng)收集的數(shù)據(jù). 但

在數(shù)據(jù)質量驗證過程中, 能夠及時看到發(fā)送的數(shù)據(jù)是一個必備功能.

方便寫 Unit Test. 方便檢測系統(tǒng)是否正常.

數(shù)據(jù)驗證系統(tǒng)

• 收集 Server 定時從驗證系統(tǒng)獲取攔截客戶端白名單
• 收集 Server 將白名單內的客戶端發(fā)送的數(shù)據(jù)轉發(fā)給驗證系統(tǒng)
• 驗證系統(tǒng)提供 UI / API, 供開發(fā)人員測試數(shù)據(jù)收集過程
  • 通過 API 可以寫 Unit Test 測試 SDK 準確性
  • 通過 UI 可以肉眼測試數(shù)據(jù)格式等.
  • 通過 API 可以監(jiān)控整個數(shù)據(jù)系統(tǒng)

總結

如果不能保證數(shù)據(jù)質量在可控范圍內, 收集來的不是 Big Data 而是垃圾, 倒不如低碳環(huán)保什么也別做.

-- EOF --