越来越多的数据采集需求, 几乎每家公司都标配类似如下结构的系统.
标准日志采集系统结构
- 其中客户端可以是 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
那上述系统设计过程中, 如何提高系统在数据质量方面的保障?
- 每条消息中携带唯一 request id
- 每个 session 的消息携带自增型序列号
- 客户端识别
- 实时数据收集验证系统
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 --
