clickhouse在风控-风险洞察领域的探索与实践( 三 )


设计:
1.及时生成common表,减少查询数据范围: 因用户行为事件明细及其庞大,分散在各个行为主题表中,所以在查询过程中,基于需要查询的事件与时间范围进行筛选, 实时创建并推送值common表,从common中查询明细结果, 减少查询范围提高查询效率2.合理利用clickhouse一级索引: clickhouse基于一级索引字段建立稀疏索引, 所以若无法命中一级索引相当于进行一次全表扫描; 以pin为一级索引, 并建立pin与手机号的mapping关系表, 使得每次查询即使不同条件也能命中索引, 提高检索效率3.巧妙利用位图函数实现去重等操作: 利用clickhouse自带bitmapCardinality、bitmapAndCardinality、bitmapOrCardinality等函数实现用户pin的去重操作, 有效的节省了存储空间.clickhouse生产运维实践背景: 在clickhouse的日常使用中, 也遇到了一些优化实践, 最后简单介绍一下相关问题与优化
Q: 生产过程中发现zk机器磁盘多次报警, zk日志与快照占用存储较多
A: 设置日志与快照份数以及自动清理的频率, 合理利用磁盘使用率
Q: 分布式表写入时会进行分片计算与数据分发,导致cpu与内存飙升,报错:Merges are processing significantly slower than inserts,merges速度跟不上写入速度
A: 写local表,同时使用vip写入,尽量保持数据写入磁盘均匀分布;
Q: zk session经常断掉,或者处理不过来事务,导致ck所有表结构出现readonly;
A: 高版本clickhouse集群支持raftKeeper, 在一定程度上解决zookeeper性能问题, 目前正在持续调研跟进中
五、未来展望总结起来, clickhouse在大批量数据读写场景下对比同类型引擎有着巨大的性能优势, 在风险洞察实时分析、实时预警领域承担着重要职责; 同时我们也在对clickhouse不断地深挖优化, 针对高并发, zookeeper集群不稳定等ck劣势方面进行采取集群拆分、优化SQL来提高查询并发能力, 后续也将推进升级版本支持RaftKeeper等措施来完善clickhouse的不足之处.
【clickhouse在风控-风险洞察领域的探索与实践】

经验总结扩展阅读