博客 / 用户故事

DeepL 与 ClickHouse 的旅程

Jannik Hoffjann & Till Westermann

2022年7月26日 - 6 分钟阅读

我们欢迎 DeepL 作为嘉宾来到我们的博客。继续阅读以了解 DeepL 如何使用 ClickHouse 作为其中心数据仓库。

在 DeepL，我们使用 ClickHouse 作为我们的中心数据仓库。如今，它服务于多种用例：从我们网站和应用程序的分析，到向所有人提供公司指标，以及技术监控。在这篇博文中，我们想告诉您我们与 ClickHouse 的旅程、我们是如何开始的以及我们构建了什么。

我们与 ClickHouse 的旅程始于 2020 年，当时我们希望以一种注重隐私的方式建立我们的分析能力。那时，我们评估了自托管解决方案的几种方案。Hadoop 世界被认为维护强度过高，并且需要花费太长时间才能设置。由于 ClickHouse 可以从 apt 存储库进行单二进制部署，因此非常容易和快速地设置 MVP（最小可行产品），以查看事情是否在我们这个规模上可行。我们从单节点设置开始，其中 ClickHouse 在 VM 内部运行，并且 hypervisor 甚至与其他几个服务共享。

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 亿行原始数据。

在构建了我们的数据基础之后，是时候继续在这个平台上构建更多东西了。

实验，也称为 AB 测试，是通过将流量分为对照组 (A) 和测试组 (B) 并向他们展示不同版本的页面来限定网站更改的技术。此实验框架的架构如下所示

在此框架中，ClickHouse 承担了统计分析的繁重工作。对于每个正在运行的实验，ClickHouse 都会处理数亿行数据，以计算平均值、标准差、离群值校正因子等等。由于 ClickHouse 针对此进行了优化，我们的数据科学家只需对索引或数据类型进行极少的优化，就可以专注于构建实际解决方案。特别是数组函数在构建统计分析方面非常有用，因为它消除了用户接触许多实验时的复杂簿记。这使我们能够在几个月内开发出该框架并进行首次实验。这使 DeepL 能够快速迭代前端或算法后端更改，并为这些领域的文化转变做出贡献。

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