整个索引查询的逻辑，可以大致分为3个步骤： 1. 生成查询条件区间 WHERE ID = 'A003' ['A003', 'A003'] WHERE ID > 'A000' ('A000', +inf) WHERE ID < 'A188' (-inf, 'A188') WHERE ID LIKE 'A006%' ['A006', 'A007') 2. 递归交集判断 3. 合并MarkRange区间 索引的查询过程

tag-generate负责标签数据构建，保存到HDFS（MySQL中存储标签配置信息）  tag-loader向ClickHouse发送从HDFS导入标签数据的sql  to-ch-sql模块，将用户画像查询条件转换为ClickHouse sql诧句  用户画像平台通过Proxy从ClickHouse集群查询标签数据 Spark tag-generate tag-loader MySQL 输入条件 返回结果 场景描述 场景：限量发放10万张家电类优惠券，先预估出符合条件的用户数。 操作：用户指定标签及标签间的逡辑关系，统计出符合标签逡辑的人数。 标签表达式，包含标签、算术运算符、逡辑运算符、括号。 整形值，表示符合标签表达式的用户人数 例如： 23 user_number 100000 用户画像场景1—预估人数—示例 画像条件 查询SQL 查询SQL 24 用户画像场景2—人群圈选画像 输入条件 返回结果 场景描述 场景：对选出符合发优惠券条件的用户迚行画像分析，人群特征分析。 操作：用户指定标签及标签间的逡辑关系，查询出符合标签逡辑的用户ID数据集，然后对数 据集迚行用户画像分析。一条SQL完成人群圈选、用户画像两个劢作。 标签逡辑表达式，包含标签、算术运算符、逡辑运算符、括号。 查询出符合标签表达式的用户ID

如何来补充ClickHouse 的短板； 4. ClickHouse的调优，运维介绍； 5. 应用总结； 全球敏捷运维峰会 广州站 根据实际业务场景需要来选择 1. 不固定的查询条件，不固定的汇总条件； 2. 数据量日益增量，每天要更新的数据量也不断增大； 3. 业务场景不断增多，涉及面越来越广； 4. 需要保证高可用并秒出； 5. 从Sql，Es， CrateDB， Kylin

按时间窗⼜确定上下游事件。 v 离线Spark与计算出事件路径及相关⽤户id的RBM。 v 离线计算结果导⼊ClickHouse做交互式路径分析。 漏斗分析 v 预定义事件漏⽃ v ⽀持各个事件单独设置过滤条件 v 查询时间跨度最⼤⼀个⽉ v 数据按user id做Sharding，查询下推 Future Work Future Work v ClickHouse集群容器化，提升物理集群资源使⽤率