关于clickhouse:使用-ClickHouse-构建通用日志系统

序言

ClickHouse 是一款罕用于大数据分析的 DBMS，因为其压缩存储，高性能，丰盛的函数等个性，近期有很多尝试 ClickHouse 做日志零碎的案例。本文将分享如何用 ClickHouse 做出通用日志零碎。

日志零碎简述

在聊为什么 ClickHouse 适宜做日志零碎之前，咱们先谈谈日志零碎的特点。

1. 大数据量。对开发者来说日志最不便的观测伎俩，而且很多状况下会间接打印 HTTP、RPC 的申请响应日志，这基本上就是把网络流量复制了一份。
2. 非固定检索模式。用户有可能应用日志中的任意关键字任意字段来查问。
3. 老本要低。日志零碎不宜在 IT 老本中占比过高。
4. 即席查问。日志对时效性要求广泛较高。
5. 数据量大，检索模式不固定，既要快，还得便宜。所以日志是一道难解的题，它的需要简直违反了计算机的根本准则，不过幸好它还留了一扇窗，就是对并发要求不高。大部分查问是人为即兴的，即便做一些定时查问，所检索的范畴也肯定无限。

现有日志计划

ElasticSearch

ES 肯定是最深入人心的日志零碎了，它能够满足大数据量、全文检索的需要，但在老本与查问效率上很难均衡。ES 对老本过于敏感，配置低了查问速度会降落得十分厉害，保障查问速度又会大幅提高老本。

Loki

Grafana 推出的日志零碎。理念上比拟合乎日志零碎的需要，但当初还只是个玩具而已。不适宜大规模应用。

三方日志服务

国内比拟卓越的有阿里云日志服务，国外的 Humio、DataDog 等，都是摈弃了 ES 技术体系，从存储上重做。国内还有观测云，只不过其存储还是 ES，没什么技术冲破。

值得一提的是阿里云日志服务，它对接了诸如 OpenTracing、OpenTelemetry 等规范，能够接入监控、链路数据。因为链路数据与日志具备很高的相似性，齐全能够用同一套技术栈搞定。

三方服务长处是日志摄入形式、查问性能、数据分析、监控告警、冷热拆散、数据备份等性能完备，不须要用户自行开发保护。

毛病是贵，尽管都说比 ES 便宜，但那是在雷同性能下，正常人不会堆这么多机器谋求高性能。最初是要把日志数据交给他人，怎么想都不太释怀。

ClickHouse 适宜做日志吗？

从第一性准则来剖析，看看 ClickHouse 与日志场景是否符合。

大数据量，ClickHouse 作为大数据产品显然是合乎的。

非固定模式检索，其自身就是张表，如果只输出关键字没有列名的话，搜寻所有列对 ClickHouse 来说显然是效率低下的。但此问题也有解，后文会提到。

成本低，ClickHouse 的压缩存储可将磁盘需要缩小一个数量级，并能进步检索速度。与之相比，ES 还须要大量空间保护索引。

即席查问，即席有两个方面，一个是数据可见工夫，ClickHouse 写入的能力较 ES 更强，且写入实现即可见，而 ES 须要 refresh_interval 配置起码 30s 来保障写入性能；另一方面是查问速度，通常单台 ClickHouse 每秒钟可扫描数百万行数据。

ClickHouse 日志计划比照

很多公司如京东、唯品会、携程等等都在尝试，也写了很多文章，然而大部分都不是「通用日志零碎」，只是针对一种固定类型的日志，如 APP 日志，拜访日志。所以这类计划不具备普适性，没有效仿施行的必要，在我看来他们只是传播了一个信息，就是 ClickHouse 能够做日志，并且老本的确有升高。

只有 Uber 的 日志计划真正值得参考，他们将本来基于 ELK 的日志零碎全面替换成了 ClickHouse，并承接了零碎内的所有日志。

咱们的日志计划也是从 Uber 登程，应用 ClickHouse 作为存储，同时参考了三方日志服务中的优良性能，从前到后构建了一套通用日志零碎。ClickHouse 就像一块璞玉，像 ELK 日志零碎中的 Lucene，尽管它底子不过，但还须要大量的工作。

