SRE实战（02）——Clickhouse在好大夫服务治理中的落地应用

作者 | 方勇

我有一剑，可搬山，可填海！

上一篇分享了SRE的相关理论、概念，以及如何从技术债务入手来推进SRE建设（见：SRE实战(01) 初识+探索SRE如何推进好大夫在线技术债务改造），本篇再来聊一聊建设落地过程中遇到的一大问题。

随着SRE的概念逐步推广，越来越多的业务接入微服务治理平台，大量数据也随之而来，ElasticSearch对海量日志的实时分析逐渐出现了性能问题。另外，随着治理平台自身的发展以及各种监控大盘的陆续上马，业务研发对日志可视化的实时性要求也越来越高，查询的数据规模和范围也越来越大。

为了不让平台建设拖SRE落地的后腿，经过调研，我们最终选择了Clickhouse这一新生利器。接下来我来汇报一下，Clickhouse在好大夫微服务治理中是如何落地实战的。

微服务治理暴露出的数据存储问题

随着微服务架构在好大夫的推进，带来了诸多便利，同时服务间调用越来越复杂，也面临了一系系列难题：

• 如何离线分析识别出不合理的服务依赖?
• 基于链路分析如何快速定位问题？
• 如何控制成本存储亿级日志数据?
• 如何从亿级数据里提炼分析出有价值的指标？
• 如何实时分析亿级数据及时触发告警？
• 针对长期指标如何选存储引擎？
• 如何聚拢不同的数据源打造友好的可视化界面?
• ...

运营好微服务离不开三种数据分析：Metrics,Tracing,Logging。

首先Tracing日志反映微服务间的链路拓扑，分析服务性能，追踪定位链路问题。也就是常说的APM (Application Performance Management) 即应用性能管理分析。好大夫APM分析，是基于自研的TraceLog模型。

另外一类日志是服务运行时产生的log,如nginx,tomcat,服务自定义的日志等，好大夫服务运行时产生的日志LocalLog也有自己的一套规范。

Metrics主要用于监控告警，大部分指标提炼于Tracing和Logging。好大夫早期日志存储分析基于ELK体系，服务运行监控告警也是实时从ES数据源读取。APM则是离线分析后进行数据展示。

随着业务的发展，日志在不断增加，Elasticsearch存储压力越来越大，磁盘IO瓶颈逐渐显现。

另外告警项的增加，对时效性要求也越来越高，ES实时查询压力骤增。

APM部分场景需要实时查询，聚合，计算同比、环比等，原先的spark体系按不同维度离线分析的模式不再灵活，离线还带来了存储成本的骤增，分析后的数据比原始数据还要大，聚合的时间维度比较粗。不太满足实时异常定位分析。

再加上云原生的推进，产生的日志事件，传统的模式对云原生资源监控更加力不从心，从而引入了Prometheus体系。而Prometheus生态对长期持久化指标不太友好。

针对以上问题，一种主流的方案会选择拥抱大数据生态，Hadoop、Hiv、Storm、Spark、Flink等。

十字路口的抉择

基于成本和应用场景考虑，我们否定了Hadoop/Spark解决方案。

世间没有银弹，Hadoop体系也不例外。Hadoop/Spark体系高度集成化，在提供了巨大的方便同时，也带来了臃肿和复杂，各种组件强强组合，有时候显得过于笨重，也带来了巨大成本。

机器资源成本 + 运维成本 + 人力成本。

Hbase/Hiv存储基于物理机，再加上计算节点需要十多台物理机。整体部署的成本和运维成本都比较高。

再者系统架构组内成员趋向Golang开发，而大数据生态偏向Java。

同时大数据部门和系统架构部分属两个不同的组织架构，根据“康威定律”，这将带来的巨大的无形沟通成本。

那有没有不依赖Hadoop生态体系的解决方案呢？

回到原点

其实我们更多的使用场景是：

• 实时性: 实时查询服务QPS/P99
• 按不同维度聚合数据生成相应的指标: 服务接口维度指标，QPS/P99/错误率
• 长期存储数据支持降准稀疏: 服务长期趋势指标，QPM/P99/服务拓扑关系
• 高频大批量写入，低频查询: 亿级TPS日志写入，分钟级别读取
• 多维度列式查询：不同维度的下钻，上卷，切面，切块，旋转
• 数据压缩比高：吃住原先由Elasticsearch/Prometheus每日生成TB级别的日志
• 丰富的函数库，丰富的数据类型: 统计函数/分位数/数组函数等
• 原生支持分布式集群，多副本，多分区，高效的索引，丰富的引擎: 查询秒级响应

