一、风险洞察平台介绍

以 Clickhouse+Flink 实时计算 + 智能算法为核心架构搭建的风险洞察平台, 建立了全面的、多层次的、立体的风险业务监控体系，已支撑欺诈风险、信用风险、企业风险、小微风险、洗钱风险、贷后催收等十余个风控核心场景的实时风险监测与风险预警，异常检测算法及时发现指标异常波动，基于根因策略快速做到风险归因分析并生成风险报告，接入 MQ 主题 500+、数据模型 6000+、实时预警 4000+、 风险监控看板 1000+、 异常检测模型 10000+, 大促时期分钟级消息处理量达 3400w/min,日均消息处理量达百亿

二、风险洞察 - 遇到的技术挑战与解决方案

技术难点与挑战

风险洞察平台早期架构采用 ElasticSearch 作为数据存储, 通过消费 MQ 消息进行批量写入, 基于 ElasticSearch 明细数据进行指标计算来满足风险预警与风险监控的需求实现. 这种架构早期可以满足业务需求,但随着平台业务的发展与数据的膨胀, 面临了以下痛点:

1. 高吞吐的实时写入: 随着平台接入的业务增多, 数据规模也跟着相应增长. 以营销反欺诈场景为例, 大促期间峰值流量最大达到 12000w/min, 日常流量为 60w/min, 如何保证海量数据的高吞吐、低延迟的写入, 实现数据高效率的存储是当下风险洞察面临的核心问题.

2. 高性能的实时查询: 随着业务的快速发展, 风险实时监控方面要求进一步提高. 在保障风险指标的实时监控预警, 实现风险策略的实时分析与验证方面有着极大的挑战.

3. 复杂聚合计算能力: 随着风险策略的优化升级,相关指标的计算逻辑已不满足于单表的简单聚合, 分析师需要结合更多的标签、特征、算等维度来进行策略的评估验证, 所以能够支撑分析师实现复杂聚合灵活分析是一大挑战. es 这类复杂计算能力较弱的数据源已无法满足当下需求.

4. 海量数据下的计算性能: 在大促时期分钟级数据量处理量达到 3400w/min, 所以在海量数据存储规模下, 最大程度保证计算性能, 提供实时计算结果仍是一大严峻挑战.

技术解决方案

基于以上面临的技术痛点再结合当下风控业务现状的背景下, 我们以效率、成本、质量等方面对市面上主流 OLAP 引擎进行调研对比,如 presto, impala, druid, kylin 等, 最终确定 clickhouse 能够更好的涵盖风险洞察所需的技术特点.并结合 Flink 实时计算能力实现整体风险洞察的计算 + 存储架构,具体方案如下:

• 高吞吐、实时的数据写入: clickhouse 采用 MPP 架构,利用 LSM 算法实现内存预排序磁盘顺序写入,具备大批量、低延迟的写入优势, 并具有出色的数据压缩能力,最大能够达到 20:1 的压缩比

• 高效快速的查询速度: clickhouse 为列式存储数据库,稀疏索引结构,采用向量化执行引擎,最大程度上利用 cpu 能力,能够达到百亿数据秒级响应

• 具备复杂聚合能力: clickhouse 支持标准化 SQL 与完整的 DBMS,拥有多样化的表引擎满足各类业务场景,能够灵活支撑复杂聚合计算需求.

• clickhouse+flink 预计算架构: 将海量数据基于 Flink 预先聚合,减少 clickhouse 数据存储规模,降低聚合查询成本,最大程度上保证 clickhouse 的查询性能

三、风险洞察 - 整体架构图

风险洞察 - 架构介绍

• 数据源: 风险核心场景数据来源,底层基于插件化设计原则抽象统一数据源引擎,可通过扩展数据源连接器实现异构数据源接入,目前已支持 clickhouse、mysql、presto、r2m、openmldb、csv 等数据源.