先说成绩

ClickHouse 日志零碎对接了 Java 服务端日志、客户端日志、Nginx 日志等，与云平台相比，日志方面的总成本缩小了 ~85%，多存储了 ~80% 的日志量，均匀查问速度升高了 ~80%。

平台仅用了三台服务器，存储了几百 TB 原始日志，高峰期摄入 500MB/s 的原始日志，每日查问超过 200W 次。

老本只是主要，好用才是第一位的，如何能力做出让开发拍案叫绝，巴不得天天躺在日志里打滚的日志零碎。

设计

存储设计

存储是最外围的局部，存储的设计也会限度最终能够实现哪些性能，在此借鉴了 Uber 的设计并进一步改良。建表语句如下:

create table if not exists log.unified_log
(
    -- 项目名称
    `project`        LowCardinality(String),
    -- DoubleDelta 相比默认能够缩小 80% 的空间并减速查问
    `dt`             DateTime64(3) CODEC(DoubleDelta, LZ4),
    -- 日志级别
    `level`          LowCardinality(String),
    -- 键值应用一对 Array，查问效率相比 Map 会有很大晋升
    `string.keys`    Array(String),
    `string.values`  Array(String),
    `number.keys`    Array(String),
    `number.values`  Array(Float64),
    `unIndex.keys`   Array(String),
    -- 非索引字段独自保留，进步压缩率
    `unIndex.values` Array(String) CODEC (ZSTD(15)),
    `rawLog`         String,

    -- 建设索引减速低命中率内容的查问
    INDEX idx_string_values `string.values` TYPE tokenbf_v1(4096, 2, 0) GRANULARITY 2,
    INDEX idx_rawLog rawLog TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1,

    -- 应用 Projection 记录 project 的数量，工夫范畴，列名等信息
    PROJECTION p_projects_usually (SELECT project, count(), min(dt), max(dt), groupUniqArrayArray(string.keys), groupUniqArrayArray(number.keys), groupUniqArrayArray(unIndex.keys) GROUP BY project)
)
ENGINE = MergeTree
    PARTITION BY toYYYYMMDD(dt)
    ORDER BY (project, dt)
    TTL toDateTime(dt) + toIntervalDay(30);

表中的根本元素如下

• project: 项目名称
• dt: 日志的工夫
• level: 日志级别
• rawLog: JSON 格局，记录日志的注释，以及冗余了 string.keys、string.values

一条日志肯定合乎这些根本元素，即日志的起源，工夫，级别，注释。结构化字段能够为空，都输入到注释。

表数据排序应用了 ORDER BY (project, dt)，order by 是数据在物理上的存储程序，将 project 放在前边，能够防止不同 project 之间互相烦扰。典型的反例是 ElasticSearch，通常在咱们会将所有后端服务放在一个索引上，通过字段标识来辨别。于是查问服务日志时，会受整体日志量的影响，即便你的服务没几条日志，查起来还是很慢。

也就是不偏心，90% 的服务受到 10% 服务的影响，因为这 10% 耗费了最多的存储资源，连累了所有服务。如果将 project 放在前边，数据量小的查问快，数据量大的查问慢，彼此不会相互影响。

然而 PARTITION BY toYYYYMMDD(dt) 中却没有 project，因为 project 的数量可能会十分大，会导致 partition 数量不受管制。

架构设计

解决了外围问题后，咱们设计了一整套架构，使之可能成为通用日志零碎。整体架构如下:

在零碎中有如下角色:

• 日志上报服务

  • 从 Kafka 中获取日志，解析后投递到 ClickHouse 中
  • 备份日志到对象存储

• 日志管制面

  • 负责与 Kubernetes 交互，初始化、部署、运维 ClickHouse 节点
  • 提供外部 API 给日志零碎内其余服务应用
  • 治理日志数据生命周期

• 日志查问服务

  • 将用户输出的类 Lucene 语法，转换成 SQL 到 ClickHouse 中查问
  • 给前端提供服务
  • 提供 API 给公司外部服务
  • 监控告警性能
• 日志前端

ClickHouse 部署架构

