埋点数据从SDK到数仓，中间Kafka这段链路怎么保证数据质量？

这道题把Kafka和数据治理结合起来考，非常贴近实际工作。在某知名出海硬件品牌，我主导了埋点治理体系的建设——把1000+历史埋点事件聚合为100+标准事件，数据质量问题减少60%。这个过程中，Kafka作为埋点数据的中间管道，它的设计直接影响上下游的数据质量。今天把埋点数据链路中Kafka的角色和质量保障方案讲透。

埋点数据链路全景

# 典型的埋点数据链路
#
# ┌─────────┐     ┌─────────┐     ┌─────────┐     ┌──────────┐
# │ 客户端   │ ──→ │ 采集服务 │ ──→ │ Kafka   │ ──→ │ Flink/   │
# │ 埋点SDK  │     │ Gateway  │     │ 集群    │     │ Spark    │
# └─────────┘     └─────────┘     └─────────┘     └──────────┘
#                                       │               │
#                                       │          ┌────┴────┐
#                                       │          │ 数仓     │
#                                       │          │(Databricks│
#                                       │          │ /Hologres)│
#                                       │          └─────────┘
#                                       ↓
#                                 ┌──────────┐
#                                 │ 实时分析  │
#                                 │(Doris/   │
#                                 │ 第三方)   │
#                                 └──────────┘

质量问题一：数据丢失

埋点数据丢失可能发生在链路的每一段：

我的配置策略：埋点数据用acks=1而不是acks=all。原因是埋点数据量极大（日均亿级），acks=all的性能开销太高，而偶尔丢一两条埋点不影响大盘统计。但如果是交易数据经过Kafka，那必须acks=all。

质量问题二：数据重复

重复比丢失更隐蔽也更常见：

① SDK重复上报：用户网络切换时SDK可能重试，同一个事件上报两次。解决方案是SDK端生成唯一的event_id，下游按event_id去重。

② Kafka Consumer重复消费：Flink恢复Checkpoint时会重新消费一部分数据。解决方案是下游OLAP引擎用UNIQUE KEY去重（Doris、Hologres都支持）。

-- 下游去重方案：在数仓层按event_id去重
-- 方案一：Doris UNIQUE KEY模型（实时场景）
CREATE TABLE ods_app_event (
    event_id VARCHAR(64),       -- SDK生成的唯一ID
    event_name VARCHAR(128),
    user_id BIGINT,
    event_time DATETIME,
    properties JSON
) UNIQUE KEY (event_id)
DISTRIBUTED BY HASH(event_id) BUCKETS 16;
 
-- 方案二：离线数仓用ROW_NUMBER去重
SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER(
        PARTITION BY event_id ORDER BY kafka_offset DESC
    ) AS rn FROM ods_app_event_raw
) WHERE rn = 1;