目标
在一定并发范围内为内部用户提供稳定、快速的实时多维交互分析功能
实时数仓架构
设计
- 我们以尽可能快的方式将业务数据同步过来，以极低的数据延迟接口对外提供交互查询功能，整个过程数据延迟控制在秒级范围；
- 数据采集阶段使用Debezium和Logserver将生成的数据实时推送至kafka
- kafka中的数据经spark streaming或kafka connector任务简单加工处理后实时写入CK；数据写入的动作可能是插入，也可能是更新或删除
- 在性能允许的前提下，接口和看板部分可与CK进行多维度自由分析
边界
单次请求耗时上限：1s
数据库并发上限：10
最大写入QPS：5w~10w/s
使用原则
同样的逻辑不同的写法，性能可能会相差数十倍、甚至上百倍，为了确保性能更佳体验更好，我们需要制定一些使用准则进行规范和约束：
- 数据同步环节不建议进行多表关联，因为这样做会降低数据入库的时间；如果确实需要这样，是否应考虑离线方案，或在保障数据准确性前提下将同步延迟降低至秒级完成。
- 对外提供的接口或制作的看板应保证1s内可返回；这么做既能保证用户体验又能确保在一定并发量下服务的稳定性
- 所有CK的Sql查询需要且必须带where条件，不允许全表扫描；
- 不允许使用select * ，严重损耗性能
- 如果允许2%左右的数据误差，可以用uniqCombined(create_user) 替代count(DISTINCT create_user)进行去重统计，性能方面能提升100倍左右
- query语句后加settings max_threads=auto. 高并发时clickhouse会动态调整执行资源；或则为耗时操作配置固定线程资源settings max_threads=8 来避免因执行时间过长导致其它查询请求排队等待
- 不推荐但不阻止使用关联分析；如果需要关联分析请优化到1s内完成，遵循小表在右原则
- Clickhouse SQL使用规范
备注：这个世界并没有完美的技术框架，需要的是适合的技术框架有针对性的解决一部分问题；所以当违反以上原则时，需要考虑是否适合在该框架进行应用，我们还有离线预计算和准实时预计算方案
场景
通过一张用户表对上述流程做下简单总结：
通过debezium实时监控mysql中base_user表的binlog日志，并将binlog日志实时推送至kafka，日志中参杂新增、更新、删除等事件，在通过spark streaming或kafka connector任务写入ck前需要对事件类型进行判断；在ck中对应的数据表使用"dw_"前缀+原始表名，意思是该表包含了原始表的所有数据实时同步，当然我们也可以通过追加更新的方式在该表上拓展一些其它字段，但字段名上需要体现实效性；为该表在mydata上创建全新数据集，对外提供作图和接口查询的需求。
遗留问题
- 如果每张业务表都对应一个streaming解析任务，后期会因业务激增而占用大量集群资源，也不便于对任务的管理及维护
网友评论