Dash0 如何用 ClickHouse 构建可观测性解决方案

本文字数：14190；估计阅读时间：36 分钟

作者：Miel Donkers

• 跨信号关联：工程师可以从指标出发，深入查看相关的追踪信息，并在同一工作流程中排查关联的日志。
• 服务健康监控：平台保留了 OpenTelemetry 的语义约定，可自动生成有意义的仪表板，并创建具备可操作性的告警。
• 简化故障排查：通过维护各类信号之间的关联，Dash0 显著缩短了事故的平均恢复时间（MTTR）。

• 能够处理并存储所有类型的信号：指标（Metrics）、日志（Logs）和追踪（Spans）
• 能够通过资源属性（Resource attributes）或字段（如 TraceId 和 SpanId）在不同信号之间建立引用关系，例如通过日志中的 TraceId 关联到对应的追踪
• 支持高基数数据结构，因为属性既存在于资源层，也存在于信号层

• 本地磁盘保留近 1-2 天的热数据
• 历史数据归档到 AWS S3
• 使用本地磁盘作为查询缓存

<clickhouse>
   <storage_configuration>
       <disks>
           <default>
               <keep_free_space_bytes>536870912</keep_free_space_bytes>
           </default>
           <disk_s3>
               <data_cache_enabled>true</data_cache_enabled>
               <endpoint>...s3 endpoint...</endpoint>
               <type>s3</type>
           </disk_s3>
           <disk_s3_cache>
               <disk>disk_s3</disk>
               <path>/mnt/cache-disk/</path>
               <type>cache</type>
           </disk_s3_cache>
       </disks>
       <policies>
           <s3tiered>
               <move_factor>0.100000</move_factor>
               <volumes>
                   <n_1_hot>
                       <disk>default</disk>
                   </n_1_hot>
                   <n_2_cold>
                       <disk>disk_s3_cache</disk>
                   </n_2_cold>
               </volumes>
           </s3tiered>
       </policies>
   </storage_configuration>
</clickhouse>

TTL toDateTime(Timestamp) + INTERVAL 25 HOUR TO VOLUME 'n_2_cold',
   toDateTime(Timestamp) + INTERVAL 13 MONTH DELETE

• 提升查询效率
• 优化数据压缩率

1. 指标名称（MetricName）、描述（MetricDescription）和单位（MetricUnit）等元数据通常在多个数据点之间保持一致。如果在每条记录中都重复保存这些内容，会导致数据重复度极高，浪费大量存储空间。即便是每个数据点携带的属性值，也往往是类似的，比如 http.response.status_code 这个属性通常取值为 200 或 500。对于这种情况，是可以进行去重优化的。
2. 将属性存储为 Map 类型字段，在查询时效率较低，同时作为主键的组成部分也表现不佳。
3. 如果用户想查询某个指标，但并不确定其具体类型（如 sum、gauge 或 histogram 等），就需要在五张不同的表中分别查找，操作成本较高。

CREATE TABLE IF NOT EXISTS otel.otel_metrics_gauge
(
 `MetricHash` UInt64 Codec(LZ4),
 `StartTimeUnix` DateTime64(9) CODEC(Delta, LZ4),
 `TimeUnix` DateTime64(9) CODEC(Delta, LZ4),
 `Value` Float64 CODEC(LZ4),
)
ENGINE MergeTree
PARTITION BY toDate(TimeUnix)
ORDER BY (MetricHash, TimeUnix)

CREATE TABLE IF NOT EXISTS otel.otel_metrics_metadata
(
 `TimeUnix` Date CODEC(Delta, LZ4),
 `MetricName` LowCardinality(String) CODEC(LZ4),
 `MetricHash` UInt64 CODEC(LZ4),
 `FirstSeen` SimpleAggregateFunction(min, DateTime64(9)) CODEC(T64, LZ4),
 `LastSeen` SimpleAggregateFunction(max, DateTime64(9)) CODEC(T64, LZ4),
 `ResourceAttributes` SimpleAggregateFunction(anyLast, Map(String, String)) CODEC(LZ4),
 `ResourceSchemaUrl` SimpleAggregateFunction(anyLast, String) CODEC(LZ4),
 `ScopeName` SimpleAggregateFunction(anyLast, String) CODEC(LZ4),
 `ScopeVersion` SimpleAggregateFunction(anyLast, String) CODEC(LZ4),
 `ScopeAttributes` SimpleAggregateFunction(anyLast, Map(String, String)) CODEC(LZ4),
 `ScopeDroppedAttrCount` SimpleAggregateFunction(anyLast, UInt32) CODEC(LZ4),
 `ScopeSchemaUrl` SimpleAggregateFunction(anyLast, String) CODEC(LZ4),
 `MetricDescription` SimpleAggregateFunction(anyLast, String) CODEC(LZ4),
 `MetricUnit` SimpleAggregateFunction(anyLast, String) CODEC(LZ4),
 `MetricAttributes` SimpleAggregateFunction(anyLast, Map(String, String)) CODEC(LZ4),
 `MetricType` SimpleAggregateFunction(anyLast, Enum8('MetricTypeEmpty' = 0, 'MetricTypeGauge' = 1, 'MetricTypeSum' = 2, 'MetricTypeHistogram' = 3, 'MetricTypeExponentialHistogram' = 4, 'MetricTypeSummary' = 5)) CODEC(LZ4),
 `SumAggTemp` SimpleAggregateFunction(anyLast, Enum8('AggregationTemporalityUnspecified' = 0, 'AggregationTemporalityDelta' = 1, 'AggregationTemporalityCumulative' = 2)) CODEC(LZ4),
 `SumIsMonotonic` SimpleAggregateFunction(anyLast, Boolean) CODEC(LZ4),
)
ENGINE = AggregatingMergeTree() PARTITION BY toYYYYMM(TimeUnix)
ORDER BY (TimeUnix, MetricName, MetricHash)

• 对不同排序方式进行全面基准测试，确保不会对现有性能产生负面影响；
• 使用 EXPLAIN indexes=1  命令分析不同排序键和索引组合对查询路径的影响；

• traces2：toStartOfHour(Timestamp), ResourceHash, xxh3(SpanId)
• traces3：ResourceHash, SpanName, xxh3(SpanId)
• traces4：ResourceHash, toStartOfHour(Timestamp), xxh3(SpanId)
• traces5：xxh3(SpanId) % 256, ResourceHash, Timestamp

• 新表结构下的压缩效果是否合理，避免大幅增加存储开销；
• 普通查询的响应时间是否保持稳定；
• 启用采样后查询是否加速明显；
• 主索引与次级索引是否生效，输出结果是否一致；

WITH subtractHours(toDateTime('${QUERY_TS}'), ${QUERY_DURATION} + 1) AS startTime, subtractHours(toDateTime('${QUERY_TS}'), 1) AS endTime
SELECT
    ResourceHash,
    Timestamp,
    SpanAttributes,
    SpanName
FROM ${QUERY_TABLE} ${QUERY_SAMPLE}
WHERE (Timestamp >= startTime) AND (Timestamp <= endTime) AND (ParentSpanId = '')
ORDER BY
    Timestamp ASC
LIMIT 50
FORMAT Null
SETTINGS use_query_cache=false;