先看一下数据库全景图，数据存储种类比较丰富，关系型数据库OLTP/OLAP，非关系型NoSQL。有支持列式存储，有支持时序性存储等等，针对不同的应用场景，精细划分。

经过调研我们的应用场景是一种典型的OLAP模式，随着调研的深入Clickhouse进入视野，它高效的性能让我们感到惊叹。

在单个节点的情况下，对一张拥有133个字段的数据表分别在1000万、1亿和10亿三种数据体量下执行基准测试，基准测试的范围涵盖43项SQL查询。在1亿数据集体量的情况下，ClickHouse的平均响应速度是Vertica的2.63倍、InfiniDB的17倍、MonetDB的27倍、Hive的126倍、MySQL的429倍以及Greenplum的10倍。不同类型的数据库对比参考附录，这里给一个CLickhouse与Mysql性能对比图。

最终基于功能、性能、成本考虑，我们选择了Clickhouse。

OLAP领域的黑马

Clickhouse是俄罗斯yandex公司于2016年开源的一个列式数据库管理系统，在OLAP领域像一匹黑马一样，以其超高的性能受到业界的青睐。

Clickhouse 为何这么优秀

• 完备的DBMS功能(Database Management System，数据库管理系统)

  支持DDL/DML/权限控制/备份恢复/分布式管理等等

• 列式存储与数据压缩

  同一列的数据往往有更高的共性，这意味着能有更高的压缩比。在Yandex.Metrica的生产环境中，数据总体的压缩比可以达到8:1（未压缩前17PB，压缩后2PB）。列式存储除了降低IO和存储的压力之外，还为向量化执行做好了铺垫。

• 向量化引擎与SIMD提高了CPU利用率，多核多节点并行化大查询

为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式（其他的还有指令级并行和线程级并行），它的原理是在CPU寄存器层面实现数据的并行操

• 多样化的表引擎

ClickHouse共拥有合并树、内存、文件、接口和其他6大类20多种表索引，根据不同的场景选择不同的引擎，而不是开发一种引擎适配多种场景。

• 多线程与分布式

由于SIMD不适合用于带有较多分支判断的场景，ClickHouse也大量使用了多线程技术以实现提速，以此和向量化执行形成互补。

• 多主架构

ClickHouse采用Multi-Master多主架构，集群中的每个节点角色对等，天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。

• 数据分片与分布式查询

数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段。ClickHouse提供了本地表（Local Table）与分布式表（Distributed Table）的概念。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。

不足：

• 不支持事务、异步删除与更新

• 不适用高并发场景

应用场景

ClickHouse 更适用于作为一个数据分析的数据库，它非常擅长针对于干净的，结构化的，不变的日志/事件数据进行分析。例如下述场景：

• ✓ 网页及APP分析(Web and App analytics)

• ✓ 广告网络以及广告投放(Advertising networks and RTB)

• ✓ 通信领域(Telecommunications)

• ✓ 在线电商以及金融(E-commerce and finance)

• ✓ 信息安全(Information security)

• ✓ 监控遥测(Monitoring and telemetry)

• ✓ 时序数据(Time series)

• ✓ 商业分析(Business intelligence)

• ✓ 网友(Online games)

• ✓ 物联网(Internet of Things)

如下场景一般不适用 ClickHouse

• ✕ 事务处理(Transactional workloads (OLTP))

• ✕ 高频次的K-V 请求(Key-value requests with a high rate)

• ✕ 文件块存储(Blob or document storage)

• ✕ 过度normalized 的数据(Over-normalized data)

Clickhouse在微服务治理中的具体实战

应用拓扑

实战心得

1、选择合适的引擎

Clickhouse有众多的数据库引擎，

• MergeTree是基础引擎，有主键索引、数据分区、数据副本、数据采样、删除和修改等功能，
• ReplacingMergeTree 有了去重功能，
• SummingMergeTree 有了汇总求和功能，
• AggregatingMergeTree 有聚合功能，
• CollapsingMergeTree 有折叠删除功能，
• VersionedCollapsingMergeTree 有版本折叠功能，
• GraphiteMergeTree 有压缩汇总功能。
• 在这些的基础上还可以叠加Replicated和Distributed。
• Integration系列用于集成外部的数据源，常用的有HADOOP，MySQL。

