数据收集系统设计的一些思考

越来越多的数据采集需求, 几乎每家公司都标配类似如下结构的系统.

标准日志采集系统结构

• 其中客户端可以是 mobile/web, 也可以是其他系统

然后就好了? 其实没有. 还有一些 non-functional 的需求要考虑一下, 其中最重要的就是:

如何保证数据质量?

而且保证数据质量就像是健身: 关键在坚持.

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

那上述系统设计过程中, 如何提高系统在数据质量方面的保障?

1. 每条消息中携带唯一 request id
2. 每个 session 的消息携带自增型序列号
3. 客户端识别
4. 实时数据收集验证系统

1. 每条消息中携带唯一 request id

---

• 分布式系统中幂等性, 参考 HTTP 幂等性概念和应用
• 放心让客户端失败重试, server 端容易做消息去重
• 开发过程中容易定位唯一消息
• 如果做到了客户端的识别, request id 也可以仅需保证一个客户端内唯一

2. 每个 session 的消息携带自增型序列号

---

• session 的定义就是一段时间内生成一个唯一id ,可以结合 request id 一并设计, 解决消息存储空间
• sn 从0开始, 每发送一条消息自增1
• 目的是容易验证一个 session 内数据中间没有丢失, 验证方法:

-- session_id: session 的唯一ID
-- client_id: 客户端唯一ID
-- sn: session 中的序列号
-- 筛选出中间丢失数据的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 内尾部数据是否丢失

3. 客户端识别

---

如果是 mobile/web, 想办法计算客户端指纹作为客户端 ID, 如果是内网中其他系统, 可以使用客户端 IP.
识别客户端有助于测试和定位问题. 完全没有客户端信息, 在后续 troubleshooting 过程中会非常苦恼. 依旧可以在 request id 中添加客户端信息, 比如把内网系统的 IP 编码到 request id 中

4. 实时数据收集验证系统

---

数据收集系统不一定会实时将数据落地到文件系统(HDFS), 因此 Hive 等系统无法及时查询到已经收集的数据. 但

在数据质量验证过程中, 能够及时看到发送的数据是一个必备功能.

方便写 Unit Test. 方便检测系统是否正常.

数据验证系统

• 收集 Server 定时从验证系统获取拦截客户端白名单
• 收集 Server 将白名单内的客户端发送的数据转发给验证系统
• 验证系统提供 UI / API, 供开发人员测试数据收集过程
  • 通过 API 可以写 Unit Test 测试 SDK 准确性
  • 通过 UI 可以肉眼测试数据格式等.
  • 通过 API 可以监控整个数据系统

总结

---

如果不能保证数据质量在可控范围内, 收集来的不是 Big Data 而是垃圾, 倒不如低碳环保什么也别做.

-- EOF --