ClickHouse 的集群治理性能比拟孱弱，很容易呈现集群状态不对立，集群命令卡住的状况，很多状况下不得不被迫重启节点。联合之前的运维教训以及参考 Uber 的做法，咱们将 ClickHouse 分为读取节点（ReadNode）与数据节点（DataNode）:

• ReadNode: 不存储数据。存储集群信息，负责转发所有查问。目前 2C 8G 的单节点也没有任何压力。
• DataNode: 存储数据。不关怀集群信息，不连贯 ZooKeeper，每个 DataNode 节点互相都是独立的。线上每个节点规格为 32C 128G。

因为 ReadNode 不波及具体查问，只在集群拓扑信息变更时重载配置文件或重启。因为不存储什么数据，重启速度也十分快。DataNode 则通常没有理由重启，能够放弃十分稳固的状态提供服务。

扩缩容问题

ReadNode 拉起节点即可提供服务，扩缩容不成问题，但很难遇到须要扩容的场景。

DataNode 扩缩容后有数据不平衡的问题。缩容比拟好解决，在日志管制面标记为待下线，进行日志写入，随后通过在其余节点 insert into log.unified_log SELECT * FROM remote('ip', log.unified_log, 'user', 'password') where dt between '2022-01-01 00:00' and '2022-01-01 00:10' 以 10 分钟为单位，将数据平均搬运到残余的节点后，下线并开释存储即可。

扩容想要数据平衡则比拟难，数据写入新节点容易，在旧节点删除掉难。因为 ClickHouse 的机制，删除操作是十分低廉的，尤其是删除大量数据时。所以最好是提前扩容，或者是存算拆散避免原节点存储被打满。

日志摄入

日志上报服务通过 Kafka 来获取日志，除了规范格局外，还能够配置不同的 Topic 有不同的解析规定。例如对接 Nginx 日志时，通过 filebeat 监听日志文件并发送到 kafka，日志上报服务进行格局解析后投递到 ClickHouse。

日志从发送到 Kakfa、读取、写入到 ClickHouse 全程都是压缩的，仅在日志上报服务中短暂解压，且解压后马上写入 Gzip Stream，内存中不保留日志原文。

而抉择 Kafka 而不是间接提供接口，因为 Kafka 能够提供数据暂存，重放等。这些对数据的可靠性，零碎灵活性有很大的帮忙，之后在冷数据恢复的时候也会提到。

在 Java 服务上，咱们提供了十分高效的 Log4j2 的 Kafka Appender，反对动静更换 kafka 地址，能够从 MDC 获取用户自定义列，并提供工具类给用户。

查问

查问语法

在查问上参考了 Lucene、各种云厂商，得出在日志查问场景，类 Lucene 语法是最为简洁易上手的。设想当你有一张千亿条数据的表，且字段的数量不确定，应用 SQL 语法筛选数据无疑是十分艰难的。而 Lucene 的语法人造反对高效的筛选、反筛选。
但原生 Lucene 语法又有肯定的复杂性，简化后的语法可反对如下性能:

• 关键词查问

  • 应用任意日志内容进行全文查问，如 ERROR /api/user/list

• 指定列查问

  • trace_id: xxxx user_id: 12345
  • key:* 示意筛选存在该列的日志

• 短语查问

  • 匹配一段残缺文字，如 message: "userId not exists"
  • 查问内容含有保留字的状况，如 message: "userId:123456"

• 含糊查问

  • *Exception*、logger: org.apache.*

• 多值查问

  • user_id: 1,2,3 等价于 user_id: 1 OR user_id: 2 OR user_id: 3，在简单查问下很不便，如 level:warn AND (user_id: 1 OR user_id: 2 OR user_id: 3) 即可简写为 level:warn AND user_id:1,2,3

• 数字查问

  • 反对 > = <，如 http.elapsed > 100
  • 一条日志中的两个列也可相互比拟，如 http.elapsed > http.expect_elapsed

• 连接符

  • AND、OR、NOT
  • 用小括号示意优先级，如 a AND (b OR c)

日志查问服务会将用户输出的类 Lucene 语法转换为理论的 SQL。

全文查问

该性能堪称是 ElasticSearch 的杀手锏，难以想象无奈全文检索的日志零碎会是什么体验，而很多公司就这么做了，如果查问必须指定字段，体验上想来不会怎么愉悦。