例如日志存储，目前Es也冗余了全量的日志，于是对Clickhouse存储异常有较高的容忍度。我们选取了Distributed + MergeTree模式，这里为了控制成本，采用多分片零副本的模式，当然为了高可用，最好还是要冗余多副本。

针对海量数据的存储，一种主流的做法就是实现Sharding方案。可以在客户端做Balance，也有数据库的中间件模式。Clickhouse Distributed表引擎就相当于Sharding方案中的中间件层，Distributed表不真实存储数据，对外提供插入和查询的路由功能。

2、表名的规范

为了适配常见的ORM模型，本地表一般采用"local_"开头如local_metrics，分布式表采用实际表如metrics。当然每个公司有自己的规范，主要还是为了方便区分和使用。

3、过期时间

由于存储的是日志类型，一般具有一定的时效性，我们设置表的TTL(Time To Live)时间，方便到期后数据自动删除。所以在建表的时候一般会带有Timestamp字段，一般我们是设置表级别TTL，当然Clickhouse还有支持更丰富的TTL类型，支持数据TTL，列TTL。

关于TTL小贴士：[注1]

1）TTL默认的合并频率由MergeTree的merge_with_ttl_timeout参数控制，默认86400秒，即1天。它维护的是一个专有的TTL任务队列。有别于MergeTree的常规合并任务，如果这个值被设置的过小，可能会带来性能损耗。
（2）除了被动触发TTL合并外，也可以使用optimize命令强制触发合并。例如，触发一个分区合并：
optimize TABLE table_name
触发所有分区合并：
optimize TABLE table_name FINAL
（3）ClickHouse目前虽然没有提供删除TTL声明的方法，但是提供了控制全局TTL合并任务的启停方法：
SYSTEM STOP/START TTL MERGES

4、分区

Clickhouse 数据分区和数据分片是两个不同的概念，数据分区是一种纵切，数据分片是一种横切。目前只有MergeTree类型的才支持分区策略。分区用PARTITION BY修饰。借助分区能提升查询性能，过滤掉不再分区的的数据。由于日志的时效性，大部分查询条件都会带上时间，所有按时间分区非常合适。但分区的粒度不能过度或者过小，当然没有区分度的字段也不能用来设置分区，一般按月或者按日来进行分区。关于分区的设置可以参考[注3]

分区的合并过程可查看下图： 

5、分片副本策略

Clickhouse分片分区策略配置在/etc/metrika.xml中，前面说了基于成本和容错性考虑，我们采用多分片0副本的策略。

<log_nshards_0replicas>
    <shard>
        <replica>
            <host>clickhouse1</host>
            <port>9000</port>
            <user>user</user>
            <password>password</password>
        </replica>
    </shard>
    <shard>
        <replica>
            <host>clickhouse2</host>
            <port>9000</port>
            <user>user</user>
            <password>password</password>
        </replica>
    </shard>
<log_nshards_0replicas>

由于日志类型没有很好的字段用于分片，这边采用rand()随机划分策略，尽量让分片数据均衡。另外Clickhouse集群配置有个分片权重设置，权重越大，分片写入数据越多，我们在新节点加入的时候会提高权重用于均衡数据。当然了这种靠手工的运维的模式不太适合频繁的节点上下线，如果有这方面的需求可以考虑引入数据均衡的中间件。更多关于分片的数据写入的细节可以参考[注2]。

6、索引

一级索引，PRIMARY KEY一般用于ORDER BY指定，由于我们存的大部分都是日志或指标类型，从而采用timestamp做一级索引。

稀疏索引，MergeTree每一行索引标记对应的是一段数据，仅需使用少量的索引标记就能够记录大量数据的区间位置信息，默认的索引粒度(8192)。由于稀疏索引占用空间小，所以primary.idx内的索引数据常驻内存，取用速度自然极快。

二级索引，除了一级索引之外，MergeTree同样支持二级索引。二级索引又称跳数索引。关于索引的更多细节可以参考附录[索引]

7、参数配置

• 最大并发查询数 max_concurrent_queries 原则上Clickhouse建议查询QPS小于100，但我们有按每分钟聚合查询的需求，这时候100就比较小了，调整max_concurrent_queries=500，需要注意的是，关注SQL的执行时间及机器负载设置合理值，避免高并发的查询影响Clickhouse性能。

