什么是跨脚本攻击（XSS）

一、引

在前面的几篇文章中，我们从 dbt core 聊到了 dbt 项目工程化，我相信前几篇文章足够各位数据开发师从零快速入门 dbt 开发，那么到现在我们更迫切需要解决的是如何让数据更新做到定时化，毕竟作为开发我们肯定没有经历每天定点去手动运行 dbt 命令，那么今天我们将带领大家快速上手 dbt cloud，通过云平台的环境以及定时任务的配置做到全自动化，通过本文你将了解到如下几个知识点：

• dbt cloud 集成
• dbt cloud IDE
• dbt could 环境配置
• dbt could 定时器
• dbt could 通知集成

需要注意的是，了解 dbt cloud 的前提我还是建议对于 dbt core 需要有一定认知，否则对于本文中的一些特定配置你可能不是特别理解，如果有时间建议阅读之前的文章，那么让我们直接开始。

二、什么是 dbt cloud

我们在第一篇文章介绍 dbt core 时顺带提了一句 dbt cloud，简单来理解，dbt core 是 dbt 的基础，它提供你本地 dbt 项目开发的一切，比如你要使用的 dbt 命令，构建过程中 sql 的编译，对于数据平台的链接通信以及抹平不同平台差异等等，而这一切仅限于你在本地项目写 model 以及构建你需要的数据模型。

而 dbt cloud 很重要的一点是能在云端集成你本地的 dbt 项目，它能做到与你本地项目的互联，你能在云平台提供的浏览器版本编辑器中切分支写代码以及测试 model，也能与你托管的仓库（比如 GitHub）集成，通过自动化任务配置，做到定时代码自动更新以及自动化更新你的 model，是不是非常棒。

更重要的是，dbt cloud 免费的开发版本虽然只有一个席位，但开发版本提供的权益完全满足你对于自动化的述求，所以说 dbt cloud 一定会成为数据更新中非常重要的一环。

三、dbt cloud 集成

3.1 新建 dbt cloud 项目

dbt cloud 集成主要分为两个部分，第一是获得数据平台（比如 bigquery）的授权，试想一下，当我们在 dbt cloud 上配置了定时器任务，到点后 dbt 像一个虚拟的开发一样帮我们更新 dbt modle 以及把 model 结果写入目标数据平台，很明显我们也需要让这个虚拟开发获得跟我们相同的数据访问 & 写入权限，也就是 GCP 。第二部分是集成 GitHub（也可以是 gitlab） 上你的 dbt 项目，这点我们后面再说。

不知道你是否还记得，我在 dbt core 第一篇文章中介绍了如何让本地项目获得访问远端数据库权限时，介绍了一种使用本地 JSON 文件授权的办法，如果你之前也是通过这种方式，那么在等会的授权集成中你可以直接上传这份 JSON，如果你之前没有，以 bigquery 为例，建议先生成一份这样的权限文件，bigquery 授权可跳转 Create credentials。

做好这些准备，你需要在 dbt 网站创建一个账号，然后来到新建项目，如下，在这里你可以先输入你喜欢的项目名称，以及需要链接的数据平台，没关系，这个配置在后续后可以编辑。

最终的部分来了，让我们聚焦 Configure your environment，需要注意的是这里默认配置的是开发环境，而 dbt cloud 默认只支持拥有一个开发环境，在后续我会介绍如何创建生产环境。

上图中的 Connection name 我们保持默认就好，然后可以看到一个上传授权 JSON 文件的按钮，当你点击上传，你会发现 setting 部分所有的输入会自动填充，所以点击上传前文提到的授权文件即可。

Optional Settings是可选设置，这里我们直接跳过，来到底部 Development credentials，这里非常重要，让我详细说明一下。

还记得之前文章中对于 dbt 工程化，我们特别指出了 dbt 支持 dataset + schema 配置做到不同开发环境将数据写入到不同数据集的目的，如果你希望 dbt cloud 也达到相同的效果，在这里你需要将 dataset 配置成与 dbt 项目中 profiles 中相同的字段。

OK，现在让我们点击 test connection 按钮，如果显示链接成功那么恭喜你最重要的一步配置已经完成了，你也拥有了属于自己的 dbt cloud 项目。

3.2 关联 GitHub

dbt cloud 虽然创建好了，但此时你并未将其与你的 dbt 项目关联起来，毕竟我们做定时任务本质还是希望帮我们运行自己的 dbt 项目。让我们点击 dbt 网站右上角的设置按钮，找到 Linked accounts，可以看到 dbt cloud 支持 GitHub gitlab 仓库托管项目集成，让我们点击 GitHub link 获取 GitHub 授权

之后展开集成，点击配置并选择你需要关联的项目点击保存即可。

那么到这里，我们对于 dbt cloud 集成相关的工作已经做好了，接下来让我们介绍 dbt cloud IDE 。

四 dbt cloud IDE

点击 dbt cloud 左上角的 cloud IDE 即可进入云平台编辑器，在这里你可以看到跟你本地编辑器完全相同的界面。

IDE 主要分为四个区域，这里我通过数字编号简单解释：

1. 分支管理区域：由于我们集成了 GitHub，因此在 IDE 也能通过 pull 拉取远端代码，以及分支创建等常见的分支管理策略。
2. 代码目录区域：这里的代码目录结构将与你本地项目完全一致，你也能在这直接新建目录以及代码文件，在修改完成通过 push 到GitHub仓库，再反向更新你本地的项目。
3. 编辑区域：这里就是标准的代码编辑区域，你能在 IDE 上与你本地编辑器一样做需求开发。
4. cloud IDE 工具区域：在这里你能看到每个 model 的可视化依赖关系，以及 model 运行以及结果测试。

