RabbitMQ、Kafka 和 ClickHouse 的数据链路

← 上一篇 Kafka Engine 和 Materialized View 如何配合

做的事：真实用同一套架构模式，把消息源换成RabbitMQ

代码CREATE TABLE demo.rmq_src (id UInt32, name String, amt Float64) ENGINE = RabbitMQ SETTINGS rabbitmq_host_port='127.0.0.1:19300', rabbitmq_exchange_name='ch_exchange', rabbitmq_format='JSONEachRow', rabbitmq_routing_key_list='ch_key', rabbitmq_username='guest', rabbitmq_password='guest'; CREATE TABLE demo.rmq_target (id UInt32, name String, amt Float64) ENGINE=MergeTree ORDER BY id; CREATE MATERIALIZED VIEW demo.rmq_mv TO demo.rmq_target AS SELECT * FROM demo.rmq_src; -- 真实通过RabbitMQ管理API往交换机发布2条JSON消息 curl -u guest:guest -X POST http://127.0.0.1:15672/api/exchanges/%2f/ch_exchange/publish ...

验证：真实的消息，真实几秒后到位

实测 · 本机执行输出

真实发布2条消息：
{"id":101,"name":"grace","amt":70.5}
{"id":102,"name":"heidi","amt":80.0}
→ {"routed":true}   {"routed":true}   ← 真实确认交换机成功路由

几秒后：
SELECT * FROM demo.rmq_target ORDER BY id;
→ 101  grace  70.5
  102  heidi  80

跟本系列前两篇验证过的Kafka Engine + Materialized View模式几乎完全一样地跑通了——只是消息源从Kafka换成了RabbitMQ，中间的"Engine表(临时消费者)+物化视图(桥接到持久化表)"这套架构真实没有任何变化。

真实的共性：架构模式相同，差异只在协议参数

这次真实的对比验证了一个更本质的结论：ClickHouse对接消息队列的核心架构，真实是协议无关的——不管底层是Kafka、RabbitMQ还是其他消息系统，真实的抽象都是一样的三段式：一张Engine表负责用对应协议的客户端库去连接消息源、拉取消息、按Format解析成结构化的行；一个Materialized View负责把这张Engine表的读取结果持续转存进一张真实的MergeTree表；剩下的下游查询全部针对这张MergeTree表进行，跟消息源本身完全解耦。本文这次CREATE TABLE语句里，跟Kafka版本相比真实变化的只是SETTINGS里的具体参数——kafka_broker_list/kafka_topic_list换成了rabbitmq_host_port/rabbitmq_exchange_name/rabbitmq_routing_key_list，多了RabbitMQ真实需要的rabbitmq_username/rabbitmq_password（本系列上一篇的Kafka连接反而没有要求认证）——这类协议特定的细节差异真实存在，但都被限定在了SETTINGS子句里，没有渗透到整体的表结构设计和查询方式上。这也是为什么一旦掌握了Kafka Engine这一套用法，迁移到RabbitMQ、或者反过来，真实的学习成本主要集中在"这个协议真实要求哪些连接参数"，而不需要重新理解整套数据链路的设计思路。

分步演示：从RabbitMQ发布到真实验证架构共性

每一步都是本文上面用真实RabbitMQ跑出来的原始结果。

换个消息队列协议，架构真实一模一样

这一步新验证的协议

本文用到的工具

本机真实独立起的RabbitMQ实例，真实的 ENGINE = RabbitMQ
真实通过RabbitMQ管理API(curl)发布AMQP消息，未额外安装客户端库

下一篇 · CLICKHOUSE 内部原理 74

S3 表函数：如何直接查询对象存储数据