#!/usr/bin/env bash
TIMESTAMP=$(date +%Y-%m-%d-%H-%M)
RESULTS_FOLDER="results"
mkdir -p ${RESULTS_FOLDER}
# Some fields replaced in the scripts
QUERY_TS=$(date --utc +'%F %H:%M:%S')
for DURATION in "1" "12" "24" "72"; do
  for FILE in *.sql; do
	for TABLE in traces traces2 "traces2 SAMPLE 0.01"; do
	  OUTPUT_FILENAME="${FILE#queries/}"
	  OUTPUT_FILENAME="${OUTPUT_FILENAME%.sql}"
	  OUTPUT_FILENAME="${RESULTS_FOLDER}/${TIMESTAMP}-${OUTPUT_FILENAME}-${DURATION}h-${TABLE}.txt"
	  echo "##################################################"
	  echo "Running benchmark for ${FILE} and table ${TABLE}"
	  # Need to export the template variables otherwise not available in the subshell
	  export QUERY_TABLE=${TABLE%%SAMPLE*}
	  export QUERY_SAMPLE=${TABLE#$QUERY_TABLE}
	  export QUERY_DURATION=${DURATION}
	  export QUERY_TS
	  QUERY=$(envsubst < ${FILE})
	  # Print the query also to the OUT_FILE to have it for reference
	  echo -e "Query:\n\n${QUERY}\n\n" | tee "${OUTPUT_FILENAME}"
	  # Remove all linebreaks from the query, but add one at the end for ClickHouse
	  echo "${QUERY}" | tr '\n' ' ' | xargs -0 printf '%s\n' | clickhouse-benchmark --cumulative --user otel --password otel  --host localhost --port 9000 -i 10 2>&1 | tee --append "${OUTPUT_FILENAME}"
	  sleep 5
	done
  done
done

• “traces2”、“traces3” 和 “traces4” 三张表的压缩率差别不大，但都不如原始表
• “traces5” 表（排序键为 xxh3(SpanId) % 256, ResourceHash, Timestamp）在采样查询中速度最快，因为它可以高效跳过大量数据块；但在执行普通查询时性能最差
• “traces4” 表略优于 “traces2” 和 “traces3”，但差距不大
• 对于时间范围小于 12～24 小时的查询，采样效果提升并不明显

INDEX idx_attr_key mapKeys(Attributes) TYPE bloom_filter(0.01) GRANULARITY 1

• has(Attributes, 'some_key') 可以正确利用 Bloom Filter
• Attributes['some_key'] = ''（空字符串）则无法使用该索引。因为一个有意设置为空的值与某个 key 不存在在语义上是相同的，这种情况无法区分，因此 Bloom Filter 无法用于后者。

EXPLAIN indexes = 1
SELECT Attributes['error']
FROM logs
WHERE (toDateTime(Timestamp) >= subtractMinutes(now(), 10)) AND (NOT ((Attributes['error']) = ''))


Query id: 6b792380-5937-4cb7-9617-c846a4543895


┌─explain──────────────────────────────────────────────────────────────────────┐
│ Expression ((Project names + Projection))                                    │
│   Expression                                                                 │
│     ReadFromMergeTree (logs)                                                 │
│       PrimaryKey                                                             │
│         Keys:                                                                │
│           Timestamp                                                          │
│         Condition: and((toDateTime(Timestamp) in [1741693620, +Inf)))        │
│         Parts: 11/11                                                         │
│         Granules: 3030/6868                                                  │
│       Skip                                                                   │
│         Name: idx_timestamp                                                  │
│         Description: minmax GRANULARITY 1                                    │
│         Parts: 9/11                                                          │
│         Granules: 1715/3030                                                  │
└──────────────────────────────────────────────────────────────────────────────┘

EXPLAIN indexes = 1
SELECT Attributes['error']
FROM logs
WHERE (toDateTime(Timestamp) >= subtractMinutes(now(), 10)) 
  AND (NOT ((Attributes['error']) = '')) 
  AND has(Attributes, 'error')


Query id: a5a6181f-9359-49d7-ab78-921e1cc64c86


┌─explain──────────────────────────────────────────────────────────────────────┐
│ Expression ((Project names + Projection))                                    │
│   Expression                                                                 │
│     ReadFromMergeTree (logs)                                                 │
│       PrimaryKey                                                             │
│         Keys:                                                                │
│           Timestamp                                                          │
│         Condition: and((toDateTime(Timestamp) in [1741693620, +Inf)))        │
│         Parts: 11/11                                                         │
│         Granules: 3030/6868                                                  │
│       Skip                                                                   │
│         Name: idx_timestamp                                                  │
│         Description: minmax GRANULARITY 1                                    │
│         Parts: 9/11                                                          │
│         Granules: 1715/3030                                                  │
│       Skip                                                                   │
│         Name: idx_attr_key                                                   │
│         Description: bloom_filter GRANULARITY 1                              │
│         Parts: 8/9                                                           │
│         Granules: 279/1715                                                   │
└──────────────────────────────────────────────────────────────────────────────

• 选择合适的 JOIN 类型：如果左表中的某个值在右表中能匹配多条记录，JOIN 操作会返回多行结果，也就是所谓的“笛卡尔积”。如果你的业务场景只需要匹配一条任意结果，可以使用 ANY JOIN（例如 LEFT ANY JOIN），相比标准 JOIN，它更高效、内存占用也更低。你可以参考 ClickHouse 的官方文档和技术博客，选择最适合的 JOIN 类型。
• 控制 JOIN 表的数据量：JOIN 操作的执行性能与参与表的大小直接相关。为了减少处理数据量，可以在 WHERE 或 JOIN ON 子句中加入更多过滤条件。ClickHouse 的查询优化器通常会尽可能将过滤条件下推至 JOIN 之前执行。如果未能自动下推（可使用 EXPLAIN 检查），可以将其中一侧改写为子查询，强制优化器进行下推处理。此外，直接在 JOIN ON 中加入时间或业务字段的条件（例如：ON a.ServiceName = b.ServiceName AND b.Timestamp BETWEEN startTime AND endTime）也有助于降低 JOIN 的数据扫描量。
• 外连接时使用默认值替代 NULL：在执行外连接（如 LEFT JOIN、RIGHT JOIN 或 FULL OUTER JOIN）时，如果某一侧未能找到匹配项，ClickHouse 默认会用特殊标记替代，遵循 SQL 标准为 NULL。但在 ClickHouse 中，这要求使用 Nullable 类型字段，带来额外的内存开销和性能损失。为提升效率，你可以设置参数 join_use_nulls = 0，让系统使用字段默认值作为未匹配占位标志，避免引入 Nullable 类型。