Ongage 的战略转移：采用 ClickHouse 实现实时电子邮件营销

实时洞察可以成就或毁掉一次数字营销活动。作为一家总部位于以色列的自动化营销公司，Ongage 意识到了这一需求。为了革新电子邮件营销行业，他们为拥有数亿联系人的客户管理数据，并在电子邮件和短信等渠道上大规模执行营销活动。

然而，Ongage 面临一个挑战。他们使用的数据仓库无法提供他们寻求的实时功能。每天处理大约 5 亿条消息（从客户电子邮件反馈到用户行为指标）需要一个强大的解决方案。这篇博文深入探讨了 Ongage 如何应对这一挑战，并通过转型到 ClickHouse 增强其分析能力和运营效率。

在 Ongage 技术历程的早期阶段，团队发现自己在使用 MongoDB、MySQL 和 Redshift 的混合方案。每个数据库都有其独特的用途，但缺乏实时功能很快成为明显的瓶颈。Ongage 研发副总裁 Roman Raslin 表示：“我们现有的数据仓库缺乏我们需要的实时功能。这对于我们的分析和自动化运营尤为重要，在这些运营中，即时事件触发和分析至关重要。” 这促使他们明确需要发展，并开始寻找更高效的解决方案。

Ongage 之前的分析设置严重依赖于大型 MySQL 集群，该集群由 AWS RDS 管理和运营。随着数据量的增加，MySQL 的局限性开始显现。性能急剧下降，分析页面加载时间变得过长。

ClickHouse 的出现，在数据处理实时分析能力方面实现了巨大的飞跃。MySQL 仍然保留用于处理增长不明显的事务数据，并用于使用账户和活动名称等详细信息来丰富 ClickHouse 中的数据。

简化这种转型的关键要素之一是 ClickHouse 内置的 MySQL 引擎。此功能使 Ongage 团队能够轻松地从 MySQL 中提取数据并将其转换为 ClickHouse 的原生表格式。MySQL 引擎不仅用于查询数据，还用于促进向 ClickHouse 的平稳迁移。

在选择数据管理解决方案时，Ongage 团队并没有仅仅选择第一个选项。他们探索了各种解决方案，SingleStore 是主要的竞争者。在深入评估期间，他们将 SingleStore 与 ClickHouse 进行了比较，考虑了存储成本和特定功能的可用性。

从成本角度来看，ClickHouse 提出了更经济的选择。对于相同的数据量，SingleStore 的存储成本是 ClickHouse Cloud 的六倍。考虑到 Ongage 的数据密集型运营，这意味着一笔可观的开支。

在功能方面，ClickHouse 提供了一个 SingleStore 缺乏的明显优势 - 物化视图的实现。此功能是一个主要的省时工具，因为它有助于将大量事件聚合到一个更小、更易于管理的表中。反过来，这大大加快了查询执行速度。

尽管如此，值得注意的是，对于优先考虑事务功能的组织，SingleStore 可能是更合适的选择。由于 Ongage 特别寻求实时分析，因此这不是他们的考虑因素之一。考虑到 Ongage 的具体需求和计划，ClickHouse 显然成为了冠军。

Ongage 决定使用 ClickHouse Cloud 而不是开源自托管选项，这受到了几个关键因素的影响。

首先，云解决方案的运营效率非常突出。Raslin 解释说：“我们在管理 Mongo 集群和 Redshift 集群上花费了大量工作和资金。我们不想再浪费这些时间了。” 尽管他们的 DevOps 团队对自托管感到满意，但他们认识到，通过选择 ClickHouse Cloud，他们可以节省大量的时间和资源。管理 MongoDB 和 Redshift 集群的运营负担已经很重，绕过这些麻烦太有吸引力了，不容错过。

其次，ClickHouse 支持团队的价值不容低估。他们在 Ongage 加速转型中发挥了关键作用，提供了重要的技巧和澄清，使整个过程更加顺畅。事实证明，这种合作是一种成功的方案 - 直接与产品开发人员合作，确保 Ongage 充分利用 ClickHouse 的潜力。正如 Raslin 所说，“当然，构建技术的人员最适合操作它。”

最后，财务方面也倾向于 ClickHouse Cloud。在转型阶段，该服务通过根据使用情况自动扩展来提供可观的成本节省，确保资源得到有效利用。对于 Ongage 的需求而言，这是性能和成本效益的理想平衡。

由于 ClickHouse 与 MySQL 的兼容性，Ongage 向 ClickHouse 的过渡比预期的更顺利，这意味着他们的大部分现有查询无需修改即可运行。正如 Raslin 强调的那样，“考虑到 MySQL 和 Redshift 之间表结构的相似性，查询与我们之前的查询相比没有太大变化。” 这种兼容性极大地促进了集成，减少了潜在的中断。

