DeepL 与 ClickHouse 的旅程

Jannik Hoffjann & Till Westermann

2022 年 7 月 26 日

我们很高兴欢迎 DeepL 加入我们的博客。继续阅读以了解 DeepL 如何使用 ClickHouse 作为其中心数据仓库。

在 DeepL，我们使用 ClickHouse 作为我们的中心数据仓库。如今，它为多个用例提供服务：从我们网站和应用程序的分析到让每个人都能访问公司指标，以及技术监控。在这篇博文中，我们想与大家分享我们在 ClickHouse 上的旅程，我们是如何开始的，以及我们构建了什么。

我们与 ClickHouse 的旅程始于 2020 年，当时我们想要以保护隐私的方式构建我们的分析功能。当时，我们评估了几个选择以自托管解决方案。Hadoop 世界被认为维护过于繁重，而且建立起来需要很长时间。由于 ClickHouse 具有来自 apt 存储库的单二进制部署，因此非常容易且快速地建立 MVP（最小可行产品）以查看它是否能在我们的规模上运行。我们从单个节点设置开始，其中 ClickHouse 运行在虚拟机内，甚至与其他几个服务共享虚拟机管理程序。

MVP 包含一个 API，用户浏览器将事件发送到该 API，Kafka 作为消息代理，一个从 Kafka 写入 ClickHouse 的接收器，ClickHouse 本身以及 Metabase 来可视化结果。架构如下所示

MVP 在几周内就组装好了，并证明了该系统能够轻松处理我们投入的数据量，而且查询时间非常出色。

作为下一步，我们对自动化进行了大量投资。事后看来，这是一个非常明智的决定，因为当前端开发人员创建新事件时，团队将不得不花费大量精力来更改表架构。我们决定为所有事件和表架构创建一个统一的真相来源。当前端想要创建新事件时，他们需要在 protobuf 中定义此事件。此 protobuf 架构文件用于三个目的

API 验证事件并检查数据一致性。这减少了错误，并为团队节省了时间，让他们专注于重要的事情
接收器计算 ClickHouse 表架构，将其与现状进行比较，并在需要时修改表格
我们根据 protobuf 文件自动创建关于所有事件及其含义的文档。

鉴于用户与翻译器的交互复杂性，与例如电子商务网站相比，ClickHouse 允许我们创建复杂的事件和查询，以了解用户如何与我们互动。Google Analytics 之类的工具无法执行此操作。所有这些都可以在完全控制数据本身的同时，并牢记用户的隐私。这使我们能够让 DeepL 的每个人都能全面了解每个平台上发生的事情，并使其成为 DeepL 内部的首选系统。

有了这些保障，团队专注于向 ClickHouse 添加越来越多的来源。我们添加了我们的原生应用程序、Linguee、与第三方系统的集成等等。

对于 DeepL 而言，这不仅仅是引入了一个分析平台，而是向许多关键组件的以数据驱动开发方式转变：主翻译页面、注册漏斗、应用程序中的行为；收集到的数据用于让产品经理了解我们的产品的使用情况，让设计人员发现机会，并找到对用户造成困扰的错误。

在使用 16 个月后，我们从单个节点设置扩展到一个包含 3 个分片和 3 个副本的集群。在此之前，单个节点和一个副本就足够了，而且运行良好。目前，此设置每天摄取约 5 亿行原始数据。

构建了数据基础之后，就该继续在这个平台上构建更多内容了。

实验（也称为 A/B 测试）是通过将流量分成控制组 (A) 和测试组 (B)，向他们展示页面的不同版本，来评估网站更改的效果。此实验框架的架构如下所示

在此框架中，ClickHouse 承担了进行统计分析的重任。对于每个正在进行的实验，ClickHouse 都要处理数亿行数据，以计算平均值、标准差、异常值校正因子等等。由于 ClickHouse 针对此进行了优化，因此我们的数据科学家几乎不需要在索引或数据类型上进行任何优化，可以专注于构建实际解决方案。尤其是数组函数在构建统计分析方面非常有用，因为它消除了用户暴露于多个实验时复杂的簿记工作。这使我们能够在几个月内开发框架，并让第一个实验投入使用。这使 DeepL 能够快速迭代前端或算法后端更改，并促成了这些领域的文化转变。

并非每个使用 DeepL 的人都需要所有功能，并非每个使用 DeepL 的人都知道所有功能。为了解决这个问题，我们成立了一个团队来对网站进行个性化定制。例如，如果我们认为某些功能对用户有用，我们会向他们提示这些功能。要做到这一点，我们需要三件事