咱们通过将结构化列冗余到 rawLog 中实现了全文查问，同时对 rawLog 配置了跳数索引 tokenbf_v1 解决大数据量必须遍历的问题。一条 rawLog 的内容如下:

{
    "project": "xxx-server",
    "dt": 1658160000058,
    "level": "INFO",
    "string$keys": [
        "trace_ext.endpoint_name",
        "trace_id",
        "trace_type"
    ],
    "string$values": [
        "/api/getUserInfo",
        "b7f7ae4a-f9ed-403a-b06c-ed46b84ba2a6",
        "SpringMVC"
    ],
    "unIndex$keys": ["http.header"],
    "message": "HTTP requestLog"
}

当用户查问 b7f7ae4a-f9ed-403a-b06c-ed46b84ba2a6 时，则应用 multiSearchAny(rawLog, ['b7f7ae4a-f9ed-403a-b06c-ed46b84ba2a6']) 查问 rawLog 字段；

当用户查问 trace_id: 7f7ae4a-f9ed-403a-b06c-ed46b84ba2a6 时，则应用 has(string.values, '7f7ae4a-f9ed-403a-b06c-ed46b84ba2a6') AND string.values[indexOf(string.keys, 'trace_id')] = '7f7ae4a-f9ed-403a-b06c-ed46b84ba2a6' 到列中查问。

在理论应用中，即便应用列查问，也会应用筛选条件 multiSearchAny(rawLog, 'xxx')，因为 rawLog 的索引足够大，很多状况下过滤成果 更好。

查问后果 rawLog 与 unIndex.keys、unIndex.values 形成了一条残缺的日志。这样 where 条件中应用列进行过滤，select 的列则根本收敛到 rawLog 上，可大大提高查问性能。

跳数索引

尽管 ClickHouse 的性能比拟强，如果只靠遍历数据量太大仍然比拟吃力。

在理论应用中，应用链路 ID、用户 ID 搜寻的场景比拟多，这类搜寻的特点是工夫范畴可能不确定，关键词的区分度很高。如果能针对这部分查问减速，就能很大水平上解决问题。

ClickHouse 提供了三种字符串可用的跳数索引，均为布隆过滤器，别离如下:

• bloom_filter 不对字符串拆分，间接应用整个值。
• ngrambf_v1 会将每 N 个字符进行拆分。如果 N 太小，会导致总后果集太小，没有任何过滤成果。如果 N 太大，比方 10，则长度低于 10 的查问不会用到索引，这个度十分难拿捏。而且按每 N 字符拆分开销未免过大，当 N 为 10，字符串长度为 100 时，会拆出来 90 个字符串用于布隆过滤器索引。
• tokenbf_v1 按非字母数字字符（non-alphanumeric）拆分。相当于按符号分词，而通常日志中会有大量符号。

只有 tokenbf_v1 是最适宜的，但也因而带来了一些限度，如中文不能分词，只能整段当做关键词或应用含糊搜寻。或者遇到中文符号（全角符号）搜不进去，因为不属于 non-alphanumeric 的范畴，所以相似 订单 ID：1234 不能用 订单 ID、1234 来进行搜寻，因为这里的冒号是全角的。

但 tokenbf_v1 的确是现阶段惟一可用的了，于是咱们建了一个很大的跳数索引 INDEX idx_rawLog rawLog TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1，大概会多应用 4% 的存储能力达到比拟好的筛选成果。以下是应用索引前后的比照，用 trace_id 查问 1 天的日志:

-- 不应用索引，耗时 61s
16 rows in set. Elapsed: 61.128 sec. Processed 225.35 million rows, 751.11 GB (3.69 million rows/s., 12.29 GB/s.)

-- 应用索引，耗时不到 1s
16 rows in set. Elapsed: 0.917 sec. Processed 2.27 thousand rows, 7.00 MB (2.48 thousand rows/s., 7.63 MB/s.)

-- 应用 set send_logs_level='debug' 能够看到索引过滤掉了 99.99% 的块
<Debug> log.unified_log ... (SelectExecutor): Index `idx_rawLog` has dropped 97484/97485 granules.

