ClickHouse Cloud 外部 API 重磅发布，解锁更多可能！
ClickStack Team约 14 分钟本文字数：9609；估计阅读时间：25 分钟
作者：ClickStack Team
欢迎阅读 ClickStack 二月最新动态。
每月，我们都会分享 ClickStack 的最新进展，涵盖从平台增强到旨在提升可观测性（observability）的速度、简易性和强大功能的新特性。二月，ClickStack 在云和开源版本均迎来了重大改进，包括全新的查询工作流、增强的指标探索功能、性能优化以及扩展的告警选项。
在此衷心感谢所有的开源贡献者，以及广大用户，正是他们的宝贵反馈塑造了这些功能，让 ClickStack 能够更好地服务于每一个人。
一如既往，我们衷心感谢所有的开源贡献者，尤其是本月首次参与贡献，共同提升 ClickStack 体验的新成员。
AdityaPimpalkar Rajin9601 mlsalcedo themavik Misfits09 Bre77 alex-clickhouse adri mxmCherry
如果您不擅长代码贡献，我们同样欢迎文档改进、新想法、功能建议、错误报告以及一般性反馈。每一份贡献，无论大小，都有助于共同提升整个社区的 ClickStack 体验。
对于许多团队而言，配置即代码（configuration as code）是其硬性需求。ClickStack API 已在开源版本中推出一段时间，并迅速成为需要大规模管理仪表板（dashboards）和告警（alerts）的企业不可或缺的功能。本月，我们很高兴能将这一能力引入 ClickHouse Cloud。
借助 ClickStack 资源在 ClickHouse Cloud OpenAPI 中的可用性，您现在可以直接通过 Cloud API 管理仪表板、告警、数据源（sources）和 Webhook。这意味着可观测性配置可以与您的应用程序代码共存，无缝融入 CI/CD（Continuous Integration/Continuous Delivery）流程，并确保在开发、预发布和生产环境之间保持高度一致。
例如，列出某个服务的所有仪表板现在变得非常简单，只需执行：
curl -X GET \
'https://api.clickhouse.cloud/v1/organizations/{organizationId}/services/{serviceId}/clickstack/dashboards' \
--user '<keyId>:<keySecret>' \
-H 'Content-Type: application/json'
无需额外的独立凭证。您现有的、具备相应权限的 ClickHouse Cloud API 密钥即可直接使用。
这是 ClickStack 实现全自动化、生产环境下可观测性工作流程的第一步。我们将继续扩大资源覆盖范围，并计划支持 Terraform。有关完整详细信息和示例，请参阅专门公告和API 参考。
本月，我们让 ClickStack 的上手变得空前简单。借助 ClickHouse 26.2 版本，ClickStack 的用户界面 (UI) 直接集成在 ClickHouse 的二进制文件中。只需下载 ClickHouse 或启动一个 Docker 容器，打开 http://localhost:8123/clickstack，即可开始探索。
该内嵌版本专为本地开发、学习和实验而设计。它提供了一种简单的方式来可视化您的可观测性数据，甚至可以使用其内部日志和系统表来分析 ClickHouse 本身。
尽管该版本不适用于生产部署，但它提供了一种有效途径，让您能够通过 ClickHouse 自带的内置 UI，理解查询性能、诊断本地问题，并探索实例的运行行为。
如果您对我们如何在仅增加约 4.1 MB 的前提下，将 UI 直接打包到 ClickHouse 的二进制文件中，同时又干净地集成到 ClickHouse 构建系统中的技术细节感到好奇，我们建议您阅读完整的公告博客文章（https://clickhouse.com/blog/clickstack-embedded-clickhouse）。
我们收到的最普遍反馈之一很简单：“我只想编写 SQL 并用它来绘制图表。”
自 ClickStack 诞生之初，我们就一直致力于简化可视化图表的构建。折线图和条形图构建器、数字方块、饼图（见下文）、搜索视图、Markdown 和引导式工作流程等功能，都旨在帮助用户无需编写 SQL 即可创建功能强大的仪表板。然而，任何向导式功能都有其局限性。虽然简化能让常见任务处理得更快，但它也可能隐藏一些底层能力。
由于 ClickStack 由 ClickHouse 提供支持，它基于功能全面且符合 SQL 标准的引擎构建，该引擎拥有一套丰富的分析和聚合函数。这种灵活性是其最大的优势之一。未来几个月，我们将开始在不同可视化类型中开放原生 SQL 支持，让用户能够选择：使用构建器以求便捷，或使用原始 SQL 以获得完全控制权。
我们从表开始。在表格视图中，用户现在可以在默认的 Builder 模式和新的 SQL 模式之间切换。在此模式下，您可以直接编写原生 SQL 查询，包括引用内置的时间范围参数（用于起始和结束时间戳）。
当图表添加到仪表盘时，时间变量会自动注入，因此您的查询将保持动态并与所选时间窗口保持一致。
这开启了远超仅仅编写比表格构建器允许的更长或更复杂查询的可能性。构建器在设计上存在特定倾向。对于表而言，它侧重于按列分组，并在其余字段中计算指标。这对于常见工作流非常适用，但无法表达更高级的分析模式。
利用原始 SQL，用户现在可以跨数据集连接、关联信号，并计算横跨多个表的派生指标。例如，您可以将日志（logs）与跟踪（traces）进行连接，以便在单个结果集中比较总日志量、错误计数和平均延迟。
WITH
Traces AS (
SELECT
ServiceName,
avg(Duration) AS avg_duration,
quantile(0.99)(Duration) AS p99_duration
FROM otel_v2.otel_traces
WHERE
Timestamp >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
AND Timestamp < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
GROUP BY ServiceName
),
Errors AS (
SELECT
ServiceName,
countIf(SeverityText = 'error') AS error_log_count
FROM otel_v2.otel_logs
WHERE
TimestampTime >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
AND TimestampTime <= fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
AND SeverityText = 'error'
GROUP BY ServiceName
)
SELECT
coalesce(Traces.ServiceName, Errors.ServiceName) AS ServiceName,
avg_duration,
p99_duration,
error_log_count
FROM Traces
FULL OUTER JOIN Errors
ON Traces.ServiceName = Errors.ServiceName
ORDER BY ServiceName
LIMIT 200;
在原始 SQL 模式下，用户只需选择一个连接。与 Query Builder 不同，无需指定数据源，用户可以自由地一次性查询多个数据源。
或者考虑一个轻量级的服务映射（service map）风格视图。对 spans 进行自连接（self JOIN）可以显示服务对之间的请求计数、总错误数和错误率百分比（也可在我们的服务映射功能中直观地查看）。这种关系分析在可视化构建器中很难连贯地建模，但在 SQL 中却简单明了：
WITH
ServerSpans AS (
SELECT TraceId AS traceId,
SpanId AS spanId,
ServiceName AS serviceName,
ParentSpanId AS parentSpanId,
StatusCode AS statusCode
FROM otel_v2.otel_traces
WHERE SpanKind IN ('Server', 'Consumer', 'SPAN_KIND_SERVER', 'SPAN_KIND_CONSUMER') AND
Timestamp >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
AND Timestamp < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
),
ClientSpans AS (
SELECT TraceId AS traceId,
SpanId AS spanId,
ServiceName AS serviceName,
ParentSpanId AS parentSpanId,
StatusCode AS statusCode
FROM otel_v2.otel_traces
WHERE SpanKind IN ('Client', 'Producer', 'SPAN_KIND_CLIENT', 'SPAN_KIND_PRODUCER') AND
Timestamp >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
AND Timestamp <= fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
)
SELECT
ServerSpans.serviceName AS serverServiceName,
ClientSpans.serviceName AS clientServiceName,
count(*) * 10 AS requestCount,
countIf(ServerSpans.statusCode = 'Error') AS error_count,
round(error_count / requestCount, 3) AS \`% error count\`
FROM ServerSpans
LEFT JOIN ClientSpans
ON ServerSpans.traceId = ClientSpans.traceId
AND ServerSpans.parentSpanId = ClientSpans.spanId
WHERE ClientSpans.serviceName IS NULL
OR ServerSpans.serviceName != ClientSpans.serviceName
GROUP BY serverServiceName, clientServiceName
ORDER BY serverServiceName, clientServiceName;
这是将引导式构建器的简洁性与 SQL 的全面表达能力相结合的第一步，让高级用户能够自由发挥 ClickHouse 的全部潜力。在接下来的几个月里，请继续关注 SQL 在其他可视化中的支持情况。
ClickStack 长期以来一直支持 OpenTelemetry metrics（概念上类似于 Prometheus），并按照数据类型（例如 gauge 和 counter）将其存储为独立的表。尽管这种模型灵活且强大，但要了解如何使用 metrics 及其关联的 labels，通常需要进行大量试错。
在此版本中，我们使指标发现（metric discovery）过程更加直观。用户通常清楚自己想要绘制哪个 metric，并能像以前一样通过自动完成功能进行选择。现在，一旦选择了某个 metric，他们就可以展开一个关联的 attributes panel，该面板会显示该特定 metric 的所有可用 labels。用户无需再猜测存在哪些 labels，而是可以立即查看并选择它们。
在上例中，我们首先绘制了 k8s.pod.memory.working_set (Gauge) metric 的平均值图表。系统会立即提示我们，该 metric 拥有 44 个关联 attributes。我们展开 attributes panel 并选择 k8s.deployment.name label。随后，该 label 既可以作为过滤器应用于图表，以缩小展示范围；也可以添加为一个分组项，以根据 Kubernetes deployment 对 metric 进行细分。在此示例中，我们按 deployment 进行分组，以比较不同服务间的工作集大小。
这种简化的流程大大减少了指标探索中的猜测成分。用户无需再手动尝试去发现哪些 labels 可用于分组或过滤。OpenTelemetry metrics 的图表绘制过程变得更加直接、可视化，侧重于获取洞察，而非 label 查找。
我们收到的最频繁的请求之一，是希望提供更丰富的可视化图表类型。增强图表功能一直是我们待办事项清单中的重要一项，在接下来的几个月里，我们将继续填补这些空白，并优先支持用户需求最迫切的可视化类型。
饼图是 分析领域最具争议的图表类型之一，然而它们在可观测性（Observability）领域仍然是一种受欢迎的选择。虽然它们并非适用于所有场景，但仍能有效展示比例构成，例如 status codes、error categories，或是跨服务请求分布等。
饼图现已在 ClickStack 最新版本中推出。要创建饼图，用户只需选择一个指标来定义扇区大小，然后选择一个分组字段来确定扇区如何划分。该字段的不同值将分别对应图表中的一个扇区。与其他可视化功能类似，在渲染前可应用过滤器以缩小数据集范围。
饼图支持跟踪（traces）、日志（logs）和 OpenTelemetry 指标，并得益于今年早些时候引入的加速物化视图支持（Materialized View）。这确保了即使在高数据量下，分解分析也能保持响应迅速和高性能。
我们一直在努力寻找提高 ClickStack 查询性能的方法。有时，这意味着利用正确的访问模式，或确保用户能够充分利用物化视图等功能。但更多时候，关键在于确保在适当的时机应用正确的查询设置和优化。
ClickHouse 核心团队在每个版本中都会推出性能改进和新的优化措施。跟踪这些变化并确保 ClickStack 能够充分利用它们，是我们的持续重点工作。ClickHouse 的近期更新已带来显著的性能提升，现在，我们会在适当且底层 ClickHouse 版本支持的情况下，自动启用这些优化中的一部分。
以下优化措施现已在适当情况下自动应用。
Top N Queries
Top N Queries 在可观测性领域随处可见。例如，“显示最新日志”、“给出最常见的错误信息”、“列出最慢的请求”等。这些模式通常以 ORDER BY … LIMIT N 的形式出现，在日志搜索和排名式仪表盘中尤为常见。
ClickHouse 最近引入了强大的优化，将 Top-N 视为一流的查询模式。在 25.12 版本中，通过 use_skip_indexes_for_top_k 设置，ClickHouse 增加了对跳过索引（skip-index）驱动的 Top-K 过滤的支持。这使得 ClickHouse 能够利用数据跳过索引中的 min/max 元数据，在读取任何行之前，便消除整个数据颗粒（granule）。该引擎不再需要全表扫描后再进行排序，而是能够预先剪枝（prune）大量数据。在 ClickStack 的基准测试中，这项优化使典型日志搜索式查询的性能提升了 2 到 3 倍，在某些情况下甚至更多。
ClickStack 目前已默认启用 use_skip_indexes_for_top_k = 1（在支持的情况下），同时将 query_plan_max_limit_for_top_k_optimization 设置为 100000，以便在面对足够大的结果集扫描时，此优化能够充分发挥作用。当查询的 ORDER BY 子句与表的排序键（ordering key）对齐时，剪枝效果将非常显著，因为数据颗粒（granule）可以完全基于元数据被跳过。
即使排序字段不属于排序键（ordering key），ClickHouse 仍然可以在执行期间应用动态 Top-N 阈值，通过
use_top_k_dynamic_filtering = 1跳过那些无法优化结果集的数据颗粒（granule）。根据数据分布和谓词的不同，这在某些实际日志搜索中可带来高达 2 倍的性能提升。然而，此功能尚未在 ClickStack 中全局启用，因为诸如 Event Patterns 等特性依赖于rand()等函数，这些函数与此优化不兼容。我们计划在不久的将来选择性地启用它。
这些设置将许多 Top-N 查询转变为元数据剪枝问题，而非传统的全表扫描。随着数据集的增长和冷缓存（cold cache）场景变得日益普遍，在数据颗粒（granule）层面避免不必要的读取变得越来越重要。ClickStack 现在已自动利用了这一优势。
欲深入了解这些功能，我们推荐阅读我们的专题博客文章。
更快的跳过索引
ClickStack 已经高度依赖 ClickHouse 的 数据跳过索引 来加速常见的可观测性工作负载。布隆过滤器索引为日志中的快速文本搜索提供支持。Minmax 索引被广泛应用于加速数值范围查询，尤其是在时间戳及其他高基数字段上。如果用户需要进行模式优化，建议他们利用这些索引。
在 ClickHouse 25.9 之前，minmax、set、布隆过滤器、vector 以及 最近新增的 text 等跳过索引都是在读取任何表数据之前进行预先评估的。这种顺序处理方式存在一些明显的弊端。带有 LIMIT 子句的查询在开始执行前，仍需扫描整个索引。在索引分析完成期间，会产生一个初始启动延迟。在某些情况下，扫描索引本身的开销甚至可能超过处理数据本身的开销。
ClickHouse 25.9 引入了二级索引的流式评估。ClickHouse 现在不再是先扫描整个索引，而是将索引检查与数据读取交错执行。当引擎准备读取一个数据粒度 (granule) 时，它会首先查询对应的索引条目。如果索引表明该数据粒度可以跳过，那么它将不会被读取。否则，该数据粒度会被处理，同时索引评估会继续进行后续数据粒度。对于 LIMIT 查询，一旦找到足够的行，执行便立即停止，索引检查和数据读取也会随之终止。
这一改变消除了启动延迟，并避免了不必要的工作。在一张包含 10 亿行数据且布隆过滤器索引大小超过 2 GiB 的表中进行测试时，启用流式索引后，一个简单的 LIMIT 1 查询运行速度提升了 4 倍以上，从大约 10 秒缩短到约 2.4 秒。
此功能由 use_skip_indexes_on_data_read 设置控制（从 25.12 版本开始默认值为 1），但从 25.9 版本起，ClickStack 对其进行强制启用。
阅读关于跳过索引流式支持的 完整深度解析（https://clickhouse.com/blog/clickhouse-release-25-09#streaming-for-secondary-indices）。
将跳过索引用于析取
在 25.12 版本之前，skip indexes（跳过索引）主要应用于简单的谓词或合取条件（如 AND 子句），使得 ClickHouse 能够修剪数据块（granules），减少不必要的数据读取。然而，析取条件（如 OR 条件）并不能从索引剪枝中受益。随着新版本的发布，skip indexes 现在也可应用于析取查询，即使查询包含 OR 逻辑，也能实现剪枝。
这一行为由 use_skip_indexes_for_disjunctions 参数控制，该参数默认启用。因此，ClickStack 能够自动利用更有效的剪枝功能，在更广泛的实际查询模式下减少数据扫描，从而提升性能。
惰性物化 (Lazy Materialization)
ClickHouse 长期以来一直依赖分层 I/O 优化，例如 columnar storage（列式存储）、主次索引、projections 和 PREWHERE，以减少从磁盘读取的数据量。传统上，一旦行通过 WHERE 子句的过滤，所有这些行中被引用的列都会在执行 sorting（排序）、aggregation（聚合）或 LIMIT 等操作之前被加载。在许多分析查询中，尤其是在 Top-N 模式下，这意味着读取大量最终结果并不需要的列。
ClickHouse 25.4 引入并默认启用的惰性物化（Lazy Materialization）改变了这一行为。ClickHouse 不再立即加载所有选定的列，而是推迟到执行计划真正需要时才读取相应列。例如，当一个查询执行 ORDER BY … LIMIT 时，引擎可以仅利用排序列来确定最终的 Top-N 行，随后再读取这些行的其余列。这显著减少了 I/O、内存使用和延迟，尤其适用于 wide tables（宽表）或从超大型数据集中仅返回少量行的查询。如果您对内部原理和深度剖析感兴趣，我们推荐这篇优秀的博客文章 “ClickHouse gets lazier (and faster): Introducing lazy materialization”。
鉴于此优化自 25.4 版本起就已默认启用，用户已从中受益一段时间。然而，此优化仅当 LIMIT 值低于指定阈值 query_plan_max_limit_for_lazy_materialization 时才应用。默认情况下，该阈值为 10,000。
在我们针对日志和追踪搜索的典型 ClickStack 访问模式进行的内部测试中，我们观察到，行数高达 100,000 的结果集仍能从惰性物化（lazy materialization）中获得显著优势——这在很大程度上得益于 近期对该功能进行的进一步优化和改进。因此，在最新版本的 ClickStack 中，我们将此阈值提升至 100,000，从而将性能提升扩展到更广泛的实际查询场景。
我们持续增强 ClickStack 的告警能力。去年，我们引入了 针对已保存搜索和图表的告警功能。在最新发布版本中，用户现在也可以直接在数字图表（number charts）上创建告警。
此功能非常适合基于简单静态阈值的告警场景。例如，如果一个数字指标卡（number tile）代表错误率、请求量、延迟或其他任何关键指标，用户即可在其超出预设阈值时触发告警。该功能的工作流程与现有告警保持一致，因此可以轻松应用于现有仪表盘。
这是一个虽小却非常实用的补充，也是我们为了让告警功能更灵活、更强大而进行更广泛努力的一部分。敬请期待未来版本中更高级的告警能力。
/END/
试用阿里云 ClickHouse企业版
轻松节省30%云资源成本？阿里云数据库ClickHouse 云原生架构全新升级，首次购买ClickHouse企业版计算和存储资源组合，首月消费不超过99.58元（包含最大16CCU+450G OSS用量）了解详情：https://t.aliyun.com/Kz5Z0q9G
征稿启示
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：[email protected]