从实时行情到 AI 智能体:ClickHouse 2025 年最值得看的 Demo 全盘点

本文字数：4055；估计阅读时间：11 分钟

作者：Mark Needham

随着一年接近尾声，整体节奏也逐渐放缓，这正是一个适合跳出细节、回顾我们团队一年成果的好时机。我在 ClickHouse 的工作中，有相当一部分时间都投入在演示项目上，这也是我非常享受的一件事。因此，我想借此机会回顾一下今年我们构建的一些最重要、也最有代表性的演示。

这个想法也源于假期前我与同事 Tom Schreiber 的一次交流。他长期从事 ClickHouse 的基准测试工作，并在聊天中分享了一点让我印象深刻的体会：

基准测试非常适合用来衡量和理解 ClickHouse 的速度，但真正能让人切身体会到这种速度的，是演示。

这句话说得非常贴切。没有什么能比真实世界的案例更直观地展示 ClickHouse 的性能优势，以及它如何支撑大规模、令人惊叹的应用。而且，这种看法并不只来自我们自己。像 Tesla 这样的客户，已经向 ClickHouse 写入了超过一千万亿行数据；又或者 GitLab，为数千万用户提供亚秒级查询服务，他们大概都会认同这一点。

这也是本文中所有演示所贯穿的一个共同主题，也是回顾我们今年成果的一个很好起点。

StockHouse：实时市场分析

StockHouse 是一个实时市场分析应用，基于 Massive APIs 提供的实时股票和加密货币数据构建。它通过 WebSocket APIs 实时接收行情数据，将数据持续写入 ClickHouse，并展示在一个使用 Perspective 构建的仪表盘中，整个界面可以在毫秒级内完成更新。

这个演示最吸引我的地方在于，ClickHouse 的速度变得触手可及。当价格发生变化时，图表几乎同步变化，没有缓冲，也看不到任何明显的延迟。

从工程实现的角度来看，StockHouse 很好地展示了将实时数据接入 ClickHouse 所需的配置是多么简单。用于摄入的 Go 程序直接连接 Massive 的 WebSocket APIs，并通过原生的 ClickHouse 接口批量写入数据，整个过程不需要复杂的数据管道，也不依赖任何外部流处理系统。

在查询层面，这个演示使用了物化视图。原始行情数据会被完整保留下来，而为实时 UI 提供数据的查询，则来自预先聚合好的表。每日的开盘价、收盘价、成交量以及最后更新时间戳，都在数据写入时完成计算，因此仪表盘查询可以保持足够简单，同时也非常高效。

整体模式非常清晰：原始事件用于保证灵活性，物化视图用于提升查询性能，最终得到的查询几乎都能在几毫秒内完成。这是 ClickHouse 中一种非常常见的设计方式，而当它被应用到实时市场数据场景时，这些设计取舍会显得尤为直观。

对于任何需要构建实时仪表盘的场景来说，StockHouse 都是一个非常好的参考，无论数据来自金融市场、传感器，还是可观测性流水线。而且，它是完全开源的。

ClickGems 最初只是 Ruby Central 团队提出的一个简单需求。他们希望社区能够更方便地使用 SQL 来探索 RubyGems 的下载统计数据。当我们把这些数据加载进 SQL Playground 之后，很快就意识到，它值得拥有一个专门的分析界面。

从本质上看，ClickGems 可以被视为一个面向 RubyGems 的 ClickPy。它复用了相同的代码库和整体思路：将大型公共数据集开放出来，以 ClickHouse 作为后端存储，并通过快速、透明、由 SQL 驱动的可视化方式，让用户自由探索数据。这套方法已经被证明具有很好的扩展性。今年 ClickPy 的数据规模突破了两万亿行，而 ClickGems 也直接受益于这些成熟的设计选择。

我非常喜欢这个演示所体现出来的协作方式。Ruby Central 负责协助数据的摄入与校验，Metabase 提供了可分享的图表能力，双方的合作让 ClickGems 在实际使用中真正变得有价值。

从技术实现上来看，ClickGems 再次印证了我们在多个演示中反复采用的一种模式：数据先以原始形式写入系统，再通过物化视图聚合成符合常见查询需求的数据形态。每一个图表背后，都对应着一条清晰可见的 SQL 查询，用户可以自行查看并运行，可视化层与数据库之间不存在任何隐藏逻辑。

如今，ClickGems 已经成为一个免费的分析平台，覆盖超过 200,000 个 gem，以及多年的下载历史数据。同时，它也很好地展示了 ClickHouse 如何在大规模场景下，支撑面向公众、以读为主的分析型工作负载。

AgentHouse 从另一个角度出发进行了探索。我们没有再去构建一个新的仪表盘，而是希望展示 ClickHouse 如何作为智能体式（agentic）应用的后端来发挥作用。