持续减少时间跨度差距会更加显著，不应用索引须要几百秒能力查到，应用索引依然在数秒内即可查到。

跳数索引的原理和稠密索引相似，因为在 ClickHouse 中数据曾经被压缩成块，所以跳数索引是针对整个块的数据，在查问时筛选出有可能在的块，再进入到块中遍历查问。如果搜寻的关键词普遍存在，应用索引反而会加速，如下图所示:

字段类型问题

ElasticSearch 在应用时会遇到字段类型推断问题，一个字段有可能第一次以 Long 模式呈现，但后续多了小数点成了 Float，一旦字段类型不兼容，后续的数据在写入时会被抛弃。于是咱们大部分时候都被迫抉择事后创立固定类型的列，限度服务打印日志时不能随便自定义列。

在日志零碎中，咱们首先创立了 number.keys, number.values 来保留数字列，并将这些字段在 string.keys, string.values 里冗余了一份，这样在查问的时候不必思考列对应的类型，以及类型变动等简单场景，只须要晓得用户的搜寻形式。

如查问 responseTime > 1000 时，就到 number 列中查问，如果查问 responseTime: 1000，就到 string 列中查问。

所有都为了给用户一种无需思考的查问形式，不必思考它是不是数字，当它看起来像数字时，就能够用数字的形式搜寻。同时也不须要事后创立日志库，创立日志列，创立解析模式等。当你开始打印，日志就呈现了。

非索引字段

咱们也提供了 unIndex 字段，配合 SDK 的实现用户能够将局部日志输入到非索引字段。在 unIndex 中的内容会被更无效地压缩，不占用 rawLog 字段可大幅减速全文查问，只在查问后果中展现。

日志剖析

如果仅仅是浏览，人眼能看到的日志只占总量的极少局部。尤其在动辄上亿的量级下，咱们往往只关注异样日志，偶然查查某条链路日志。这种状况下数据的检索率，或者只有百万分之一。

而业务上应用的数据库，某张表只有几千万条数据，一天却要查上亿次的状况不足为奇。

大量日志写入后直到过期，也没有被检索过。通过剖析日志来进步检索率，进步数据价值，很多时候不是不想，而是难度太高。比方有很多实际是用 hdfs 存储日志，flink 做剖析，技术栈和工程简单不说，增加新的剖析模式不灵便，甚至无奈发现新的模式。

ClickHouse 最弱小的中央，正是其强悍到令人发指的剖析性能。如果只是用来寄存、检索日志，无疑大材小用。如果做到存储剖析一体，不仅架构上会简化，剖析能力也能够大大提高，做到让死日志活起来。

于是咱们通过一系列性能，让用户可能无效利用 ClickHouse 的剖析能力，去开掘发现有价值的模式。

ClickHouse 最弱小的中央，正是其强悍到令人发指的剖析性能。如果只是用来寄存、检索日志，无疑大材小用。如果做到存储剖析一体，不仅架构上会简化，剖析能力也能够大大提高，做到让死日志活起来。

于是咱们通过一系列性能，让用户可能无效利用 ClickHouse 的剖析能力，去开掘发现有价值的模式。

疾速剖析

统计列的 TopN、占比、惟一数。

这个性能不算稀奇，在各种三方日志服务中算是标配。不过这里的疾速剖析列不必当时配置，一旦日志中呈现这个列，就马上在疾速剖析中可用。

为了这个性能，在日志表中创立了一个 Projection:

PROJECTION p_projects_usually (SELECT project, count(), min(dt), max(dt), groupUniqArrayArray(string.keys), groupUniqArrayArray(number.keys), groupUniqArrayArray(unIndex.keys) GROUP BY project)

这样一来实时查问我的项目的所有列变得十分快，不必思考在查问服务中做缓存，同时这些列名也帮忙用户查问时主动补全:

但疾速查问最麻烦的是难以对资源进行管制，日志数量较多时或查问条件简单时，疾速剖析很容易超时变成慢速剖析。所以咱们管制最多扫描 1000w 行，并利用 over() 在单条 SQL 中同时查出聚合与明细后果:

