clickhouse在风控-风险洞察领域的探索与实践 - 京东云开发者
source link: https://www.cnblogs.com/Jcloud/p/16888186.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
一、风险洞察平台介绍
以Clickhouse+Flink实时计算+智能算法为核心架构搭建的风险洞察平台, 建立了全面的、多层次的、立体的风险业务监控体系,已支撑欺诈风险、信用风险、企业风险、小微风险、洗钱风险、贷后催收等十余个风控核心场景的实时风险监测与风险预警,异常检测算法及时发现指标异常波动,基于根因策略快速做到风险归因分析并生成风险报告,接入MQ主题500+、数据模型6000+、实时预警4000+、 风险监控看板1000+、 异常检测模型10000+, 大促时期分钟级消息处理量达3400w/min,日均消息处理量达百亿
二、风险洞察-遇到的技术挑战与解决方案
技术难点与挑战
风险洞察平台早期架构采用ElasticSearch作为数据存储, 通过消费MQ消息进行批量写入, 基于ElasticSearch明细数据进行指标计算来满足风险预警与风险监控的需求实现. 这种架构早期可以满足业务需求,但随着平台业务的发展与数据的膨胀, 面临了以下痛点:
技术解决方案
基于以上面临的技术痛点再结合当下风控业务现状的背景下, 我们以效率、成本、质量等方面对市面上主流OLAP引擎进行调研对比,如presto, impala, druid, kylin等, 最终确定clickhouse能够更好的涵盖风险洞察所需的技术特点.并结合Flink实时计算能力实现整体风险洞察的计算+存储架构,具体方案如下:
三、风险洞察-整体架构图
风险洞察-架构介绍
风险洞察-clickhouse实时数据模型设计
风险洞察架构的核心在于风险实时数据模型+实时计算架构, 风险实时数据模型的核心在于clickhouse, 接下来我们深入介绍下clickhouse在风险实时数据模型中的设计与使用.
层级缩短: 首先, 风险数据模型采用短链路架构设计,从RODS层可直接通过Flink构建RDWM层与RDWS层,重视层级缩短, 降低数据延迟; clickhouse作为分层数据载体, 可根据业务需求提供不同层级的数据查询服务, 当然基于性能的考虑推荐业务尽量使用第二层或第三层数据.
维度退化: 传统数仓中查询会涉及事实表与维度表之间的关联, 该操作会带来复杂的性能调优问题. 为了发挥clickhouse单表计算优势, 尽量多的将常用维度字段退化到事实表中,形成宽表供业务方来使用. 减少联查带来的性能效率问题.
Flink预聚合: 结合Flink实时计算引擎实现海量数据风险指标秒级或分钟级周期预聚合计算, 降低下游计算成本, 尤其在大促环境时期, 通过预聚合手段能够显著提高clickhouse计算能力
四、风险洞察-clickhouse的实践应用
介绍完clickhouse参与的架构设计理念, 接下来结合具体实践场景来介绍下clickhouse在使用中遇到的问题与优化方案.
营销反欺诈场景大促实践
背景: 营销反欺诈作为风控体系中的重要场景, 其原始数据流具备两大特点: 1. 消息体庞大且复杂, 包含多种数据结构, 但MQ消息体大小达17kb; 2. 消息流量大, 营销数据日常流量在1w/s左右, 在2021双11大促时期峰值更是达到60w/s, 为日常流量的60倍. 因数据需要支撑实时看板监控与预警, 所以如何保证数据写入的吞吐量与数据查询的及时性是极具挑战的问题.
初始设计: 通过消费原始消息流, 通过事件总线写入clickhouse.
问题发现:
架构改造:
改造点1: 分而治之, 集群拆分解耦
改造点2: 因势利导, 动态的写入策略
改造点3: 化繁为简, 预聚合
用户行为路径查询实践
背景: 行为路径分析能够帮助分析师洞察出某一类用户在各个主题事件间的路径分布特性。可依次通过人群筛选与路径筛选来得到目标人群与目标路径,再将筛选结果及相应的数据通过桑基图或排行榜的方式来呈现. 所以用户行为路径面临着海量数据如何高效查询、指标计算等问题
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的不足之处.
作者:李丹枫
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK