QuintoAndar 用 ClickHouse 统一 9 亿月事件并兼容 Postgres 生态

QuintoAndar，成立于2013年，用自身的承保取代了担保人。如今它是拉丁美洲最大的住房平台，为寻找租房、买房或卖房的人提供直接、简单、透明的体验。它每月签订超过15,000份新租赁合同和3,000份销售合同，每月安排超过650,000次看房。

Bruno Brito是客户数据平台（CDP）团队的技术负责人，负责收集、整合和统一租户、业主和中介的数据。他说：“我们每月从超过1400万用户那里收集超过10亿个事件，其中每月有近9亿个原始事件进入ClickHouse。”然后这些数据通过每月大约3亿次API请求返回给聊天机器人和内部服务。

Bruno加入我们最近的网络研讨会，他在会上介绍了他的团队如何重建CDP于ClickHouse Cloud，从整合到几乎阻止它的障碍，以及ClickHouse Managed Postgres如何成为缺失的一块。

旧Lambda架构的问题

CDP始于移动用户跟踪事件和来自事务数据库的变更数据捕获，通过Kafka流式传输。两者都流入内部事件网关，团队在此应用治理、进行转换并沿途丰富事件。所有这一切都服务于Bruno所称的团队的“客户360度视角”。

之前的架构然后沿着经典的Lambda线分裂。热层（另一个内部Postgres服务，称为Datazord）消费网关的输出主题，并通过其自己的Postgres数据库向聊天机器人和其他内部消费者提供用户信息，选择它是为了低延迟读取。冷层使用Kafka Connect将所有内容转储到数据湖中的着陆区，24/7的Databricks工作流将其处理成银层，分析ETL和他们的用户激活工具Hightouch可以从中提取数据。

之前的CDP架构：事件网关的输出主题分成热层，Datazord从Postgres服务聊天机器人，以及冷层运行24/7的Databricks工作流。

正如Bruno所解释的，存在几个问题。首先，团队必须维护两个独立的代码库，这是任何运行Lambda架构的人熟悉的代价。其次，在冷路径中，大量重复事件意味着对Delta表进行不断的MERGE INTO操作。“每次复制所有这些百万计的事件不仅在成本上而且在时间上都变得昂贵，”Bruno说。第三，保存热层的Postgres实例开始看起来不适合处理其中的事件量。

“作为一个架构，它有点复杂，”Bruno说。“所以我们在想，我们如何简化它，使其更快，并拥有这种高新鲜度、低延迟的架构，让我们能够提供所有这些信息？……那时我们找到了ClickHouse。”

整合到ClickHouse Cloud

团队的回答是停止将Kafka主题视为管道的输出，而是让事件网关直接写入ClickHouse。回顾旧图表，Bruno列出了变化：“我们可以摆脱这个，摆脱这个，摆脱那个……我可以使用ClickHouse来支持我们所有的分析查询。”

在新架构中，Hightouch将为用户激活查询ClickHouse，Datazord可以从ClickHouse而不是其自己的Postgres提供API请求，仍然在不到一秒内返回结果。这将消除着陆区、不断的MERGE INTO操作以及第二个代码库的需要。

Bruno指出，QuintoAndar更广泛的数据组织在Trino上运行Superset。他的团队想知道他们是否会与其他所有人隔离开来。在实践中，答案是否定的。ClickHouse的连接器意味着Trino和Apache Spark都可以访问CDP的表，ClickHouse也可以反向读取公司数据湖中的Delta表。他说：“与这个栈集成对我们来说不是一个大问题。”

CDP团队正在实施的新栈：事件网关直接写入ClickHouse，Superset、Trino和Spark都能访问CDP的表。

障碍：“ClickHouse在哪里？”

ClickHouse看起来是完美的匹配。但随后到了Bruno说所有工程师在某个时刻都面临过的时刻：“你为你的架构选择了一个新部件，你开始测试它，它工作得很好，然后你开始与你所有的其他第三方工具集成……”

在QuintoAndar，Hightouch对营销组织的运作至关重要，将受众数据同步到运行其活动的平台。营销团队想要使用其Customer Studio功能，这将使他们能够构建受众、细分用户、运行A/B测试并组装多步骤旅程。然而，当Bruno的团队去查看文档，检查Customer Studio支持哪些源——Snowflake、Databricks、BigQuery、Redshift、Athena、Synapse、MS SQL Server、PostgreSQL、Greenplum、Microsoft Fabric——列表中明显缺少一个名字。

“ClickHouse在哪里？”Bruno记得问道。“它似乎是一个很棒的解?方案，完美适合我们所有的用例，直到它不再适合。”

Databricks是QuintoAndar栈中唯一符合条件的引擎，但中央数据团队由于高成本决定放弃Databricks SQL Warehouse，倾向于开源替代品如Trino，而CDP团队想要使用ClickHouse。然而，Trino也不受支持。

那留下一个选项：Postgres。幸运的是，ClickHouse刚刚推出了一个新服务，让团队在一个统一的栈中运行分析和事务工作负载。正如Bruno回忆，“那时我们听说了ClickHouse的托管Postgres服务。”

缺失的一块：ClickHouse Managed Postgres

将Hightouch连接到ClickHouse Managed Postgres 让 Postgres 代表它连接 ClickHouse。

“我们在 ClickHouse 中看到的卓越性能、低延迟以及所有优秀特性，都能够通过 ClickHouse 托管的 Postgres 在 Hightouch 中加以利用。这正是我们架构中所缺失的部分。” — Bruno Brito，QuintoAndar 技术主管经理

关键机制是pg_clickhouse 扩展。他解释说，设置过程很简单：创建扩展、创建指向 ClickHouse 的外部服务器、创建 schema，并导入外部表。之后，ClickHouse 表就可以像普通 Postgres 表一样被查询，连接和聚合操作会被下推，而不是被拉回到 Postgres 中。

Hightouch 连接到由 ClickHouse 管理的 Postgres，该 Postgres 会将分析查询下推到 ClickHouse，而事件网关已经在那里直接写入事件。

当被问及从 Postgres 到 ClickHouse 再返回的往返过程对性能有何影响时，Bruno 表示影响可以忽略不计：“对于 Hightouch 的用例而言，这完全不会产生影响。”

而且 Postgres 不仅转发查询。Hightouch 的 Lightning Sync 功能维护自己的状态（一个规划器表和一个审计表），以便定时同步只推送发生变化的内容，而不是每次都推送整个受众群体。这些表存储在 Postgres 中，使用 NVMe 存储。一个连接最终承担了两项工作。

“它像 OLTP 数据库一样在 Postgres 中持久化数据，但实际在 ClickHouse 中运行分析查询。因此，我们充分利用了两者的优势。” — Bruno Brito，QuintoAndar 技术主管经理

托管 Postgres 作为通用接口

对于 QuintoAndar 来说，使用 ClickHouse 托管的 Postgres 的最大好处之一是架构更加简单。“ClickHouse 变成了一个即插即用的数据库，你可以连接任何支持 Postgres 的第三方工具，”Bruno 说。

他补充说，这种简单性并不会以牺牲治理为代价：“并不是说 Postgres 就能访问 ClickHouse 中的所有内容。你仍然需要创建用户、角色，并在需要时授予你想授予的访问权限。”

团队还充分利用了 ClickHouse 的全部价值，而不是为了满足单一集成而支付第二个仓库或查询引擎的费用。正如 Bruno 所说，“你确实可以利用 ClickHouse 的能力，并最大限度地发挥它的作用。”

当被问及是否考虑过替换 Hightouch 时，Bruno 表示团队从未需要考虑这个选项；他们可以继续使用已有的解决方案。展望未来，任何支持 Postgres 的工具都可以以同样的方式连接 ClickHouse。“你仍然可以使用 ClickHouse，”他说，“即使你的一些合作伙伴还不支持它。”