iFood 用 ClickHouse Cloud 构建智能体安全平台

摘要

• iFood 使用 ClickHouse 作为其内部安全平台的基础，支持每个业务部门的检测、调查和长期日志保留。
• iFood 最初在 Databricks 上构建其安全平台，Databricks 仍广泛用于商业智能和数据科学，但安全团队需要更快、更具可扩展性的日志摄取、长期保留以及更快的应急响应。
• 借助 ClickHouse Cloud，该团队以 40-50% 的成本实现了 9-16 倍的查询速度提升，同时从每小时批量更新转变为近实时的数据新鲜度。
• 这一转变开启了智能体威胁狩猎：以前需要分析师一周的工作现在只需约 2 小时即可完成，多个子智能体并行查询超过 30 TB 的数据。

iFood 是拉丁美洲领先的食品配送平台。它成立于 2011 年，在巴西食品配送行业拥有超过 80% 的市场份额，并已扩展到杂货、药房、宠物用品、金融服务等领域。

Jesus Santos 领导公司的安全事件响应团队，该团队是约 100 人的网络安全组织的一部分，服务于每个业务部门。

我们采访了 Jesus，以了解 iFood 的 ClickHouse 之旅。虽然 Databricks 仍然是 iFood Lakehouse 的基础，但安全事件响应团队发现 ClickHouse 是一个可以集成到该架构中并满足他们需求的引擎：高容量日志摄取、长期保留，最重要的是快速访问数据，以便他们能够快速响应事件。

了解为什么 AWS 上的 ClickHouse Cloud 是正确的选择，在实现规模化所需的速度和成本效益的同时，解锁了以前不可能实现的智能体威胁狩猎工作流。

触及成本上限

当 iFood 的网络安全团队组建时，他们选择不购买打包的 SIEM，而是围绕公司已经在运行的 Databricks 自建系统。

Jesus 解释说，问题在于 iFood 的安全需要大量日志、长期保留，以及在事件发生时快速提取数月历史数据的能力。随着操作超过 130 TB，满足这些需求的成本变得难以扩展。

为了控制支出，公司领导层和平台管理员引入了查询超时，首先将查询限制为 20 分钟，然后将该限制减少到 10 分钟。对于 Jesus 的团队来说，他们需要扫描三到六个月的日志来构建新的检测，这些超时使得这项工作几乎不可能完成。他说：“随着 iFood 规模和范围的增长，我们根本无法在这些参数范围内工作。”

预算限制造成了额外的限制。Jesus 说：“在我们可以支出的预算上限内，我们可以创建的警报数量受到限制。因此，由于平台成本，我们的目标受阻。”

他们需要的是一个能够满足其安全团队要求的平台，在这个平台上，成本不再是上限。他说：“这就是 ClickHouse 发挥作用的地方。”

使用 ClickHouse Cloud 更便宜、更快

ClickHouse 对 iFood 来说并不陌生，他们有过通过开源 ClickHouse 拉取日志文件进行临时查询的经验。

对于安全事件响应团队来说，ClickHouse Cloud 是自然的选择。他们使用一个月的真实生产数据在 ClickHouse 和 Databricks 中进行了概念验证。“我们尽量做到公平，给两个解决方案相同的架构和几乎相同的查询，”Jesus 说。

“ClickHouse 的性能价格比非常惊人。我们看到了 9-16 倍的性能提升，而成本是以前解决方案的一半。” — Jesus Santos，iFood 安全事件响应团队负责人

解决了这些问题后，Jesus 和团队开始重建他们的安全工具，从调度和警报、去重、关联到值班升级。“我们吸取了所有的经验教训和面临的问题，创建了一个更适合我们的工具，”他说。

借助 ClickHouse Cloud，iFood 预计将成本降低 40% 至 50%，同时获得更快的性能。数据新鲜度也得到改善；以前大多数数据每小时批量处理一次，现在几乎实时到达，因此调查可以快得多。“整个系统运行得更快、更流畅，”他说。“我们对所得到的结果非常满意。”

iFood 基于 ClickHouse 的新架构

在 iFood 的安全平台中，日志来自各处：基础设施和文件系统、Kubernetes 工作负载、云管理控制台。“任何产生审计数据的地方，我们可能需要这些数据，”Jesus 说。所有这些数据都进入 AWS S3，并通过 ClickPipes（ClickHouse Cloud 的原生摄取层）摄取到 ClickHouse 中。结果是端到端的新鲜度在 2 到 10 分钟之间，Jesus 表示这足够快，并且值得换取 ClickPipes 提供的可靠性和易用性。如果他们确实需要亚分钟级的新鲜度，Kafka 仍然是一个选择，因为 ClickPipes 支持 Kafka 以及许多其他数据源。