select logger, 
count() as cnt,
sum(cnt) over() as sum,
uniq(logger) over() as uniq from 
(select string.values[indexOf(string.keys, 'logger')] as logger
        from unified_log where project= 'xx-api-server' and dt between '2022-08-01' and '2022-08-01' and rawLog like '%abc%'
      limit 1000000
)
group by logger order by cnt desc limit 100;

高级直方图

直方图用来批示工夫与数量的关系，在此之上咱们又加了一个维度，列统计。

即直方图是由日志级别重叠而成的，不同日志级别定义了灰蓝橙红等不同色彩，不须要搜寻也能让用户一眼看到是不是呈现了异样日志:

同时它还能够和疾速剖析联合，让直方图可应用任意列进行统计:

这个性能曾胜利帮忙业务方定位 MQ 生产沉积的问题，过后发现在一些工夫点，只有个别线程在进行生产，而在平时每个线程生产数量都很平均。

杀手锏 – 高级查问

很多日志都是没有结构化的内容，如果能现场抽取这些内容并剖析，则对开掘日志数据大有帮忙。当初咱们曾经有了一套语法来检索日志，但这套语法无论如何也不适宜剖析。SQL 非常适合用来剖析，大部分开发者对 SQL 也并不生疏，说来也巧，ClickHouse 自身就是 SQL 语法。

于是咱们参考了阿里云日志服务，将语法通过管道符 | 一分为二，管道符前为日志查问语法，管道符后为 SQL 语法。管道符也能够有多个，前者是后者的子查问。

为了方便使用，咱们也对 SQL 进行了肯定简化，否则用户就要用 string.values[indexOf(string.keys, 'logger')] as logger 来获取字段，未免啰嗦。而 ClickHouse 中有 Map 类型，能够稍稍简化下用 string['logger'] as logger。语法结构:

上面用个残缺的例子看下，在服务日志中看到一些正告日志:

当初想统计有多少个不存在的工作节点，即「workerId=」后边的局部，查问语句如下:

工作节点不存在 | select sublen(message, 'workerId=', 10) as workerId, count() group by workerId

首先通过「工作节点不存在」筛选日志，再通过字符串截取获取具体的 ID，最初 group 再 count()，执行后果如下:

最终执行到 ClickHouse 的 SQL 则比较复杂，在该示例中是这样的:

SELECT
    sublen(message, 'workerId=', 10) AS workerId,
    COUNT()
FROM
    (
        SELECT
            dt,
            level,
            CAST((string.keys, string.values), 'Map(String,String)') AS string,
            CAST((number.keys, number.values),
                'Map(String,Float64)'
            ) AS number,
            CAST((unIndex.keys, unIndex.values),
                'Map(String,String)'
            ) AS unIndex,
            JSONExtractString(rawLog, 'message') AS message
        FROM
            log.unified_log_common_all
        WHERE
            project = 'xxx'
            AND dt BETWEEN '2022-08-09 21:19:12.099' AND '2022-08-09 22:19:12.099'
            AND (multiSearchAny(rawLog, [ '工作节点不存在']))
    )
GROUP BY
    workerId
LIMIT
    500

用户写的 SQL 当做父查问，咱们在子查问中通过 CAST 办法将一对数组拼成了 Map 交给用户应用，这样也能够无效管制查问的范畴。

而上面这个示例，则通过高级查问定位了受影响的用户。如下图日志，筛选条件为蕴含「流动不存在」，并导出 activityId、uid、inviteCode 字段

查问语句如下:

参加的流动不存在 and BIZ_ERROR 
| select dt, JSONExtractString(message, 'requestPayload') AS requestPayload 
| select dt, JSONExtractString(requestPayload, 'eventParam', 'uid') AS uid,
JSONExtractString(requestPayload, 'eventParam', 'activityId') AS activityId,
JSONExtractString(requestPayload, 'eventParam', 'inviteCode') AS inviteCode 

后果如下:

在后果中发现有反复的 uid、activityId 等，因为该日志是 HTTP 申请日志，用户会重复申请。所以还须要去重一下，在 ClickHouse 中有 limit by语法能够很不便地实现，当初高级查问如下:

