2019年10月27日 众安保险 • 成立于2013年，是中国第一家互联网保险公司。 • 互联网保险特点： 1. 场景化 2. 高频化 3. 碎片化 • 今年上半年众安上半年服务用户3.5亿，销售保单33.3亿张。 CHAPTER 报表系统的现状 01 数据分析的最直观表现形式：报表 报表≠数据驱动 每天被访问超过10次的报表寥寥无几 传统报表访问往往是静态的、高聚合、低频、表单式的 洞察数据模型+Clickhouse 使用效果 CHAPTER 使用ck对百亿数据的探索 03 背景 我们希望对保单、用户数据进行灵活分析，根据用户标签筛选出符合 要求的客户进行精准营销。 原始保单数据百亿+，用户数据数亿，如果用户标签几百个，数据存 储和查询以及分析的压力就会很大，原有系统使用es来保存用户标签 数据。 保单表 用户表 用户行为表 ODPS ES 用户标签表 痛点 • 数据查询慢：每个查询需要5～10分钟； 持用户灵活的定义标签并让用户实时得到反馈。 标签平台 clickhouse 保单表 用户表 用户行为表 数据 • 历史保单数据 join 用户数据 join 用户行为数据 • 100+亿行，50+列 • 用户id • 事业部 • 入库时间 • first_policy_premium • ... • phone_flag • ha_flag • ... clickhouse集群配置

特性发布快 3. 软件质量高 4. 物化视图 5. 高基数查询 6. 精确去重计数（count distinct） 3 精确去重计数性能测试 4亿多的数据集上，去重计算出6千万整形数值， 非精确去重函数：uniq、uniqHLL12、uniqCombined 精确去重函数：uniqExact、groupBitmap 函数 时长（秒） Contents 苏宁如何使用ClickHouse ClickHouse集成Bitmap 用户画像场景实践 8 Bitmap位存储和位计算 每个bit位表示一个数字id，对亍40亿个的用户id，只需要40亿bit位， 约477m大小 = （4 * 109 / 8 / 1024 / 1024） 但是如果使用上述的数据结构存储单独一个较大数值的数字id，会造成空间上的浪费，例如 仅 连续数据，劢态分配 最大存储：65536元素 最大空间：128KB 稠密数据，固定大小 最大存储：65536元素 最大空间：8KB RoaringBitmap原理介绍 丼个栗子： 40亿（0xEE6B2800）这个值如何存入RoaringBitmap，以存入Array Container来说明： 12 short[] keys 0x0000 0xEE6B 0xFF01

早期集群机器配置16核64G 一块1.7T本地SSD 问题： 1：内存限制，对于一些大的查询会出现内存不够问题 2：存储限制，随着表越来多，磁盘报警不断 3：cpu限制 64G对于一些大表(每天600亿+)的处理，很容易报错，虽然有基于磁盘解决方案，但是会影响速度 clickhouse的数据目录还不支持多个数据盘，单块盘的大小限制太大 cpu需要根据实际情况而定 解决： 1：机器的内存推荐128G+ eventType='' 建表的时候缺乏深度思考，由于分时指标的特性，我们的表是order by (timestamp, eventType)进行索引 的，这样在计算累时指标的时候出现非常耗时(600亿+数据量) 分析： 对于累时数据，时间索引基本就失效了，由于timestamp”基数”比较高，对于排在第二位eventType索引， 这个时候对数据的过滤就非常有限了，这个时候几乎就要对当天的数据进行全部扫描

Representation 20 业务应用实践 iData 2 iData画像服务需要升级 Ø扩展性差 数据导入后结果不支持修改/追加 Ø数据类型有限 数据类型只能支持数字类型 Ø数据量有限 数据量达到10亿级以上查询效率有所降低 Ø单表计算 不能进行多表关联计算 一切以用户价值为依归 21 业务应用实践 iData 2 为什么选择ClickHouse • SQL • OLAP • 超高性能 1.11 2.786 3.47 4.362 3.789 5.231 7.123 6.572 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 4亿数据下钻耗时(单机) clickhosue tgface 一切以用户价值为依归 22 业务应用实践 iData 2 • TDW HIVE SQL • 转换成拓展的列 • 嵌套数据类型 •

疏索引就好比是这本书的一级章节目录。 一级章节目录不会具体对照到每个字的位 置，只会记录每个章节的起始页码。 以默认的索引粒度(8192)为例， MergeTree只需要12208行索引标 记就能为1亿行数据记录索引。 索引粒度 基于索引粒度，将数据标记成多个小的区间 index_granularity，默认8192 索引数据的生成规则 依照索引粒度生成索引，紧凑存储,惜字如金。 PRIMARY