本文将从以下五部分切入，讲述日志系统的演进之路：携程日志的背景和现状、如何搭建一套日志系统、从 ElasticSearch 到 Clickhouse 存储演进、日志3.0重构及未来计划。
一、日志背景及现状
图1
2012年以前，携程的各个部门日志自行收集治理（如图1）。这样的方式缺乏统一标准，不便治理管控，也更加消耗人力和物力。
从2012年开始，携程技术中心推出基于 ElasticSearch 的日志系统，统一了日志的接入、ETL、存储和查询标准。随着业务量的增长，数据量膨胀到 4PB 级别，给原来的 ElasticSearch 存储方案带来不少挑战，如 OOM、数据延迟及负载不均等。此外，随着集群规模的扩大，成本问题日趋敏感，如何节省成本也成为一个新的难题。
2020年初，我们提出用 Clickhouse 作为主要存储引擎来替换 ElasticSearch 的方案，该方案极大地解决了 ElasticSearch 集群遇到的性能问题，并且将成本节省为原来的48%。2021年底，日志平台已经累积了20+PB 的数据量，集群也达到了数十个规模（如图2）。
2022年开始，我们提出日志统一战略，将公司的 CLOG 及 UBT 业务统一到这套日志系统，预期数据规模将达到 30+PB。同时，经过两年多的大规模应用，日志集群累积了各种各样的运维难题，如集群数量激增、数据迁移不便及表变更异常等。因此，日志3.0应运而生。该方案落地了类分库分表设计、Clickhouse on Kubernetes、统一查询治理层等，聚焦解决了架构和运维上的难题，并实现了携程 CLOG 与 ESLOG 日志平台统一。
图2
二、如何搭建日志系统
2.1 架构图
从架构图来看（如图3），整个日志系统可以分为：数据接入、数据 ETL、数据存储、数据查询展示、元数据管理系统和集群管理系统。
图3
2.2 数据接入
数据接入主要有两种方式：
第一种是使用公司框架 TripLog 接入到消息中间件 Kafka（Hermes协议）（如图4）。
图4
第二种是用户使用 Filebeat/Logagent/Logstash 或者写程序自行上报数据到 Kafka（如图5），再通过 GoHangout 写入到存储引擎中。
图5
2.3 数据传输ETL（GoHangout）
GoHangout 是仿照 Logstash 做的一个开源应用（Github链接），用于把数据从 Kafka 消费并进行 ETL，最终输出到不同的存储介质（Clickhouse、ElasticSearch）。其中数据处理 Filter 模块包含了常见的 Json 处理、Grok 正则匹配和时间转换等一系列的数据清理功能（如图6）。GoHangout 会将数据 Message 字段中的 num 数据用正则匹配的方式提取成单独字段。
图6
2.4 ElasticSearch 数据存储
早期2012年第一版，我们使用 ElasticSearch 作为存储引擎。ElasticSearch 存储主要由 Master Node、Coordinator Node、Data Node 组成（如图7）。Master 节点主要负责创建或删除索引，跟踪哪些节点是集群的一部分，并决定哪些分片分配给相关的节点；Coordinator 节点主要用于处理请求，负责路由请求到正确的节点，如创建索引的请求需要路由到 Master 节点；Data 节点主要用于存储大量的索引数据，并进行增删改查，一般对机器的配置要求比较高。
图7
2.5 数据展示
数据展示方面我们使用了 Elastic Stack 家族的 Kibana（如图8）。Kibana 是一款适合于 ElasticSearch 的数据可视化和管理工具，提供实时的直方图、线形图、饼状图和表格等，极大地方便日志数据的展示。
图8
2.6 表元数据管理平台
表元数据管理平台是用户接入日志系统的入口，我们将每个 Index/ Table 都定义为一个Scenario（如图9）。我们通过平台配置并管理 Scenario 的一些基础信息，如：TTL、归属、权限、ETL 规则和监控日志等。
图9
三、 从Elasticsearch到Clickhouse
我们将会从背景、Clickhouse 简介、ElasticSearch 对比和解决方案四方面介绍日志从 ElasticSearch 到 Clickhouse 的演进过程。2020年初，随着业务量的增长，给 ElasticSearch 集群带来了不少难题，主要体现在稳定性、性能和成本三个方面。
（1）稳定性上：
- ElasticSearch 集群负载高，导致较多的请求 Reject、写入延迟和慢查询。
- 每天 200TB 的数据从热节点搬迁到冷节点，也有不少的性能损耗。
- 节点间负载不均衡，部分节点单负载过高，影响集群稳定性。
- 大查询导致 ElasticSearch 节点 OOM。
（2）性能上：
- ElasticSearch的吞吐量也达到瓶颈。
- 查询速度受到整体集群的负载影响。
（3）成本上：
- 倒排索引导致数据压缩率不高。
- 大文本场景性价比低，无法保存长时间数据。
3.1 Clickhouse 简介与 Elasticsearch 对比
Clickhouse 是一个用于联机分析（OLAP）的列式数据库管理系统（DBMS）。Yandex 在2016年开源，使用 C++ 语法开发，是一款PB级别的交互式分析数据库。包含了以下主要特效：列式存储、Vector、Code Generation、分布式、DBMS、实时OLAP、高压缩率、高吞吐、丰富的分析函数和 Shared Nothin g架构等。
图10
Clickhouse采用的是 SQL 的交互方式，非常方便上手。接下来，我们将简单介绍一下 Clickhouse 的类 LSM、排序键、分区键特效，了解 Clickhouse 的主要原理。
首先，用户每批写入的数据会根据其排序键进行排序，并写入一个新的文件夹（如201905_1_1_0），我们称为 Part C0（如图10）。随后，Clickhouse 会定期在后台将这些 Part 通过归并排序的方式进行合并排序，使得最终数据生成一个个数据顺序且空间占用较大的 Part。这样的方式从磁盘读写层面上看，能充分地把原先磁盘的随机读写巧妙地转化为顺序读写，大大提升系统的吞吐量和查询效率，同时列式存储+顺序数据的存储方式也为数据压缩率提供了便利。201905_1_1_0与201905_3_3_0合并为201905_1_3_1就是一个经典的例子。
另外，Clickhouse 会根据分区键（如按月分区）对数据进行按月分区。05、06月的数据被分为了不同的文件夹，方便快速索引和管理数据。
图11
我们看中了 Clickhouse 的列式存储、向量化、高压缩率和高吞吐等特效（如图11），很好地满足了我们当下日志集群对性能稳定性和成本的诉求。于是，我们决定用Clickhouse来替代原本 ElasticSearch 存储引擎的位置。
3.2 解决方案
有了存储引擎后，我们需要实现对用户无感知的存储迁移。这主要涉及了以下的工作内容（如图12）：自动化建表、GoHangout 修改、Clickhouse 架构设计部署和 Kibana 改造。
图12
（1）库表设计
图13
我们对ck在日志场景落地做了很多细节的优化（如图13），主要体现在库表设计：
- 我们采用双 list 的方式来存储动态变化的 tags（当然最新的版本22.8，也可以用map和新特性的 json 方式）。
- 按天分区和时间排序，用于快速定位日志数据。
- Tokenbf_v1 布隆过滤用于优化 term 查询、模糊查询。
- _log_increment_id 全局唯一递增 id，用于滚动翻页和明细数据定位。
- ZSTD 的数据压缩方式，节省了40%以上的存储成本。
（2）Clickhouse 存储设计
Clickhouse 集群主要由查询集群、多个数据集群和 Zookeeper 集群组成（如图14）。查询集群由相互独立的节点组成，节点不存储数据是无状态的。数据集群则由Shard组成，每个 Shard 又涵盖了多个副本 Replica。副本之间是主主的关系（不同于常见的主从关系），两个副本都可以用于数据写入，互相同步数据。而副本之间的元数据一致性则有 Zookeeper 集群负责管理。
图14
（3）数据展示
为了实现用户无感知的存储切换，我们专门实现了 Kibana 对 Clickhouse 数据源的适配并开发了不同的数据 panel（如图15），包括：chhistogram、chhits、chpercentiles、chranges、chstats、chtable、chterms 和 chuniq。通过 Dashboard 脚本批量生产替代的方式，我们快速地实现了原先 ElasticSearch 的 Dashboard 的迁移，其自动化程度达到95%。同时，我们也支持了使用 Grafana 的方式直接配置 SQL 来生成日志看板。
图15
（4）集群管理平台
为了更好地管理 Clickhouse 集群，我们也做了一整套界面化的 Clickhouse 运维管理平台。该平台覆盖了日常的 shard 管理、节点生成、绑定/解绑、权重修改、DDL 管理和监控告警等治理工具（如图16）。
图16
3.3 成果
- 迁移过程自动化程度超过95%，基本实现对用户透明。
- 存储空间节约50+%（如图17），用原有ElasticSearch的服务器支撑了4倍业务量的增长。
- 查询速度比ElasticSearch快4~30倍，查询P90小于300ms，P99小于1.5s。
图17
四、 日志3.0构建
时间来到2022年，公司日志规模再进一步增加到 20+PB。同时，我们提出日志统一战略，将公司的 CLOG 及 UBT 业务统一到这套日志系统，预期数据规模将达到 30+PB。另外，经过两年多的大规模应用，日志系统也面临了各种各样的运维难题。
(1) 性能与功能痛点
- 单集群规模太大，Zookeeper 性能达到瓶颈，导致 DDL 超时异常。
- 当表数据规模较大时，删除字段，容易超时导致元数据不一致。
- 用户索引设置不佳导致查询慢时，重建排序键需要删除历史数据，重新建表。
- 查询层缺少限流、防呆和自动优化等功能，导致查询不稳定。
(2) 运维痛点
- 表与集群严格绑定，集群磁盘满后，只能通过双写迁移。
- 集群搭建依赖 Ansible，部署周期长（数小时）。
- Clickhouse 版本与社区版本脱节，目前集群的部署模式不便版本更新。
面对这样的难题，我们在2022年推出了日志3.0改造，落地了集群 Clickhouse on Kubernetes、类分库分表设计和统一查询治理层等方案，聚焦解决了架构和运维上的难题。最终，实现了统一携程 CLOG 与 ESLOG 两套日志系统。
4.1 ck on k8s
我们使用 Statefulset、反亲和、Configmap 等技术实现了 Clickhouse 和 Zookeeper 集群的 Kubernetes 化部署，使得单集群交付时间从2天优化到5分钟。同时，我们统一了部署架构，将海内外多环境部署流程标准化。这种方式显著地降低了运维成本并释放人力。更便利的部署方式有益于单个大集群的切割，我们将大集群划分为多个小集群，解决了单集群规模过大导致 Zookeeper 性能瓶颈的问题。
4.2 类分库分表设计
图18
（1）数据跨如何跨集群
假设我们有三个数据集群1、2、3和三个表A、B、C（如图18）。在改造之前，我们单张表（如A）只能坐落在一个数据集群1中。这样的设计方式，导致了当集群1磁盘满了之后，我们没有办法快速地将表A数据搬迁到磁盘相对空闲的集群2中。我们只能用双写的方式将表A同时写入到集群1和集群2中，等到集群2的数据经过了TTL时间（如7天）后，才能将表A从数据集群1中删除。这样，对我们的集群运维管理带来了极大的不方便和慢响应，非常耗费人力。
于是，我们设计一套类分库分表的架构，来实现表A在多个集群1、2、3之间来回穿梭。我们可以看到右边改造后，表A以时间节点作为分库分表的切换点（这个时间可以是精确到秒，为了好理解，我们这里以月来举例）。我们将6月份的数据写入到集群1、7月写到集群2、8月写到集群3。当查询语句命中6月份数据时，我们只查询集群1的数据；当查询语句命中7月和8月的数据，我们就同时查询集群2和集群3的数据。
我们通过建立不同分布式表的方式实现了这个能力（如：分布式表tableA_06/tableA_07/tableA_08/tableA_0708，分布式表上的逻辑集群则是是集群1、2、3的组合）。这样，我们便解决了表跨集群的问题，不同集群间的磁盘使用率也会趋于平衡。
（2）如何修改排序键不删除历史数据
非常巧妙的是，这种方式不仅能解决磁盘问题。Clickhouse 分布式表的设计只关心列的名称，并不关心本地数据表的排序键设置。基于这种特性，我们设计表A在集群2和集群3使用不一样的排序键。这样的方式也能够有效解决初期表A在集群2排序键设计不合理的问题。我们通过在集群3上重新建立正确的排序键，让其对新数据生效。同时，表A也保留了旧的7月份数据。旧数据会在时间的推移一下被TTL清除，最终数据都使用了正确的排序键。
（3）如何解决删除大表字段导致元数据不一致
更美妙的是，Clickhouse 的分布式表设计并不要求表A在7月和8月的元数据字段完全一致，只需要有公共部分就可以满足要求。比如表A有在7月有11个字段，8月份想要删除一个弃用的字段，那么只需在集群3上建10个字段的本地表A，而分布式表 tableA_0708 配置两个表共同拥有的10个字段即可（这样查分布式表只要不查被删除的字段就不会报错）。通过这种方式，我们也巧妙地解决了在数据规模特别大的情况下（单表百TB），删除字段导致常见的元数据不一致问题。
（4）集群升级
同时，这种多版本集群的方式，也能方便地实现集群升级迭代，如直接新建一个集群4来存储所有的09月的表数据。集群4可以是社区最新版本，通过这种迭代的方式逐步实现全部集群的升级。
4.3 元数据管理
为了实现上述的功能，我们需要维护好一套完整的元数据信息，来管理表的创建、写入和 DDL（如图19）。该元数据包含每个表的版本定义、每个版本数据的数据归属集群和时间范围等。
图19
4.4 统一查询治理层
（1）Antlr4 的 SQL 解析
在查询层，我们基于 Antlr4 技术，将用户的查询 SQL 解析成 AST 树。通过 AST 树，我们能够快速地获得 SQL 的表名、过滤条件、聚合维度等（如图20）。我们拿到这些信息后，能够非常方便地对 SQL 实时针对性的策略，如：数据统计、优化改写和治理限流等。
图20
（2）查询代理层
图21
我们对所有用户的SQL查询做了一层统一的查询网关代理（如图21）。该程序会根据元数据信息和策略对用户的 SQL 进行改写，实现了精准路由和性能优化等功能。同时，该程序会记录每次查询的明细上下文，用于对集群的查询做统一化治理，如：QPS 限制、大表扫描限制和时间限制等拒绝策略，来提高系统的稳定性。
五、未来计划
通过日志3.0的构建，我们重构了日志系统的整体架构，实现集群 Kubernetes 化管理，并成功地解决了历史遗留的 DDL 异常、数据跨集群读写、索引重构优、磁盘治理和集群升级等运维难题。2022年，日志系统成果地支撑了公司 CLOG 与 UBT 业务的数据接入，集群数据规模达到了30+PB。
当然，携程的日志系统演进也不会到此为止，我们的系统在功能、性能和治理多方面还有不少改善的空间。在未来，我们将进一步完善日志统一查询治理层，精细化地管理集群查询与负载；推出日志预聚合功能，对大数据量的查询场景做加速，并支持 AI智能告警；充分地运用云上能力，实现弹性混合云，低成本支撑节假日高峰；推到日志产品在携程系各个公司的使用覆盖等。让我们一起期待下一次的日志升级。
