关于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 会变得扩散。