• 压缩比 Clickhouse默认lz4压缩算法，MergeTree引擎压缩后和Elasticsearch对比，存储空间大约只有后者的1/10。更多关于压缩参考[ClickHouse数据的压缩和原理]。

• 多用户支持 默认Clickhouse安装后用户是default，空密码，需要做修改，避免安全问题。同时按不同的database设置不同的用户角色。同时注意密码加密方式，我们采用password_double_sha1_hex。另外我们为web可视化终端单独设置了用户，单独配置用户行为。[注4]

• 熔断机制 基于用户设置sql最大执行时间execution_time=5，类似pt-kill，超过阈值会终止查询。防止查询造成Clickhouse Server过载。还可设置result_rows/read_rows。为了避免内存耗尽造成异常，按需设置max_memory_usage。[注5]

<web>
    <interval>
        <duration>3600</duration>
        <queries>500</queries>
        <errors>100</errors>
        <result_rows>100</result_rows>
        <read_rows>2000</read_rows>
        <execution_time>5</execution_time>
    </interval>
</web>

<web_user>
    <password_double_sha1_hex>***</password_double_sha1_hex>
    <networks incl="networks" replace="replace">
        <ip>::/0</ip>
    </networks>
    <profile>default</profile>
    <quota>web</quota>  // 引用用户策略
    <access_management>1</access_management>
</web_user>

8、可视化