一旦 Ongage 将 ClickHouse 集成到他们的系统中，就确定了两个主要用例。

第一个用例围绕营销活动分析。Ongage 使用客户已经熟悉的当前 UI 实施了 ClickHouse。这确保了无缝过渡，用户注意到速度显着提高，而无需适应新的界面。在幕后，部署了一个在 ClickHouse 前面新建的微服务，它使用 Node.js。

第二个用例侧重于他们的自动化系统。Ongage 设计了一个用户友好的拖放系统，该系统根据用户交互触发特定操作。例如，如果用户点击了特定的营销活动，系统将在设定的等待时间后通过发送电子邮件或短信等操作做出响应。它还可以在继续操作之前检查用户细分。至关重要的是，此拖放系统的每个块都附加了分析，从而可以概览其在选定时间范围内的表现。

有趣的是，尽管后端发生了重大变化，但两个用例的 UI 都没有改变。

ClickHouse 的实施还为 Ongage 带来了实时决策能力。以前，生成必要的业务报告是一项耗时且有时很麻烦的任务。“我们以前使用 MySQL，有时仓库需要两到三个小时才能生成一份报告，有时会导致系统发出警报。这很痛苦，”Raslin 说。

然而，有了 ClickHouse，情况发生了巨大的变化。“当我们测试相同的报告在 ClickHouse 上需要多长时间时，人们感到非常惊讶。我们运行了相同的数据，转眼间，我们就得到了结果，”Raslin 说。ClickHouse 提供的快速数据访问不仅给团队留下了深刻的印象，也赢得了公司董事的支持。新发现的效率和速度使他们能够比以往更快地做出明智的决策。

Ongage 的架构随着时间的推移而演变，以满足实时数据分析和自动化基础设施的需求。ClickHouse 是 Ongage 架构的核心。

1. 插入原始数据和丰富数据：其架构的第一步涉及将原始数据传输到 S3。然后，使用 S3 集群函数，立即将其插入到 ClickHouse 中。同时，使用 MySQL 引擎将大约八个来自 MySQL 的表复制到 ClickHouse 中，以确保其数据保持更新和丰富。然后，将此数据传输到 MergeTree 表，并通过 exchange 命令使其可用。得益于 ClickHouse 的 MySQL 语法兼容性，此过程得到了简化。

2. 物化视图和 SummingMergeTree：其架构的最后一步涉及使用在插入原始数据时触发的物化视图。此物化视图运行多个连接以丰富数据，然后将数据写入 SummingMergeTree 表 - 这是消费者查询的最终目的地。此步骤将所有数据按照不同的“分组依据”参数聚合在一起，从而实现快速分析结果。根据用例，MySQL 数据可以是仅追加的，也可以完全刷新。

物化视图和 SummingMergeTree：其架构的最后一步涉及使用在插入原始数据时触发的物化视图。此物化视图运行多个连接以丰富数据，然后将数据写入 SummingMergeTree 表 - 这是消费者查询的最终目的地。此步骤将所有数据按照不同的“分组依据”参数聚合在一起，从而实现快速分析结果。根据用例，MySQL 数据可以是仅追加的，也可以完全刷新。

Ongage 最初开始使用 ClickHouse 时主要关注分析，此后已将使用范围扩展到他们的自动化项目。然而，旅程并没有在此结束；他们正在积极寻求将更多流程迁移到 ClickHouse。

这种持续转型的第一步涉及完全迁移他们的一些遗留管道。他们计划使用 Kafka 来流式传输数据，利用最近推出的 ClickPipes 产品。

Ongage 计划将更多数据从他们现有的 Redshift 集群传输到 ClickHouse。他们在使用 ClickHouse 的实时功能和成本效益方面的经验表明，该平台可以管理他们目前使用 Redshift 完成的许多任务。

Ongage 向 ClickHouse 的转型在非常短的时间内取得了令人印象深刻的成果。不仅他们的系统性能得到了显着提高，而且他们的报告和实时分析能力也得到了大幅提升。查询转换的简易性和转型过程中 ClickHouse 的支持进一步简化了他们的迁移。

凭借 ClickHouse 的可扩展性，处理如此庞大的数据变得更加精简。物化视图的使用以及 MySQL 引擎的战略性使用提高了数据分析的速度，从而在各个方面实现了更好的决策。

此外，与他们之前的系统相比，ClickHouse 的成本效益确保 Ongage 不仅获得了强大的数据处理解决方案，而且还获得了可持续的解决方案，因为数据量不可避免地会增长。随着 Ongage 继续利用 ClickHouse，进一步提高性能和节省成本的机会前景广阔。

了解更多信息：https://www.ongage.com/