Kaggle竞赛经典案例深度剖析吾爱 kaggle

前言： 【Kaggle竞赛经典案例深度剖析吾爱】下哉课程ZY：Kaggle竞赛经典案例深度剖析吾爱
备用链接：https://www.sisuoit.com/1972.html
简述 ClickHouse 近两年在开源社区愈发火热，不知从何开始大家争相用它来替换 ElasticSearch，大概因为 ElasticSearch 的开销太高，在不作为搜索引擎的场景下，一定程度的暴力搜索是可以容忍的。
我们在使用 Skywalking 后发现，它对后端存储要求太高了，使用 (32C + 64G + 2T) x8 的配置，在云平台上每月好几万的开销，性能依然非常捉急，查询经常超时。前前后后优化了小半年后，最终下定决心替换成 ClickHouse。
在使用为 ClickHouse 后，机器数量减少了 50%；

查询链路列表从 5.53/s 提高到了 166/s，响应时间从 3.52s 降低到了 166ms；
查询链路详情从 5.31/s 提高到了 348/s，响应时间从 3.63s 降低到了 348ms；
链路数据存储时间从 5 天提高到了 10 天，数据量达到数百亿；
值得一提的是，在与 ES 的对比中经常会提到磁盘空间降低，其实 ClickHouse 的压缩率没有那么夸张，起码在我的实际体验两者相差不大。如果 ES 空间占用很高，那很可能是因为没在索引中开启 codec: best_compression。
ClickHouse 也并不是没有缺点，本篇文章分享下如何用 ClickHouse 作为 Skywalking 的后端存储。本文不会赘述 ClickHouse 的基本原理，需要读者对 ClickHouse 有一定了解的情况下阅读。
（由于工作量巨大，对 Skywalking 存储的改造仅限于存储链路数据，即 Segment，其余部分就抓大放小，仍使用 ElasticSearch 存储，没有进行改造）
表设计
ClickHouse 基本只能建立一种索引，即 Order By 的索引。而链路表查询条件众多，几乎每个字段都是查询条件，且包含多种排序，设计起来比较辣手。
查询条件：时间、服务名称、服务实例、链路类型、链路 ID、链路名称、响应时间、是否异常
排序条件：时间、响应时间
想要在一张表上设计出符合所有查询模式，基本是不可能的（或完全不可能），在参考了 jaeger-clickhouse 等众多设计后，更加坚定了这个结论。
尝试了数次后，最终的建表语句如下：

CREATE TABLE skywalking.segment ( `segment_id` String, `trace_id` String, `service_id` LowCardinality(String), `service_instance_id` LowCardinality(String), `endpoint_name` String, `endpoint_component_id` LowCardinality(String), `start_time` DateTime64(3), `end_time` DateTime64(3), `latency` Int32, `is_error` Enum8('success' = 0, 'error' = 1), `data_binary` String, INDEX idx_endpoint_name endpoint_name TYPE tokenbf_v1(2048, 2, 0) GRANULARITY 1, PROJECTION p_trace_id ( SELECT trace_id, groupArrayDistinct(service_id), min(start_time) AS min_start_time, max(start_time) AS max_start_time GROUP BY trace_id ) ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(start_time) ORDER BY (start_time, service_id, endpoint_name, is_error) TTL toDateTime(start_time) + toIntervalDay(10)

首先，在 partition 上还是使用了天作为条件。在 Order By 时，使用时间 + 服务 + 链路名称 + 异常。为什么不是服务 + 时间，因为在很多查询中，时间作为条件的情况比服务作为条件的频率更高，如果在服务放在前边，大部分时候 ClickHouse 需要在一个文件的不同部分去遍历，IO 会变得分散。