clickhouse在易企秀数据仓库项目中已投入使用两年,主要为内部用户提供快速查询和多维分析的能力;希望你在业务当中遇到的性能问题,在这里都能得到解决
Clickhouse堪称OLAP领域的黑马,最近发布的几个版本在多表关联分析上也有了极大的性能提升,尤其是还引入了MaterializeMySQL Database Engine做到了实时对齐业务线mysql中的数据。
表优化
数据类型
建表时能用数值型或日期时间型表示的字段,就不要用字符串——全String类型在以Hive为中心的数仓建设中常见,但CK环境不应受此影响。
虽然clickhouse底层将DateTime存储为时间戳Long类型,但不建议直接存储Long类型,因为DateTime不需要经过函数转换处理,执行效率高、可读性好。
官方已经指出Nullable类型几乎总是会拖累性能,因为存储Nullable列时需要创建一个额外的文件来存储NULL的标记,并且Nullable列无法被索引。因此除非极特殊情况,应直接使用字段默认值表示空,或者自行指定一个在业务中无意义的值(例如用-1表示没有商品ID)。
分区和索引
分区粒度根据业务特点决定,不宜过粗或过细。一般选择按天分区,也可指定为tuple();以单表1亿数据为例,分区大小控制在10-30个为最佳。
PARTITION BY tuple()
必须指定索引列,clickhouse中的索引列即排序列,通过order by指定,一般在查询条件中经常被用来充当筛选条件的属性被纳入进来;可以是单一维度,也可以是组合维度的索引;通常需要满足高基列在前、查询频率大的在前原则;还有基