参加的流动不存在 and BIZ_ERROR 
| select dt, JSONExtractString(message, 'requestPayload') AS requestPayload 
| select dt, JSONExtractString(requestPayload, 'eventParam', 'uid') AS uid,
JSONExtractString(requestPayload, 'eventParam', 'activityId') AS activityId,
JSONExtractString(requestPayload, 'eventParam', 'inviteCode') AS inviteCode 
limit 1 by uid, activityId

查问后果中可见曾经实现去重，后果数量也少了很多:

再进一步，也能够通过 inviteCode 邀请码在 Grafana 上创立面板，查看邀请码应用趋势，并创立告警

自定义函数

ClickHouse 反对 UDF(User Defined Functions)，于是也自定义了一些函数，方便使用。

• subend，截取两个字符串之间的内容
• sublen，截取字符串之后 N 位
• ip_to_country、ip_to_province、ip_to_city、ip_to_provider，IP 转城市、省份等
• JSONS、JSONI、JSONF: JSONExtractString、JSONExtractInt、JSONExtractFloat 的简写

日志周期治理

日志备份

咱们摸索了很多种日志备份形式，最开始是在日志上报服务中，读 Kafka 时另写一份到 S3 中，然而遇到了很多艰难。如果依照 project 的维度拆分，那么在 S3 上会产生十分多的文件。又尝试用 S3 的分片上传，但如果两头停机了，会失落很大一部分分片数据，导致数据失落重大；如果不依照 project 拆分，将所有服务的日志都放在一起，那么复原日志的时候会很麻烦，即便只须要复原 1GB 的日志，也要检索 1TB 的文件。

而 ClickHouse 自身的文件备份行不行呢，比方用 clickhouse-copier、ttl 等。首先问题还是无奈按 project 辨别，其次是这些在系统工程中，难以脱离人工执行。而如果应用 ttl，数据有可能没到 ttl 工夫就因故失落了。况且，咱们还要求不同的 project 有不同的保留工夫。

咱们的最终计划是，通过 ClickHouse 的 S3 函数实现。ClickHouse 备份复原语句如下:

-- 写入到 S3 
INSERT INTO FUNCTION s3('%s','%s', '%s', 'JSONCompactEachRow', 'dt DateTime64(3), project String, level String, string$keys Array(String), string$values Array(String), number$keys Array(String), number$values Array(Float64), unIndex$keys Array(String), unIndex$values Array(String) ,rawLog String', 'gzip') 
SELECT dt, project, level, string.keys, string.values, number.keys, number.values, unIndex.keys, unIndex.values, rawLog FROM log.unified_log where project = '%s' and dt between '%s' and '%s' order by dt desc limit 0,%d

-- 从 S3 复原
insert into log.unified_log (dt, project, level, string.keys, string.values, number.keys, number.values, unIndex.keys, unIndex.values, rawLog) 
select * from s3('%s','%s', '%s', 'JSONCompactEachRow', 'dt DateTime64(3), project String, level String, string$keys Array(String), string$values Array(String), number$keys Array(String), number$values Array(Float64), unIndex$keys Array(String), unIndex$values Array(String) ,rawLog String') 

在日志上报服务中，每晚 1 点会跑定时工作，将前一天的日志数据逐渐备份到 S3 中。

至于当天的日志，则有 Kafka 做备份，如果当天的日志丢了，则重置 kafka 的生产点位，从 0 点开始从新生产。

日志生命周期

在表的维度，有 ttl 设置。在日志管制面中可针对每个 project 配置保留工夫，通过定时工作，对超时的日志执行 delete 操作: alter table unified_log delete where project = 'api-server' and dt < '2022-08-01'

因为 delete 操作负载较高，在配置生命周期时须要留神，最好对量级较大的服务独立配置生命周期。因为 delete 实质是将 Part 中的数据读出来从新写入一遍，在过程中排除合乎 where 条件的数据。所以抉择日志量较大的服务，能力升高 delete 操作的开销，不然没有删除的必要。

同时日志管制面也会定时监控磁盘使用量，一旦超过 95% 则启动强制措施，从最远一天日志开始执行 alter table unified_log drop partition xxx，疾速删除数据开释磁盘，防止磁盘彻底塞满影响应用。

冷数据恢复

