活码系统每天产生海量日志，如何高效地清洗、聚合、存储，并最终呈现给运营人员？这需要一个健壮的实时ETL管道。今天，我们以企销宝的数据平台为例，聊聊背后的技术栈。
一、数据源与采集
活码数据主要来自两个地方：
- 业务数据库： MySQL中存储活码规则、员工信息等静态数据。
- 日志文件： Nginx访问日志、业务服务日志，包含扫码事件、添加事件。
日志采集采用Filebeat，将日志发送到Kafka集群。Kafka作为数据缓冲区，可以应对流量高峰。
二、实时清洗与加工
使用Flink消费Kafka数据，进行实时清洗：
- 解析日志格式，提取关键字段（时间、IP、UTM、user_agent）。
- IP解析：将IP转换为地理位置（国家、省份、城市）。
- User-Agent解析：识别设备类型、操作系统、浏览器。
- 会话拼接：将同一次扫码的多个事件（如扫码、添加）关联起来。
Flink作业的Checkpoint间隔设为10秒，保证Exactly-Once语义。
三、数据分层存储
我们将数据分为三个层次：
ODS层（操作数据存储）： 原始日志数据，存储在HDFS/Hive，用于离线回溯。
DWD层（明细数据）： 清洗后的明细数据，存储在ClickHouse，用于实时查询。表结构按天分区，使用MergeTree引擎，主键为(date, scene)。
DWS层（聚合数据）： 预聚合的统计数据，如每小时各渠道扫码量、每日各渠道添加率，也存储在ClickHouse，用于快速看板查询。
ClickHouse的聚合表使用SummingMergeTree引擎，定时聚合，查询时无需实时计算。
四、实时计算：漏斗与归因
一些复杂指标需要实时计算，比如每个渠道的实时转化率。我们在Flink中维护状态，计算滑动窗口内的指标。
归因计算： 用户添加事件到达时，关联最近30分钟内的扫码事件（根据IP和设备指纹），按最后点击归因原则分配渠道，然后更新DWS层的渠道转化数。
五、可视化看板
前端使用Vue + ECharts，从ClickHouse查询聚合数据。对于实时性要求高的看板（如今日实时扫码量），直接查询Flink输出的实时数据（存储在Redis中）。
企销宝的运营看板包括：
- 实时扫码曲线（每分钟更新）
- 渠道排行（按扫码量、添加率）
- 地域分布（热力图）
- 员工接待排行
六、数据质量监控
- 数据完整性监控： 每小时检查Kafka消费延迟，超过阈值告警。
- 数据一致性监控： 每日凌晨比对ClickHouse与MySQL中的总数，发现异常自动重跑。
七、性能优化
- ClickHouse优化： 使用物化视图预计算常用指标，避免查询时全表扫描。
- 查询缓存： 热门查询结果缓存5秒，减轻数据库压力。
- 冷热数据分离： 90天前的数据迁移到低成本对象存储，查询时通过Hive外表访问。
八、一个查询示例
运营想看“近7天抖音渠道的扫码趋势”，SQL如下：
SELECT toDate(created_at) as day, count(*) as scan_cnt
FROM dwd_scan_log
WHERE utm_source = 'dy' AND created_at >= now() - interval 7 day
GROUP BY day
ORDER BY day
在ClickHouse中，这种聚合查询秒级返回。
结语：
一套完整的活码数据ETL管道，需要从采集、清洗、存储到可视化，每个环节精心设计。企销宝的数据平台基于Flink + ClickHouse构建，实现了百万级扫码数据的实时分析，为运营决策提供了强大支持。