AgentHouse 构建在 LibreChat 和 ClickHouse 之上，通过 ClickHouse MCP server 直接查询托管在 ClickHouse Cloud 中的真实数据集。用户可以使用自然语言提出问题，查看系统生成的 SQL，并基于真实数据获得即时反馈。

这个演示最让我喜欢的一点在于，它非常直观地呈现了智能体式应用在现实中的运行方式。这里不存在抽象层，也没有任何模拟环境。大语言模型（Large Language Model）直接生成 SQL，在 ClickHouse 的实时数据上执行查询，并基于真实的查询结果进行推理，使整体架构一目了然。

AgentHouse 使用的是我们 SQL Playground 中已有的数据集，包括 RubyGems、PyPI、GitHub 和 Hacker News。这让它成为一个非常合适的实验环境，用来观察自然语言接口在大规模、真实世界数据集上的表现。

对我们而言，AgentHouse 的重点并不在于替代 SQL，而在于拓展人们与数据交互的方式。它展示了 ClickHouse 如何融入由大语言模型驱动的系统，同时依然保持透明性、高性能以及对系统的掌控力。

我们构建 ClickStack 演示，是为了让用户更直观地体验，在 ClickHouse 之上实现可观测性（observability）究竟是什么样子。这个演示的核心思路，是让你代入一名 SRE 的角色，使用整套技术栈去排查一次真实的应用事故，并沿用你在生产环境中熟悉的工作流程。

该演示基于官方的 OpenTelemetry 演示项目，该项目模拟了一个由微服务构成的电商应用，并通过负载生成器持续产生访问流量。所有服务都使用 OpenTelemetry 进行埋点，通过标准的 OTel Collector，将日志、追踪、指标以及会话数据统一写入 ClickHouse。

数据集大约包含 40 小时的遥测数据，并且每天都会进行一次重放，同时将时间戳平移到当前时间窗口中。所有信号都以宽事件的形式存储在 ClickHouse 中，并通过 HyperDX 进行分析，日志、指标和追踪不再需要各自独立的后端系统。

这个演示让我特别喜欢的一点在于，它几乎完整复现了一名 SRE 的真实工作过程：从一个模糊的异常现象入手，通过日志逐步缩小问题范围，再借助追踪和指标验证系统行为，最后从用户视角确认实际影响。

Alexey Milovidov，ClickHouse 的 CTO 兼联合创始人，一直非常热衷于引入新的数据集，并基于 ClickHouse 构建各种演示，让探索数据变得更容易，这一点当然也不例外。

今年，他扩展了一个最初用于航空交通数据的可视化工具，并将其应用到了多个新的演示中。其中较早的一个基于 Foursquare 数据，在地图上展示了商店、餐厅、公园、游乐场以及纪念碑等地点信息。

随后，Alexey 又探索了一个颇为特别的数据集，该数据源自飞机的遥测信息，用于推断天气状况。这些数据被写入 ClickHouse，并且相关实验实现了完整的端到端复现。

之后，他将注意力转向了一个以鸟类观测为主题的数据集，同样将数据写入 ClickHouse，并在 adbs.exposed 上进行了可视化展示。

而这一切还没有结束。在年底前的几周，Alexey 又发布了一个新网站，用来跟踪 ClickHouse 团队在 GitHub 上的活动情况。

感谢你，Alexey，为今年带来的所有精彩演示。

回头来看，这些演示覆盖了非常不同的使用场景，从实时仪表盘，到面向公众的分析站点，再到由智能体驱动的交互接口。但它们背后依然遵循着同样的核心理念：保留原始数据，通过物化视图对数据进行整理，保持查询逻辑的清晰可见，并依靠高性能来简化系统的其余部分。

所有这些演示都是在开放环境中构建的。代码、表结构和查询都公开可见，任何人都可以阅读、复用或改造。它们并不是停留在幻灯片里的参考架构，而是真正可运行的系统，开发者可以将其拆解，并作为自己应用的基础。在结合真实数据和真实规模的情况下，这种开放性尤为重要。正如我在引言中与 Tom 讨论的那样，演示让人能够真正感受到 ClickHouse 所支持的速度与规模：你可以看到查询在毫秒级返回，观察仪表盘实时更新，并探索那些在许多其他系统中几乎难以处理的数据集。

对我来说，这正是演示与基准测试相互补充的地方。

我们会在 2026 年继续构建更多这样的演示。

/END/

试用阿里云 ClickHouse企业版

轻松节省30%云资源成本？阿里云数据库ClickHouse 云原生架构全新升级，首次购买ClickHouse企业版计算和存储资源组合，首月消费不超过99.58元（包含最大16CCU+450G OSS用量）了解详情：https://t.aliyun.com/Kz5Z0q9G