Ongage 将实时电子邮件营销战略转向 ClickHouse

Elissa Weve

2023年8月24日

实时洞察可以成就或破坏数字营销活动。作为一家总部位于以色列的自动化营销公司，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架构的核心。

插入原始数据和数据丰富：其架构的第一步涉及将原始数据传输到S3。然后，使用S3集群功能将其立即插入到ClickHouse中。同时，使用MySQL引擎将MySQL中的大约八个表复制到ClickHouse中，以确保其数据保持更新和丰富。然后，将这些数据传输到MergeTree表，并通过exchange命令使其可用。由于ClickHouse与MySQL语法兼容，因此此过程得到了简化。
物化视图和SummingMergeTree：其架构的最后一步涉及使用在插入原始数据时触发的物化视图。此物化视图运行多个连接来丰富数据，然后将其写入SummingMergeTree表——最终目标，消费者从中查询数据。此步骤将所有数据汇总到不同的“group by”参数上，从而实现快速分析结果。根据用例的不同，MySQL数据要么是追加式的，要么是完全刷新的。

物化视图和SummingMergeTree：其架构的最后一步涉及使用在插入原始数据时触发的物化视图。此物化视图运行多个连接来丰富数据，然后将其写入SummingMergeTree表——最终目标，消费者从中查询数据。此步骤将所有数据汇总到不同的“group by”参数上，从而实现快速分析结果。根据用例的不同，MySQL数据要么是追加式的，要么是完全刷新的。

Events collector.png