• 事件总线: 承担风险实时数据统一标准化处理的职责, 负责将上游复杂数据进行解析、转换, 富化、分发等操作. 底层核心算子抽象为 source、transform、sink 三层架构, 支持各层算子插件式扩展, 并支持 groovy、python 等脚本语言自定义配置, 可直接对接 clikchouse 集群或转发 MQ 至 Flink 进行实时计算处理. 为整个风险洞察数据流转的重要一环.

• 风险数据模型: 风险数据模型采用以 clickhouse 为基础的三层存储结构, 分别对贴源层 (RODS), 轻度汇总总 (RDWM), 聚合层 (RDWS) 数据进行存储, 打通离线数据平台链路可实现离线与实时数据之间的互相推送转换, 并基于 Flink 实现实时指标加工处理.

• 数据建模: 统一标准化数据建模, 支持拖拽生成或自定义 SQL 建模. 底层抽象统一 SQL 引擎,基于 ANSI SQL 协议实现异构数据源语法解析、执行优化、数据查询等能力,支持自定义函数、sql 参数、条件表达式等多种功能设定.

• 算法服务: 基于数据模型结果进行异常检测、归因分析、聚类分析, 挖掘潜在风险问题,为风险指标提供算法能力支撑.

• 风险洞察: 上层风险数据应用, 提供风险核心能力,如风险预警,风险分析,风险报告, 风险感知,风险策略分析,风险群体分析等服务.

风险洞察-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. 消费能力不足: 营销的消息体较为复杂, mq 消息序列化反序列化操作耗费大量 cpu, 吞吐量瓶颈在于消息解析

2. clickhouse 写入异常: 在海量数据场景下会造成多频少批的写入, 导致 ck 服务端生成大量小文件, 文件 merge 时消耗服务端大量 cpu 与 io, 不足以支持写入频次导致抛出异常

3. clickhouse 查询异常: 大促时期数据查询与写入场景增多, 导致超过 ck 集群最大并发数限制, 抛出异常.

4. clickhouse 计算效率下降: 大促时期海量数据背景下, 基于海量明细数据的监控指标范围内数据量激增, 影响一定的计算效率

架构改造:

改造点 1: 分而治之, 集群拆分解耦

1. 消费集群拆分, 事件总线按照业务维度, 职责维度进行深度拆分, 将有远高于其他场景的营销流量单独拆分解耦, 再根据解析, 入库职责进一步拆分集群, 实现解析集群机器 cpu 利用最大化, 并降低下游如 Flink 计算, 事件总线入库的 cpu 压力.提高消费效率

2. clickhouse 集群拆分, clickhouse 按照业务维度进行单独拆分, 总共拆分出 4 大 ck 集群: 交易集群、营销集群、信用集群、混合集群. 营销场景承担着更大的存储与更高频次的写入, 与其他业务解耦可以更好的提高 ck 集群的并发量与计算效率

改造点 2: 因势利导, 动态的写入策略

1. clickhouse 集群数据写入规则在消费端进行封装优化, 支持按批量条数,批量大小,定时间隔的策略进行批量写入,对不同场景不同流量的数据进行写入规则调节适配,发挥 ck 大批量写入的同时也保证数据的实时性.

改造点 3: 化繁为简, 预聚合

1. 原始消息经过解析集群规整富化后, 消息体大小缩减 10 倍, 再由 Flink 集群基于核心指标进行分钟级聚合,最终写入到 RDWS 层,规模相较于 RODS 层减少 95%, 大幅提高 ck 查询效率

用户行为路径查询实践

背景: 行为路径分析能够帮助分析师洞察出某一类用户在各个主题事件间的路径分布特性。可依次通过人群筛选与路径筛选来得到目标人群与目标路径，再将筛选结果及相应的数据通过桑基图或排行榜的方式来呈现. 所以用户行为路径面临着海量数据如何高效查询、指标计算等问题

设计:

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 的不足之处.

作者：李丹枫