ClickHouse 内部数据仓库构建之路：一年回顾

一年前，我的同事 Dmitry Pavlov 描述了我们如何使用 ClickHouse Cloud 构建 ClickHouse 的内部数据仓库，昵称为“DWH”。该 DWH 通过收集来自各种源系统的数据，根据数据模型对其进行处理，并提供对数据的访问，为 ClickHouse, Inc. 提供内部业务分析和报告。最初的博文涵盖了构建 DWH 的多个方面，例如使用反规范化的数据集市、安全功能的实现、底层基础设施的管理等等。

然而，随着 ClickHouse 的发展，其基于 ClickHouse Cloud 的 DWH 也随之发展。在这篇博文中，我将分享过去一年 DWH 如何演变的更新，以支持更多样化的用户、数据源和访问点。特别是，我们继续使用 ClickHouse 并融入 dbt 作为堆栈中的两个主要组件，使 DWH 能够支持更多的实时数据处理到常规批处理报告中，这是其他传统数据仓库历来缺乏的功能。因此，我们能够根据我们的数据做出更好的决策。

数据仓库是一个集中式存储库，用于存储从组织内不同来源收集的数据，以支持决策制定，通常是业务决策。以下是我们的 DWH 架构概述。

目前，我们配置了 19 个原始数据源，具有每小时或每天的插入作业。每天有大约 60 亿行和 50 TB 的未压缩数据写入 DWH。然后 ClickHouse 压缩并存储这些数据。目前，我们存储了过去两年收集的 470 TB 数据（压缩后），在过去 30 天内增加了 23%。在给定的一周内，我们通常会看到约 70 位唯一用户生成至少一个 SELECT 查询。

DWH 是我们组织中业务关键的系统，因为包括领导层、产品、工程、营销、销售和财务在内的各个业务部门都依赖 DWH 获取数据。此外，DWH 预生产环境已被用作金丝雀，用于在 ClickHouse Cloud 中进行更广泛的升级之前测试开源 ClickHouse 版本。

我们 DWH 的第一个迭代版本是一个从少量业务系统导入数据的工具，数据量相对较小。导入这些原始数据后，对其进行处理以创建批处理报告，如“试用次数”或“转化率”，这些是数据仓库的基础。批处理报告主要在 Airflow 中配置，我们根本没有使用 dbt。然而，随着我们添加数据源、定义更复杂的业务指标以及为越来越多的内部利益相关者提供服务，这种方法无法扩展。dbt 是数据工程师和分析师用来构建数据管道的开源工具，允许团队编写和迭代用于转换数据的模块化 SQL 代码。将 dbt 引入堆栈有所帮助，因为它将与批处理报告相关的转换逻辑集中在一个地方。

例如，当我们添加新的数据源时，dbt 允许我们使用时间函数轻松连接在不同时间提供的数据，并在准备就绪时触发后续流程。例如，考虑来自不同来源的数据在不同时间插入的情况，例如晚上 7:26 和晚上 10:01，即使用于 JOIN 数据的逻辑时间戳是一个小时的增量，例如晚上 7:00。这种逻辑可能是高度自定义的，并且会根据业务需求而变化。当有一个像 dbt 这样的工具来跟踪依赖关系时，编码这种逻辑与 19 个不同的数据源要容易得多，dbt 还会自动生成谱系图作为文档。

此外，我们定义的指标变得更加复杂。跨日期范围的简单 count() 和 sum() 让位于窗口函数和数据差异，这些窗口函数和数据差异根据存储在外部表中的条件进行筛选。dbt 与 ClickHouse 的 SQL 方言相结合，是管理这种日益增长的复杂性的关键，因为 SQL 成为我们编码这种业务逻辑的方式。dbt 成为在 DWH 中报告批处理业务指标的更可扩展方式的基础。

定义复杂业务指标作为批处理报告流程的一部分的能力是企业数据仓库的基本要求。ClickHouse 以其在 PB 级数据集上的性能而闻名，可以轻松处理我们投入的数据。然而，我们的 DWH 真正擅长的是处理新的和独特的实时数据格式，这些格式不符合严格的模式或关系（对这些格式的支持正在不断改进）。通常，这些数据源的数据量也更大。

例如，在我们的 DWH 中，每天约有 40 亿行插入到仅一个表中 - 整个表有近万亿行。再举一个例子，我们从 Google Analytics 导入事件，Google Analytics 将事件参数存储为嵌套数组，这些数组表示 clickhouse.com 上的网站活动。同样，来自我们的 NoSQL 控制平面数据库的卸载类似于具有灵活模式的嵌套 JSON 结构。

在我们的基础批处理报告到位后，我们开始在我们的报告中配置越来越多的实时数据源。我们的用户反馈说，他们发现这种数据非常有价值且更直观，即使数据结构化程度较低，并且在运行查询时需要进行一些轻微的处理（例如，从 JSON 列中提取字段）。我们的营销团队能够更好地了解我们网站上哪些页面最受欢迎。我们的支持工程师能够通过深入研究客户最近云活动的日志来诊断客户查询的问题。我们的产品团队能够定义更自定义的逻辑来跟踪转化事件。

