Value Bitmap Container 0 1 1 0 ① ② ③ ④ ClickHouse集成RoaringBitmap Bitmap字段类型，该类型扩展自AggregateFunction类型，字段类型定义： AggregateFunction( groupBitmap, UInt(8|16|32|64)) 参考： https://clickhouse Bitmap函数 千万级用户， 秒级出结果！ Contents 苏宁如何使用ClickHouse ClickHouse集成Bitmap 用户画像场景实践 17 用户画像原有的流程及痛点 Hive表 商品数据 ElasticSearch 用户数据 交易数据 HBase Redis 第三方… Spark 用户画像平台 现有的流程：  ES中定义标签的大宽表 高频查询的画像数据通过后台任务保存到加 速层：Hbase 戒者 Redis  实时标签通过Flink计算，然后写入Redis  用户画像平台可以从ES、Hbase、Redis查 询数据 痛点：  标签导入到ES的时间过长，需要等待各种业 务数据准备就绪，才能迚行关联查询。  新增戒者修改标签，丌能实时迚行，涉及到 ES文档结构的变化。  ES对资源消耗比较大，属亍豪华型配置。

用户画像 DataMore 月光宝盒 DataMore 任务系统 iData 数据可视化 游 谱 游戏说 神秘 商店 iData 多维提取 … 游戏数据 驱动场景 潘多拉 社交与功能 用户增长 服务场景 游戏 社区 微信手Q 渠道投放 直播 电竞 … 大数据基础PaaS平台 n 标准化、海量数据接入能力 n 实时化、低延时对接数据应用 n 异构化兼容能力 大数据应用PaaS服务 iData画像服务需要升级 Ø扩展性差 数据导入后结果不支持修改/追加 Ø数据类型有限 数据类型只能支持数字类型 Ø数据量有限 数据量达到10亿级以上查询效率有所降低 Ø单表计算 不能进行多表关联计算 一切以用户价值为依归 21 业务应用实践 iData 2 为什么选择ClickHouse • SQL • OLAP • 超高性能 • 列式存储 • 统计函数 • 线性扩展 • 驱动丰富

ClickHouse-JDBC 与ClickHouse兼容的 HTTP 接口 请求管理/流量控制 查询缓存 查询分发器 查询处理器 ClickHouse 监控管理平台 元数据管理 库表管理 权限管理 埋点分析 报表平台 HDFS/Hive Kafka/Databus 离线接入 (Rider/Spark/WaterDrop) 实时接入 (BSQL/Saber/Flink & ClickHouse 计 v ⽇志查询采⽤类似ES语法，降低⽤户迁移成本 用户行为数据分析 概述 v 基于ClickHouse构建B站⽤户⾏为数据分析产品：北极星 v 行为数据分析平台主要以下功能模块： 事件分析 v 海量埋点事件数据，⽇增数据千亿级。 v ⽤户⾏为事件的多维度分析场景。 v 事件包含公共属性和私有属性，均可作过滤和聚合维度。 v 不同事件有不同的私有属性字段。 v 动态选择的过滤维度和聚合维度。

千万数据点并发实时写入 • 引入辅助索引，加快数据检索 速度 低成本存储 • 列式存储结合高效的编码 • Delta、XOR 等适合时序场景的压缩算法 • 通过 Rollup 功能，对历史数据做聚合，减少数据量 稳定可扩展 • 分布式架构 • 数据多副本存储 • 服务高可用 Thanks For You

监控好服务器的cpu/内存波动/`system`.query_log； • 数据存储磁盘尽量采用ssd； • 减少数据中文本信息的冗余存储； • 特别适用于数据量大，查询频次可控的场景，如数据分析，埋点日志系统； 全球敏捷运维峰会 广州站 StarRocks应用小结 • 发挥分布式的优势，要提前做好分区字段规划； • 支持各种join，语法会相对clickhouse简单很多； • 一个sql可以多处用；

原始保单数据百亿+，用户数据数亿，如果用户标签几百个，数据存 储和查询以及分析的压力就会很大，原有系统使用es来保存用户标签 数据。 保单表 用户表 用户行为表 ODPS ES 用户标签表 痛点 • 数据查询慢：每个查询需要5～10分钟； • 数据更新慢：更新数据可能需要数天时间； • 不灵活：用户有新标签需求时，需要提需求给标签开发人员排期开发 需求，开发人员开发完再更新到系统中，这时离需求提出可能已经过