用户抉择好工夫范畴，指定过滤词后，执行数据恢复工作。

日志管制面会扫描 S3 上该服务的备份文件，并冻结文件（通常会对备份日志配置归档存储），期待文件冻结后，到 ClickHouse 中执行复原。此时用户在页面上能够看到日志复原进度，并能够间接浏览曾经复原的日志了。

被复原的日志会写入到一个新的虚构集群中，具体实现为在 DataNode 中创立新的表，如 unified_log_0801，在 ReadNode 中创立新的分布式表，连贯到新表中。查问时通过该分布式表查问即可。

在冷数据应用完后，删除之前创立出的表，防止长时间占用磁盘空间。

ClickHouse 性能浅谈

性能优化

ClickHouse 自身是一款十分高效且设计良好的软件，所以对它的优化也绝对比较简单，纵向扩容服务器配置即可线性进步，而扩容最次要的中央就在 CPU 和存储。

在执行查问时察看 CPU 是否始终很高，在 SQL 后增加参数 settings max_threads=n 看是否显著影响查问速度。如果加了线程显著查问速度进步，则阐明持续加 CPU 对进步性能是无效的。反之瓶颈则不在 CPU。

存储上最好抉择 SSD，尽量大的读写速度对查问速度帮忙是极大的。而随机寻址速度益处无限，只有保障表设计正当，最终的 Part 文件数量不会太多，那么大部分的读取都是程序的。

查看存储的瓶颈形式则很多，比方在查问时 Top 察看 CPU 的 wa 是否过高；通过 ClickHouse 命令行的查问速度联合列压缩比例，推断原始的读取速度；

而须要留神的是，如果列创立了很大的跳数索引，则可能在查问时会耗费一定量的工夫。因为跳数索引是针对块的，一个 part 中可能蕴含几千几万个块，就有几千几万个布隆过滤器，匹配索引时须要循环挨个匹配。比方上文中跳数索引示例中，查问 trace_id 破费了 0.917s，实际上从 trace log 能够看到，在索引匹配阶段花了 0.8s。

这个问题可能会在全文索引推出时失去缓解，因为布隆过滤器只能针对某几个块，布隆过滤器之间无奈合作，数据的理论维度是 块 → 过滤器。而全文索引（倒排索引）正好将这个关系倒过去，过滤器→块，索引阶段不必循环匹配，速度则会进步很多。不过最终还是看官网怎么实现了，而且全文索引在数据写入时的开销也肯定会比布隆过滤器高一些。

性能老本均衡

对我来说，日志天然是要充沛满足即席查问的，所以优先保障查问速度，而不是老本和存储时长。而这套日志零碎也能够依据不同的衡量，有不同的玩法。

性能优先型

在咱们的实际中，应用了云平台的自带 SSD 型机器，CPU 根本够用，能够提供极高的读写性能，单盘能够达到 3GB/s。在应用时咱们做了软 raid，来升高 ClickHouse 配置的复杂度。

这种部署老本也能做到很低，相比应用服务商的云盘，要低 70% 左右。

存储拆散型

存储应用服务商提供的云盘，长处是云盘能够随时扩容而且不丢数据。能够肯定水平上独自扩容存储量和读写能力。

毛病是云盘通常不便宜，低等级的云盘提供的读写能力较差，而且读写会受限于服务器的网络带宽。高等级的云盘须要配合高规格的服务器能力齐全施展。

齐全 S3 型

ClickHouse 的存储策略增加 S3 类型，并将表的 storage_policy 指定为 S3。这样利用 S3 极低的存储价格，根本不必放心存储费用问题。还能利用 S3 的生命周期治理来治理日志。

毛病是 S3 存储目前还不健全，可能会踩坑。S3 的性能当然也不算好，还会受限于单个 Bucket 的吞吐下限。不过用来承载低负载的场景还是很有价值的。

结语

基于 ClickHouse 构建的通用日志零碎，有心愿率领日志走向另一条路线，日志本就不应该是搜索引擎，而应该是大数据。将来日志的侧重点，应该更多从查问浏览，转向剖析开掘。

咱们也在摸索日志在定时剖析，批剖析上的能力，让日志可能施展出更大的价值。