一般采用tabix。为了支持Prometheus，Elasticsearch，Clickhouse，我们选择Grafana，见：Clickhouse-Data-Source(https://grafana.com/grafana/plugins/grafana-clickhouse-datasource/?tab=installation)。

实战场景

全站可用性监控大盘

主要功能是实时查询，目前Clickhouse已对接好大夫在线绝大多数原始日志数据。包括入口流量日志KongLog，链路日志TracingLog，业务自定义日志LocalLog，组件及框架可用性日志如小程序日志、JS异常日志、页面性能日志等等。

表结构示例：

 CREATE TABLE {database}.{local_table} ON CLUSTER {cluster}
(
    `date` Date,
    `timestamp` DateTime,
    ...
)
ENGINE = MergeTree
PARTITION BY date
ORDER BY timestamp
TTL timestamp + toIntervalDay(30)
SETTINGS index_granularity = 8192

CREATE TABLE {database}.{table} ON CLUSTER {cluster} 
AS {database}.{local_table}
ENGINE = Distributed({cluster}, {database}, {table}, rand())

那么基于这些原始日志就能实时监控趋势了，产品形态如图

APM

主要用于分析服务的性能，我们存储了Tracing日志，依然是Distributed + MergeTree模式。

Tracing日志记录了服务的上下游服务及接口，上下游机器ip，RPC请求耗时，请求状态等。

这样我们就可以分析上下游细节了，如上下游QPM，依赖接口的延迟P99。

比如分析服务的上下游QPM，依赖接口的延迟p99，服务的网络延迟P99，接口的错误率等等。

这依赖Clickhouse丰富的函数，常用统计函数/分位数/中位数/数组函数等等，针对大量数据还可以基于采样查询SAMPLE BY。

如P99（由于延迟具有长尾效应，一般统计第99分位数据）。

SELECT
    (intDiv(toUInt32(timestamp), 1) * 1) * 1000 as t,
    quantile(0.99)(consume) as p99
FROM apm.trace_logs

WHERE
    timestamp >= toDateTime(1605147889)
    AND app_name = 'app'
GROUP BY
    t
ORDER BY t

APM常见的场景就是提供链路画像，需要按TraceID搜索，TraceID类似UUID字符串，不具备索引区分度。每次查询都会全表扫描，如何能快速查找TraceID对应的链路数据呢？

# 本地表存储tracing日志
 CREATE TABLE apm.local_trace_logs ON CLUSTER {cluster}
(
    `date` Date,
    `timestamp` DateTime,
    `trace_id` String, // uuid 随机32字符串
    ...
)
ENGINE = MergeTree
PARTITION BY date
ORDER BY timestamp
TTL timestamp + toIntervalDay(30)
SETTINGS index_granularity = 8192

# 分布式表Distributed
CREATE TABLE apm.trace_logs ON CLUSTER {cluster} 
AS apm.local_trace_logs
ENGINE = Distributed({cluster}, apm, trace_logs, rand())

# 提取入口trace_id数据即level=1，生成物化视图，这个视图的数据只有原表的10%的量级。
 CREATE MATERIALIZED VIEW apm.local_entrances
(
    `date` Date,
    `timestamp` DateTime,
    `trace_id` String,
    ...
)
ENGINE = MergeTree
PARTITION BY date
ORDER BY timestamp
TTL timestamp + toIntervalDay(6)
SETTINGS index_granularity = 8192 AS
SELECT
    date,
    timestamp,
    trace_id,
    ...
FROM apm.local_trace_logs
WHERE level = '1'

# Distributed 暴露给外查询的引擎
CREATE TABLE apm.entrances ON CLUSTER {cluster} 
AS apm.local_entrances
ENGINE = Distributed({cluster}, apm, entrances, rand())

统计发现这样提取后物化视图的数据只有原表的10%了，在查询的时候，我们先从entrances表中查询给定的{trace_id}的数据，拿到{timestamp}、{date}后。再将{trace_id}、{timestamp±5min}、{date}带去trace_logs表中查询，因为trace_logs按date分区，并且有timestamp索引，这样就不用全部扫描了，只用查询timestamp between {timestamp-5min} and {timestamp+5min} and date = {date}的数据即可。

当然如果后续trace_logs数据再翻翻，我们还有优化的空间。根据前缀索引模型，我们截取trace_id前n位记作sub_id,然后根据sub_id做索引，根据数据量的大小调整n的值，这样我们能将单次查询数据控制在一定的范围内。

如果数据量过大，还可以根据特征字段配置采样策略。

产品形态：

运行时

拓扑分析 

链路分析 

告警指标分析

好大夫早期的监控告警是依托于Elasticsearch，数据可视化也是基于Elasticsearch。随着告警项的增加，并发查询增加，导致Elasticsearch负载过高，无法正常提供服务，同时Elasticsearch写入面临磁盘I/O瓶颈。为了监控的高可用及时效性，我们全面迁移到Clickhouse。

目前大约每分钟有2000+SQL并发执行，5s内能分析完毕，分析后的数据按分钟聚合后存储到Clickhouse中。

这里采用了GraphiteMergeTree引擎，同理由于是临时存储，依然采用多分片零副本的分片策略。GraphiteMergeTree类似于Graphite数据库，是一个图表数据库，这里我们参考Prometheus时序数据库的思想，将原始数据按不同的维护聚合分析后转换成key-value的数据类型。其中name为指标名，tags为指标的多维度标签，是一个数组类型，date用于分区，ts指标插入时间，val是指标的具体值是Float64格式，update用于降准稀疏。

Prometheus就可以通过exporter拉取这些分析后的指标，经过判定触发告警。

如app的QPM可以表示为：

date:    2021-11-25
name:    app_request_qpm
tags:    ['app_name=demo','ttl=forever']
val:     336608
ts:      2021-11-26 23:00:00
updated: 2021-11-26 23:00:22

查询最近5min demo的访问量：

SELECT sum(val) as total
FROM metrics
WHERE (name = 'app_request_qpm') 
AND has(tags, 'app_name=demo')
AND date=today() and ts>now()-300

表结构：

# 本地表用于存储指标
CREATE TABLE apm.local_metrics ON CLUSTER {CLUSTER}
(
    `date` Date DEFAULT toDate(0),
    `name` String,
    `tags` Array(String),
    `val` Float64,
    `ts` DateTime,
    `updated` DateTime DEFAULT now()
)
ENGINE = GraphiteMergeTree('graphite_metric')
PARTITION BY date
ORDER BY (name, tags, ts)
TTL ts + toIntervalDay(30)

# 分布式表
CREATE TABLE apm.metrics ON CLUSTER {CLUSTER}
AS apm.local_metrics
ENGINE = Distributed('{CLUSTER}', 'apm', 'local_metrics', rand())

特征数据归档

前面看到我们存储了大量的原始日志数据，也看到物化视图的威力，那还有哪些场景能使用这把利器。目前提供给业务方的自定义的日志LocalLog，常用event和app_name来标识不同的类型。LocalLog记录了全服务的日志，数据量级非常大，为了更好地检索数据，避免查询大表LocalLog，我们把常用的event剥离出来，单独生成物化视图，从而提升查询性能。

比如为配合Tracing日志，我们在框架中集成了调用中间件的日志，复用了LocalLog，记录微服务调用中间件的详情，如mysql sql详情，RabbitMQ发布、消费记录等。这时我们就可以基于event事件分离出中间件日志单独生成视图。这类场景还有很多，比如分离出客户端慢交互数据，特定埋点的用户行为日志等。

 CREATE MATERIALIZED VIEW apm.local_middleware_logs
(
    `date` Date,
    `timestamp` DateTime,
    `trace_id` String,
    `event` String,
    ...
)
ENGINE = MergeTree
PARTITION BY date
ORDER BY timestamp
TTL timestamp + toIntervalDay(6)
SETTINGS index_granularity = 8192 AS
SELECT
    date,
    timestamp,
    trace_id,
    event,
    ...
FROM apm.local_biz_logs
WHERE event in ('mysql','rabbitmq'...)

CREATE TABLE apm.middleware_logs ON CLUSTER {cluster} 
AS apm.local_middleware_logs
ENGINE = Distributed({cluster}, apm, middleware_logs, rand())

前面我们存储了基于原始日志分析后等到聚合指标metrics，有些数据需要长期存储，比如存储一个Q，一年等。如微服务的QPM，P99需要永久存储，方便从长期时间维度查看趋势，从而评估服务整体健康度演化趋势。我们可以对感兴趣的metrics打上tags TTL="forever"。这样我们设置local_view_metrics的引擎策略GraphiteMergeTree roll_up上卷模式，graphite_metric_view。按不同的策略对同名指标包含相同tags的数据进行降准稀疏，<=7d内存储原始指标，7d~30d按小时进行上卷，>30d按天进行上卷，上卷的策略有sum/avg/min/max等。

# 物化视图 提取特定tags的指标
CREATE MATERIALIZED VIEW apm.local_view_metrics ON CLUSTER {CLUSTER}
(
    `date` Date DEFAULT toDate(0),
    `name` String,
    `tags` Array(String),
    `val` Float64,
    `ts` DateTime,
    `updated` DateTime DEFAULT now()
)
ENGINE = GraphiteMergeTree('graphite_metric_view')
PARTITION BY date
ORDER BY (name, tags, ts)
SETTINGS index_granularity = 8192 AS
SELECT
    date,
    name,
    tags,
    val,
    ts,
    updated
FROM apm.local_metrics
WHERE has(tags, 'ttl=forever') = 1

CREATE TABLE apm.view_metrics ON CLUSTER {CLUSTER}
AS apm.local_view_metrics
ENGINE = Distributed('{cluster}', 'apm', 'local_view_metrics', rand())

# graphite_metric_view 配置策略
    <graphite_metric_view>
        <path_column_name>tags</path_column_name>
        <time_column_name>ts</time_column_name>
        <value_column_name>val</value_column_name>
        <version_column_name>updated</version_column_name>
        <default>
            <function>avg</function>
            <retention>
                <age>0</age>
                <precision>30</precision>
            </retention>
            <retention>
                <age>604800</age>
                <precision>3600</precision>
            </retention>
            <retention>
                <age>2592000</age>
                <precision>86400</precision>
            </retention>
        </default>
        <pattern>
            <regexp>rollup_sum</regexp>
            <function>sum</function>
            <retention>
                <age>0</age>
                <precision>30</precision>
            </retention>
            <retention>
                <age>604800</age>
                <precision>3600</precision>
            </retention>
            <retention>
                <age>2592000</age>
                <precision>86400</precision>
            </retention>
        </pattern>
        ...
    </graphite_metric_view>

Prometheus远程存储

随着监控体系向云原生靠拢，我们整体也是采用了Prometheus。但是Prometheus官方并没有提供长期数据持久化的方案，但有些业务指标需要长期存储。我们采用本地存储15d+远程存储的模式。远程存储采用CLickhouse，这也是经过对比后选定的，业内也有选择InfluxDB，但社区版的InfluxDB不支持集群模式，加上引入新的DB产生的运维成本，最终还是选择了Clickhouse，毕竟有一定的经验积累了。

我们自研了Prometheus2CLickhouse_adapter，将数据从Prometheus同步到CLickhouse。有兴趣的同学可以查看源码，目前已经开源到GitHub: remote_storage_adapter。

业务尝试

目前已有业务方对接了Clickhouse，主要场景是多方向聚合数据，然后按不同的维度检索数据（多维度的统计数据实时查询）。一开始也考虑直接用熟悉的MySQL/MongoDB，但都有性能瓶颈问题，千万级数据查询会到大于10s，无法满足业务需求，改用Clickhouse后查询在200ms内。由于业务数据需要高可用，数据不可丢失，这里采用了三分片一副本的策略，准备了6个节点，ck1~6。类似于RedisCluster模式，实现两两备份。

另外为了提升写入性能，我们设置了异步同步模式internal_replication=true，Distributed表在该shard中只会选择一个合适的replica，并写入数据，多replica副本间的数据复制则交给本地表引擎如ReplicatedMergeTree。

集群配置：

# 分片副本
<nshards_1replicas>
    <shard>
        <internal_replication>true</internal_replication>
        <replica>
            <host>clickhouse1</host>
            <port>9000</port>
            <user>user</user>
            <password>password</password>
        </replica>
        <replica>
            <host>clickhouse4</host>
            <port>9000</port>
            <user>user</user>
            <password>password</password>
        </replica>
    </shard>
    ...
<nshards_1replicas>

# 变量用于建表时的占位符，策略将存在zookeeper中.
<macros>
    <layer>02</layer>
    <shard>01</shard>
    <replica>ck2-01-01</replica>
</macros>

表结构：

CREATE TABLE default.local_tests ON CLUSTER nshards_1replicas
(
    `id` Int64,
    `diseaseid` Int64,
    `ctime` DateTime,
    ...
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/local_tests', '{replica}')
PARTITION BY toYYYYMMDD(ctime)
ORDER BY (ctime, diseaseid)
TTL ctime + toIntervalDay(7)
SETTINGS index_granularity = 8192


CREATE TABLE default.tests ON CLUSTER nshards_1replicas 
AS {database}.local_tests
ENGINE = Distributed(nshards_1replicas, default, tests, rand())

上线之后业务反馈还不错，数据查询反馈很及时。

展  望

1. Clickhouse管理平台的演进 由于Clickhouse迭代升级非常频繁，每个月会更新一版，但是部署运维偏向手动。故障转移，参数配置等运维成本较高。做好权限控制，将集群下发给业务方使用。为了高可用及稳定性，后续会向PaaS平台演进。

2. 拓宽Clickhouse使用场景，对接更多的业务方需求。

3. 减少Clickhouse黑盒模式，要知其然知其所以然，加深对Clickhouse的深入研究。

4. 提升CLickhouse中间件的稳定性，借助混沌工程思想，做好周期性故障演练。

小  结

在大数据时代，人人都是数据分析师，OLAP也一直在进化，适应着时代的发展。当下微服务治理产生的数据也越来越大，为了辅助研发同学更好的治理线上服务，OLAP数据库将发挥着越来越重要的作用。尤其是实时查询，不同的人关注的不同的维度，通过上卷，下钻及时定位异常问题。本篇我们一起探讨了Clickhouse在好大夫微服务治理中发挥的作用，后续我们还将分享更多的应用场景，期待大家共同讨论。最后推荐一本书：《ClickHouse原理解析与应用实践》https://book.douban.com/subject/35091211/。

参考资料：

1. clickhouse vs elasticsearch benchmark：https://www.alibabacloud.com/blog/clickhouse-vs--elasticsearch_597898；
2. clickhouse vs mysql benchmark：http://mmedojevic.com/2020/03/09/clickhouse-vs-mysql/；
3. Performance comparison of analytical DBMS：https://clickhouse.yandex/benchmark.html；
4. ClickHouse数据的压缩和原理：https://blog.csdn.net/weixin_43975771/article/details/115861032；
5. “索引” 朱凯著.ClickHouse原理解析与应用实践.机械工业出版社华章分社.2020:215.
6. [注1] “TTL” 朱凯著.ClickHouse原理解析与应用实践.机械工业出版社华章分社.2020:255.
7. [注2] “分片写入核心流程” 朱凯著.ClickHouse原理解析与应用实践.机械工业出版社华章分社.2020:473.
8. [注3] “数据的分区规则朱凯著.ClickHouse原理解析与应用实践.机械工业出版社华章分社.2020:208.
9. [注4] 用户配置：https://clickhouse.com/docs/en/operations/settings/settings-users/

10. [注5] 配额：https://clickhouse.com/docs/en/operations/quotas/

作者简介：

方勇：好大夫基础架构部高级工程师，专注于 SRE，微服务、中间件的稳定性和可用性建设，整体负责好大夫服务治理云平台的设计和搭建。

你也「在看」吗？👇