iFood 安全平台的日志摄取管道架构

在查询方面，团队全程使用 SQL（这是最初吸引他们使用 ClickHouse 的部分原因）。在调查方面，分析师习惯于使用 Databricks 上的笔记本，他们可以在调查过程中添加单元格，并保留分析师查看内容和时间的运行记录。为了保留这种工作流程，团队采用了 Querybook（一个开源笔记本平台），并在此基础上构建自己的调查工具，与公司正在各团队推动的 AI 工作流更紧密地集成。

对于他们的用户界面，团队正在搭建 ClickStack（ClickHouse 的可观测性堆栈）。Jesus 希望将其作为展示运营 KPI 的主要方式：他们生成了多少警报，摄入了多少日志，有多少变成了调查和事件。“单一玻璃面板，”正如他所说，以便任何人都可以看到运营运行情况。

使用 ClickHouse 和 Langfuse 进行智能体威胁狩猎

自迁移以来，ClickHouse Cloud 已成为 iFood 网络安全团队以 AI 构建的核心。正如 Jesus 所说：“ClickHouse 是我们整个 CSIRT 的 AI 战略的核心。”

一个典型的例子是智能体威胁狩猎。在过去的六个月里，该团队构建了自动运行威胁狩猎的工具。分析师提出假设（例如“我们在 AWS 基础设施方面是否遭到入侵？”），AI 智能体在日志中扫描以确认或排除。曾经需要分析师大约一周的工作现在大约需要两个小时。

Jesus 指出，仅端点检测与响应（EDR）日志每天就会生成 1.6 TB 的原始数据。一次狩猎通常查看一个月或更长时间的数据，因此一次多达 50 TB。目标日志保留期为 6 个月到 1 年，只有 ClickHouse 才能实现。

在狩猎的早期阶段，团队生成 10 到 15 个假设，并并行调查多个假设。他们同时启动子智能体，一次五个，每个智能体运行自己的查询。由于 ClickHouse 提供快速、经济高效的查询，这些智能体可以自由迭代并产生更强的结果。早期测试很有希望：以前需要分析师整整一周手动狩猎的工作，现在可以通过 ClickHouse 上的 AI 智能体工作流在大约两个小时内完成。

“有了 ClickHouse 中的安全数据，我们的智能体可以借鉴数月的历史背景，而且由于查询速度如此之快，可以快速大规模地测试多个假设。” — Jesus Santos，iFood 安全事件响应团队负责人

为了了解智能体在做什么并改进它们以更好地狩猎，团队使用Langfuse，开源 AI 可观测性和评估平台ClickHouse 于 2026 年收购，以查看每次分析成功或不足之处，并相应地调整智能体。Jesus 说：“Langfuse 对我们来说很重要，可以详细了解分析方面的情况，以及如何调整智能体以进行更好的分析。”采用范围远远超出安全领域，iFood 已在全公司对 500 多人进行了 Langfuse 智能体遥测和分析培训。

立即开始

有兴趣看看 ClickHouse 如何处理您的数据？几分钟内即可开始使用 ClickHouse Cloud，并获得 $300 的免费额度。

注册

更快的检测，以及一个正在传播的平台

对于 Jesus 的团队来说，ClickHouse 的影响在平均检测时间等 KPI 中显而易见。“以前我们不能每小时运行多次的警报，现在平均每 10 分钟运行一次。我们现在可以做到这一点，因为警报执行只需几秒钟，”他说。平均响应时间也在改善，这要归功于更新的数据和更快的查询。

展望未来，该团队计划将 CDN 和 API 日志从 OpenSearch 迁移到 ClickHouse，将保留期从 7 天延长到 6 个月，成本仅为原来的四分之一。“当我们完成 API 日志的迁移时，我们将能够进行以前无法想象的分析，”Jesus 说，他指出事件通常可以追溯到一周以上，他的团队遇到过可疑行为在他们介入前一个月或更早就开始的情况。目标是捕获到达 iFood 应用的每一个请求。

正如 Jesus 所说，“我们在这里所做的工作展示了 ClickHouse 有一天可以为整个公司带来的潜力、节省和性能。”