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

本文字数：3326；估计阅读时间：9 分钟

审校：庄晓东（魏庄）

本文在公众号【ClickHouseInc】首发

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

Schema-less技术的兴起和衰落

在2010年代初期，Python 和 Javascript 这样的动态类型语言，以及 MongoDB 和 Elasticsearch 这样的 NoSQL 数据库，标志着远离严格、预先定义的模式规划的趋势。所有这些技术都采用更简洁的语法和更大的灵活性，承诺了更快的开发周期和更容易的原型设计，使它们成为初创公司和追求快速市场进入的新项目的首选语言。

然而，随着项目和组织规模的增长，这些技术的初始优势开始显露出重要的折衷。缺乏模式强制执行导致数据的不一致性，使得在应用程序发展过程中更难确保数据质量和完整性。而严格类型约束的缺失和无模式型数据库的灵活性，使得大型代码库的调试和维护变得愈发困难。

对关系型存储技术（如 ClickHouse）日益增长的兴趣，标志着我们行业在数据管理方面的细微变化。虽然现代数据系统需要处理各种各样的数据集，有时需要采取非结构化的方法，但人们对于强类型、结构化数据处理方法所带来的效率和组织性，也在不断增加。

管理模式（Schema）仍然是一种挑战

NoSQL 运动的一个推动因素是，许多开发人员希望尽一切可能避免管理数据库模式的困扰。模式更改，也称为迁移，需要技术专业知识来安全有效地完成。现代数据库提供了一种有限的、强制性的方式来更改模式，称为 DDL 语句。

如果我们不是完全放弃模式及其好处，而是使管理它们成为一种无缝的过程，而不需要任何特殊的努力，会怎样呢？管理数据库模式无疑需要技术专业知识，但这不是一个无尽复杂的挑战。因此，可以创建自动化工具来简化非专家的任务。

数据库 Schema-as-Code

近年来，随着云资源管理方面的巨大进步，一种名为基础设施即代码（IaC）的方法的出现，管理数据库模式的一种新方法逐渐崭露头角。这种方法被称为“数据库模式即代码-Database Schema-as-Code”，由 Atlas 和 Skeema 等项目代表，旨在通过为工程师提供具有声明性 API 的工具，极大地简化模式管理。

声明性 API 的工作原理是通过向工具提供期望系统达到的状态，让工具自行分析当前的数据库信息模式，并为用户自动生成迁移计划，以使数据库与期望状态保持一致。

自动化迁移规划并不是一个新概念。应用程序开发框架和 ORM（对象关系映射）如 Django 多年来已经提供了类似的功能。但是，ORM 层面的自动化迁移规划仅限于特定的上下文，并不能适用于所有堆栈。此外，ORM 更多关注于数据库的基本功能，如表、列、外键和索引，并未提供管理视图、物化视图、存储过程等高级对象的方法。

它是如何运作的

让我们实际了解一下数据库模式即代码和声明式迁移是如何运作的。为了演示，我们将使用 Atlas，这是一个开源的数据库模式即代码工具。想要了解更多并开始使用，请查阅 Atlas 文档获取入门和安装说明。

在进行演示之前，我们需要先运行一个本地空的 ClickHouse 实例，使用 Docker 即可轻松完成。

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://localhost:9000/demo" \
--to file://schema.sql \
--dev-url "docker://clickhouse/23.11/demo"

这会告诉 Atlas，我们想要将 schema.sql 文件中定义的模式应用到 localhost:9000/demo 的 ClickHouse 数据库上。

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

如果计划看起来正确，我们就点击“应用”将更改应用到数据库中。

成功运行我们计划的迁移后，我们可以再次运行 schema apply 命令，以确保数据库处于所需的状态。

atlas schema apply \
-u "clickhouse://localhost: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 等数据库架构即代码工具作为解决方案出现，旨在简化和优化架构操作，弥合了开发效率与结构化数据完整性需求之间的差距。

在本文中，我们展示了 Atlas 的部分功能，这远非是一份全面的指南。针对 ClickHouse 用户的更完整的“Atlas 入门指南”可在 Atlas 文档网站上找到。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com

​​联系我们

手机号：13910395701

邮箱：Tracy.Wang@clickhouse.com

满足您所有的在线分析列式数据库管理需求