在 DWH 中，我们以原始格式（当我们导入时）以及转换后的状态（如实时事件的聚合）公开了这些实时数据。ClickHouse 丰富的函数库和支持的数据格式使得以原始格式探索实时数据非常容易，这意味着用户可以使用 SQL 客户端执行即席分析，而无需数据工程师的帮助。创建实时数据的聚合也是可能的 - 我们使用 dbt 在实时数据到达 DWH 时定义聚合，然后将这些聚合存储在单独的表中。我们使用 dbt 是因为我们已经在其他地方使用 dbt，因此更容易在现有工具中集中化，但这些聚合也可以在 ClickHouse 中使用 物化视图等功能进行原生配置。然后将这些聚合与现有报告连接起来，以跟踪诸如“查询失败的客户数量”之类的指标。

这种设置使我们能够为实时数据配置批处理报告风格的管道，同时保留底层记录，以防需要更深入的调查。在一个环境中，ClickHouse Cloud + dbt 让我们的用户可以将批处理报告与实时数据流结合起来。

在 DWH 的第一个迭代版本中，我们配置了 Apache Superset 作为用户访问数据的 BI 工具。Superset 在一个部署中提供了许多关键功能，如仪表板、SQL 客户端、警报和用户管理，这对维护 DWH 的团队很有吸引力。而且，它是开源软件。然而，它也有其局限性。即，我们发现 Superset 的 SQL 客户端存在错误，这对用户体验产生了非常实际的影响。

为了解决这个问题，我们使用 ClickHouse Cloud 的原生 SQL 控制台打开了对 DWH 的访问。SQL 控制台对于用户编写即席 SQL 查询以及探索各种数据库表和视图要好得多。我们使用 ClickHouse Cloud API 来管理用户对敏感数据的访问，并使用 Google Groups 将角色分配给用户。DWH 的几位用户分享了使用 SQL 控制台比 Superset 的原生 SQL 客户端体验更好的感受。

对于超出编写即席查询的更专业用例，我们配置了与 Growthbook 的连接，作为使用我们 DWH 中的数据运行 A/B 测试的一种方式。Growthbook 和 ClickHouse Cloud 之间的连接只需几分钟即可设置完成，并为我们提供了一个开箱即用的工具来分析 A/B 测试的结果（这些结果是对 DWH 的 SELECT 查询）。Growthbook 直接查询 DWH ClickHouse Cloud 服务，这意味着使用非常原始的日志级别数据运行实验非常简单。

最后，我们设置了一个从 ClickHouse Cloud 到 Salesforce 的数据导出作业，以便我们的销售团队可以直接在我们的 CRM Salesforce 中使用来自 DWH 的数据。这种连接设置起来有点棘手，因为我们的 Salesforce 部署不支持来自静态 IP 地址的查询，这种限制会使连接不太安全。最终，我们最终将数据从 DWH 推送到 S3 存储桶中，然后让 Salesforce 查询这个 S3 存储桶。

展望未来，我们很高兴通过配置更多的数据源和引入更多的用户来继续扩展 DWH。为了确保 DWH 可扩展，我们希望将工作负载分解为独立可扩展的计算组，我们相信这将带来性能改进和成本节约。

当 DWH 首次创建时，我们只有一个“每小时加载 DAG”查询，这是一个在 Airflow 中调度的 ETL 作业，负责将所有新数据合并到 DWH 中。之所以选择这种架构，是因为我们的数据源数量有限，数据模型很简单，仅包含两个实体。然而，我们很快意识到，随着我们添加更多的数据源和数据模型，这种方法是不可扩展的：插入作业执行时间过长，并且由于不同数据模型之间的依赖关系，仅仅一个错误就会危及所有数据的插入。在引入 dbt 后，我们将这项作业重构为九个不同的流程，并注意到服务可靠性的提高。这些作业中的大多数仍然每小时运行一次，这意味着我们的 ClickHouse Cloud 服务必须 24x7 全天候运行以支持新数据的插入。

我们对即将推出的 ClickHouse Cloud 功能 计算-存储分离感到兴奋。此功能使我们可以将 DWH 的计算资源分离为多个服务，每个服务都可以根据需要独立扩展或缩减。这意味着我们可以为我们的 BI 工具提供只读服务，为关键 ETL 作业提供 24x7 全天候读写服务，并为不太关键的 ETL 作业提供第二个读写服务，在这些作业中，数据只需要每天刷新一次。然后，第二个读写服务可以在不活动时缩减，从而节省大量成本。通过这种方式，我们看到了分散计算资源并使不同的计算组彼此独立工作的潜力。

在人工智能时代，我也很高兴看到我们如何将人工智能功能融入到我们的 DWH 中。ClickHouse Cloud 已经支持 AI 查询构建器，该构建器可以帮助用户编写简单的 SQL 查询。然而，从长远来看，我很高兴看到 AI 业务分析师的前景，它可以帮助不熟悉 SQL 的 DWH 用户。此外，许多 DWH 用户目前查询 DWH 以编写每周/每月/每季度报告，我希望将另一个流程交给 AI 来完成，方法是使用现有的报告和查询来提供上下文。

在 ClickHouse，我们每周都以领导层会议开始，以审查和讨论公司最重要的指标。其中许多指标直接从 DWH 报告。随着我们的组织规模的扩大以及 DWH 的发展，我意识到数据仓库除了显示漂亮的仪表板和生成报告之外，还发挥着重要的作用；数据仓库是复杂而强大的机器，它们通过使整个组织的人员与单一的事实来源保持一致来促进讨论并促进行动。它们允许工程师、营销人员、销售人员、产品经理和高管使用相同的信息并据此做出决策。对于我们的数据仓库，ClickHouse 通过轻松地使用实时数据丰富批处理报告，扩展了可查询数据的范围。