由于 IDE 使用比较简单，而我本人还是习惯在本地做项目开发，更多是将 dbt cloud 作为自动化工具，因此 IDE 部分就不过多介绍，详细文档可见 dbt cloud IDE 部分。

那么接下来让我们聚焦于自动化配置部分，让我们先从环境配置开始。

五、dbt cloud 环境配置

为什么要介绍环境配置呢？因为 dbt cloud 的自动化任务的载体就是环境，后续所有的自动化任务都是在某个环境中创建，毕竟任务总得区分环境，以及知道要基于哪个分支拉取代码等等。

5.1 关于 dev 环境

前文已经提到，dbt cloud 默认已经为你创建了一个 dev 环境，而且你至多只能拥有这一个 dev 环境，如果你喜欢在 cloud IDE 做项目开发，那么 dev 环境你还是需要做少许配置。


让我们进入 dev 环境配置，在这里你可以设置默认的项目分支，因为我们提到 IDE 也能自动同步 GitHub 代码，那么这里的默认分支就是告诉 IDE 默认拉取哪个分支的代码，其次让我们把目光看到 profile page，点击此配置，你可以看到在我们创建第一个 dbt cloud 项目时关于继承 bigquery 的相关配置，所以前文也说， 如果你需要后续再修改那么可以在这里进行修改，比如你希望修改 dev 模式下 Dataset 的字段。

5.2 关于 production 环境

现在，让我们直接创建属于自己的 production 环境，由于与 dev 配置选项大体相同，这里我就不再截图展示了，你需要将 Custom branch 设置为你希望的 GitHub 主分支，比如你是 main 就设置为 mian，是 master 就设置 master，后面当自动化脚本运行时，所做的第一件事就是基于你在这配置的分支名做代码领取，再基于这个分支的 model 做更新。

其次，关于 Dataset 我们也介绍了，如果你有做项目工程化配置需要做 model 写入的数据集区分，这里你需要将 Dataset 设置成与你 profiles 中完全相同的字段。

六、dbt cloud jobs

dbt cloud jobs 支持两种任务，第一种是定时部署任务，比如你希望每天的什么时间段帮你执行；第二种就是 PR 任务，比如你希望 GitHub 仓库产生新的 PR 合并时自动更新 model 时，这里我们介绍定时任务。

点击新建选择部署任务，既可以看到任务创建界面，这里解释下关键的配置：

• Job name：任务名称，取一个对任务具有解释意义的名称会更好

• Description：可选，任务的描述。

• Environment：任务执行所对应的环境，需要注意的是我们无法为 dev 环境配置任务，这里选择刚才新建的生产环境。

• Commands：任务被执行时你希望执行的 dbt 命令，比如我就希望更新整个项目，那在这里定义 dbt run即可，如果你需要执行多条命令，这里也支持新建多条命令。

• schedule：定时器，它决定了任务执行的时机，比如我希望的是每天的某个时间，或者每个月的某一天，这里可以选择 cron schedule，需要注意的是这里配置的时区均为 UTC 时区。比如我希望 UTC 时区的每天0点0分执行，那么配置 0 0 * * *即可；再比如我希望任务在每个月的一号的 UTC 2点执行，那么配置 0 2 1 * *即可，大致规则如下：

  • 0 * * * *: Every hour, at minute 0
  • */5 * * * *: Every 5 minutes
  • 5 4 * * *: At exactly 4:05 AM UTC
  • 30 */4 * * *: At minute 30 past every 4th hour (e.g. 4:30AM, 8:30AM, 12:30PM, etc., all UTC)
  • 0 0 */2 * *: At midnight UTC every other day
  • 0 0 * * 1: At midnight UTC every Monday.

  更详细的说明可见官网文档。

到这里，你就配置了属于自己的第一个自动化任务，是不是非常简单。

七、dbt cloud 通知

事实上，自动化任务会根据你的配置准时准点运行，但可能因为你项目的问题或者 model 编写问题导致执行失败，此时你一定希望自动化任务在运行之后给你发起一次通知，那么 dbt cloud 提供了邮件以及 slack 两种通知方式。

点击 dbt 网站右上角的设置中心，选择通知设置，我们可以先来到 Linked accounts 先为 slack 做授权，之后来到 Slack notifications，如下图：

在这里，你需要先选择需要通知的 slack 频道，然后在下方表格中为你配置的 jobs 的不同状态做选择，比如这里我勾选了我配置的三个任务的所有状态通知，后续只要任何一个任务运行成功，我所对应的频道就能收到执行结果的通知。

假设执行失败，你能通过通知的链接直接跳转到任务执行详情，查看执行过程中的所有信息，比如导致失败的错误信息等等。

而关于邮件通知由于比较简单，这里我就不过多介绍了，采用哪种通知方式看大家喜好。

那么到这里，dbt cloud 的介绍就全部完成了，其实 dbt cloud 的能力远不止如此，但如果要全部展开本文篇幅就过长了，而本文的初衷也只是希望带大家快速上手，先跑起来并在使用过程中为自己解疑答惑。而关于本文中内容若有疑问也欢迎留言，那么到这里本文结束。