使用 Atlas 管理您的 ClickHouse Schema-as-Code

今天，我们欢迎来自 ariga 的 Rotem Tamir，他维护着用于以代码方式管理数据库模式的开源核心工具 atlas。Rotem 深入探讨了细节，并展示了最近对 ClickHouse 支持的价值。

在 2010 年代初期，像 Python 和 Javascript 这样的动态类型语言以及像 MongoDB 和 Elasticsearch 这样的 NoSQL 数据库标志着偏离严格的前期模式规划的趋势。所有这些技术，以更简洁的语法和更大的灵活性，承诺更快的开发周期和更轻松的原型设计，使其成为面向快速进入市场的初创公司和新项目的首选语言。

然而，随着项目和组织规模和复杂性的增长，这些技术的最初优势开始显露出显著的权衡。缺乏模式强制导致数据不一致，随着应用程序的发展，这使得确保数据质量和完整性变得更加困难。缺乏严格的类型系统和无模式数据库的灵活性质使得调试和维护大型代码库变得越来越困难。

人们对 ClickHouse 等关系存储技术的兴趣日益浓厚，这表明我们行业对数据管理方法正在发生细微转变。虽然现代数据系统需要处理有时需要非结构化方法的各种数据集，但人们越来越认识到强类型、结构化数据处理方法带来的效率和组织性。

NoSQL 运动的驱动因素之一是，许多开发人员希望不惜一切代价避免管理数据库模式的痛苦。模式更改，也称为迁移，需要技术专长才能安全有效地完成。现代数据库提供了一种有限的、命令式的更改模式的方法，称为 DDL 语句。

如果我们不完全放弃模式及其优势，而是能够将模式管理变成一个无需任何特别努力的无缝过程呢？管理数据库模式无疑需要技术专长，但这不是一个无限复杂的问题。因此，可以创建自动化工具来简化非专家的任务。

近年来，随着云资源管理领域取得了巨大进步，采用了一种称为 基础设施即代码 的方法，一种管理数据库模式的新方法正在出现。这种方法被称为 "数据库 Schema-as-Code"，由 Atlas 和 Skeema 等项目体现，旨在通过为工程师提供一个具有_声明式_API 来与数据库交互的工具来极大地简化模式管理。

声明式 API 通过向工具提供系统的期望状态并让工具找出将系统与当前状态协调所需的运算来工作。在数据库模式管理的背景下，用户向工具提供他们希望数据库具有的模式，让工具检查当前数据库的信息模式，并自动为他们生成迁移计划。

自动迁移计划当然不是一个新概念。像 Django 这样的应用程序开发框架和 ORM 已经提供了类似的功能多年。在 ORM 级别自动执行迁移计划的问题是，它们只能在其特定上下文中使用，不能普遍应用于每个堆栈。此外，ORM 往往侧重于数据库功能的一个小子集，例如表、列、外键和索引，并且不提供管理更高级对象（例如视图、物化视图、存储过程等）的方法。

让我们看看数据库 Schema-as-Code 和声明式迁移在实践中是如何工作的。为了演示它，我们将使用 Atlas，一个开源核心数据库 schema-as-code 工具（F.D：我是其中一位创建者）。有关入门和安装说明，请访问 Atlas 文档。

作为此演示的先决条件，让我们使用 Docker 运行一个本地的空 ClickHouse 实例

docker run --rm -d --name atlas-demo -e CLICKHOUSE_DB=demo -p 9000:9000 clickhouse/clickhouse-server:latest

与更传统的方法相反，使用声明式迁移，我们总是从数据库的期望状态开始。让我们创建一个名为 schema.sql 的文件，内容如下

CREATE TABLE `users` (
   `id` UInt64,
   `name` String)
ENGINE = MergeTree
PRIMARY KEY (`id`)
ORDER BY `id`;

现在，我们可以使用 atlas schema apply 命令将此模式应用于目标数据库

atlas schema apply \
-u "clickhouse://127.0.0.1:9000/demo" \
--to file://schema.sql \
--dev-url "docker://clickhouse/23.11/demo"

这将告诉 Atlas 我们希望将 schema.sql 文件中定义的模式应用于 localhost:9000/demo 处的 ClickHouse 数据库（我们刚刚使用 Docker 在本地启动）。

Atlas 连接到目标数据库，检查其信息模式，计算当前状态和期望状态之间的差异，并提示我们批准迁移计划

-- Planned Changes:
-- Create "users" table
CREATE TABLE `users` (
  `id` UInt64,
  `name` String
) ENGINE = MergeTree
 PRIMARY KEY (`id`) SETTINGS index_granularity = 8192;
? Are you sure?:
  ▸ Apply
    Lint and edit
    Abort

该计划看起来不错，因此我们点击“应用”将更改应用到数据库。

在成功运行 Atlas 为我们规划的迁移后，我们可以重新运行 schema apply 命令以确保数据库处于其期望状态

atlas schema apply \
-u "clickhouse://127.0.0.1:9000/demo" \
--to file://schema.sql \
--dev-url "docker://clickhouse/23.11/demo"

Atlas 再次连接到我们的 ClickHouse 实例，检查它并计算差异，这次告诉我们

Schema is synced, no changes to be made

接下来，让我们对我们的期望状态进行一个小的更改，以表明声明式迁移适用于具有现有模式的实时数据库。让我们向 users 表添加一个新列 email_address。编辑 schema.sql 添加以下列

CREATE TABLE `users` (
    `id` UInt64,
    `name` String,
+    `email_address` String
)
 ENGINE = MergeTree
 PRIMARY KEY (`id`)
ORDER BY `id`;

接下来，让我们重新运行 schema apply 命令，看看 Atlas 如何为我们规划迁移

-- Planned Changes:
ALTER TABLE `users` ADD COLUMN `email_address` String;
? Are you sure?:
  ▸ Apply
    Lint and edit
    Abort

太棒了！Atlas 检测到现有表并规划了迁移以将缺少的列添加到目标数据库。让我们点击 应用 将我们的数据库带到期望状态。

2010 年代的趋势是无模式数据库，因为开发人员试图避免模式管理的复杂性，但这种转变随着系统规模的扩大导致了数据一致性和维护方面的挑战。从过去的挑战中吸取教训，科技行业现在表现出对关系技术的重新兴趣。

然而，开发人员仍然面临着过去模式管理中遇到的相同挑战。像 Atlas 这样的数据库 Schema-as-Code 工具作为一种解决方案出现，旨在简化和简化模式操作，弥合对开发效率的渴望与对结构化数据完整性的需求之间的差距。

本文展示了 Atlas 的部分功能，但这绝非一份完整的指南。您可以在 Atlas 文档网站 上找到更完整的“ClickHouse 用户 Atlas 入门指南”。