用 Apache Doris 替换 Apache Hive、Elasticsearch 和 PostgreSQL

简单是最好的策略。 数据服务公司如何构建数据仓库？我曾担任一家平台的实时计算工程师，该平台旨在允许用户搜索公司的业务数据、财务和法律详细信息。已采集300多个维度、3亿+实体信息。我和我的同事的职责是确保这些数据的实时更新，以便我们能够为我们的注册用户提供最新的信息。这就是我们数据仓库面向客户的功能。除此之外，它还需要支持我们内部营销和运营团队的临时查询和用户细分，这是随着我们业务的增长而出现的新需求。

我们的旧数据仓库由当时最流行的组件组成，包括 Apache Hive、MySQL、Elasticsearch 和 PostgreSQL。它们支持我们数据仓库的数据计算和数据存储层：

• 数据计算：Apache Hive 作为计算引擎。
• 数据存储：MySQL 为 DataBank、Tableau 和我们面向客户的应用程序提供数据。Elasticsearch 和 PostgreSQL 为我们的 DMP 用户细分系统服务：前者存储用户分析数据，后者存储用户组数据包。

可以想象，长而复杂的数据管道维护成本高，并且不利于开发效率。此外，它们无法进行即席查询。因此，作为数据仓库的升级，我们用 Apache Doris（一个基于 MPP 的开源分析数据库）替换了大部分组件。

数据流

这是我们数据仓库的侧视图，从中可以看到数据是如何流动的。

首先，来自 MySQL 的二进制日志将通过 Canal 摄取到 Kafka，而用户活动日志将通过 Apache Flume 传输到 Kafka。在 Kafka 中，数据将被清理并组织成平面表，随后将其转换为聚合表。然后，数据将从 Kafka 传递到 Apache Doris，后者作为存储和计算引擎。

Apache Doris 中针对不同的场景采用不同的数据模型：来自 MySQL 的数据将被排列在Unique 模型中，日志数据将被放入Duplicate 模型中，而 DWS 层的数据将被合并在 Aggregate 模型中。

这就是 Apache Doris 在我们的数据仓库中取代 Hive、Elasticsearch 和 PostgreSQL 角色的方式。这样的改造为我们节省了大量的开发和维护的精力。它还使临时查询成为可能，并且我们的用户细分更加高效。

即席查询

之前：每次提出新的请求时，我们都会在Hive中开发和测试数据模型，并在 MySQL 中编写调度任务，以便我们面向客户的应用平台可以从 MySQL 中读取结果。这是一个复杂的过程，需要花费大量的时间和开发工作。

之后：由于 Apache Doris 拥有所有的明细数据，因此每当面临新的请求时，它可以简单地拉取元数据并配置查询条件。然后就可以进行临时查询了。简而言之，只需要低代码配置即可响应新请求。

用户细分

之前：基于元数据创建用户分段任务后，相关用户ID 会写入 PostgreSQL 配置文件列表和 MySQL 任务列表中。同时，Elasticsearch 会根据任务条件执行查询；结果产生后，会更新任务列表中的状态，并将用户组位图包写入PostgreSQL。（ PostgreSQL 插件可以计算位图的交集、并集、差集。）然后 PostgreSQL 会为下游操作平台提供用户组数据包。

Elasticsearch 和 PostgreSQL 中的表不可重用，使得该架构成本效益低下。另外，在执行新类型的查询之前，我们必须预先定义用户标签。这减慢了事情的进展。

之后：用户ID 只会写入 MySQL 任务列表。对于首次分段，Apache Doris 将根据任务条件执行即席查询。在后续的分段任务中，Apache Doris 将进行微批量滚动并计算与之前生成的用户组数据包相比的差异集，并将任何更新通知下游平台。（这是通过 Apache Doris 中的位图函数实现的。）

在这个以Doris为中心的用户细分过程中，我们不需要预先定义新的标签。相反，标签可以根据任务条件自动生成。处理管道具有灵活性，可以使我们基于用户组的 A/B 测试变得更加容易。另外，由于明细数据和用户组数据包都在 Apache Doris 中，我们不必关心多个组件之间的读写复杂性。

将用户细分速度提高 70% 的技巧

出于规避风险的原因，user_id 许多公司选择随机生成，但这会导致用户组数据包中的用户ID稀疏且不连续。在用户细分中使用这些 ID，我们必须忍受很长的等待时间来生成位图。

为了解决这个问题，我们为这些用户 ID 创建了连续且密集的映射。通过这种方式，我们将用户细分延迟减少了 70%。

例子

步骤1：创建用户ID映射表：

我们对用户ID 映射表采用 Unique 模型，其中用户ID是唯一键。映射的连续 ID 通常从1开始并且严格递增。

步骤2：创建用户组表：

我们对用户组表采用聚合模型，其中用户标签作为聚合键。

假设我们需要选出 ID 在0到2000000之间的用户。

以下代码段分别使用不连续( tyc_user_id) 和连续 ( tyc_user_id_continuous) 用户 ID 进行用户分段。他们的响应时间差距很大：

• 非连续用户 ID：1843ms 连续用户 ID：543ms

结论

我们在 Apache Doris 中有 2 个集群，可容纳数十个 TB 的数据，每天有近 10 亿新行流入。随着数据量的增加，我们曾经目睹数据摄取速度急剧下降。但在使用 Apache Doris 升级我们的数据仓库后，我们的数据写入效率提高了 75%。此外，在结果集小于500万的用户细分中，它能够在毫秒内响应。最重要的是，我们的数据仓库对于开发人员和维护人员来说更加简单和友好。

最后，我想与大家分享一些我们第一次与 Apache Doris 社区交谈时最感兴趣的事情：

• Apache Doris 支持数据摄取事务，因此可以确保数据只写入一次。
• 它与数据生态系统集成良好，可以与大多数数据源和数据格式平滑对接。
• 它允许我们使用命令行界面实现集群的弹性伸缩。
• 它在连接查询方面优于 ClickHouse 。

原文作者：ApacheDoris