声明:本人仅仅负责数据工程中的数仓部分。我的主要业务包括:
我的次要业务包括:
我上个月开始严肃的用 Cursor 来帮助自己自动化一些开发。以下是我的经验和感触。因为我的经验并不丰富,所以估计以后会有更多的想法。
首先是判断哪些开发比较适合用 AI 自动化。一个比较简单、容易重复的开发,是给现有的 silver 表增加新的列。我们有很多 silver 表是从 s3/dynamoDB 里通过串流数据程序,以 JSON Blob 的方式导入到数据库中,然后再做一些简单的变换而生成的。这部分开发非常简单,但是频率很高,让我烦不胜烦,所以决定第一个拿它开刀。
我尝试了两种办法:
方法一,将所有变换规则都写在子目录的 cursor rules 里,再把 git flow 也写清楚。使用的时候就直接在 chat 里和 AI 对话,让它引用这两个规则,最后本人审核完毕之后,直接修改 dbt 的 models.yml ,最后提交 PR 。整体步骤大概是:
我测试了一段时间,发现方法一还是有些问题。一个是 Cursor 的数据库插件时好时坏,还有一个是 Atlassian 的插件突然就不好用了,我也不确定是什么问题,但是最重要的是,这个方法还是没有解放我自己,我需要和 AI 进行对话。所以我后来决定自己写程序自动化这个流程。
方法二(还在制作过程中),将这部分 silver 表的元信息加入到 models.yml 中,包括列名、列类型等等。然后在 CI/CD 中增加了一个 Python 程序,一旦检测到这部分模型发生变动,那么自动将 models.yml 中的相关数据模型重新“编译”,然后用 dbt compile 和 dbt run --target dev 进行测试。这个方法的好处是,下游组想要新的列,直接修改 models.yml 提交 PR 即可,我只需要审核即可。我使用 AI 来帮我确认 yml 文件的格式,以及帮我来写 Python 程序。因为我比较喜欢写这种程序,所以大部分代码还是自己写,而不是让 AI 生成。
我同时尝试了一下让 AI 帮我从头到尾生成一个全新的数据模型。首先我写了一份详细的 Markdown 表格,里头有对业务数据的简介、下游组为什么要这个数据,每个数据流的元数据(数据流的表的名字,PK 列是哪些?怎么样避免全表扫描?等等),以及下游主所需要的每张表的特点(比如说,subscription 表是需要将数据流 A 和数据流 N 根据某几个列 JOIN 起来,最后生成的表格的每一行是一个 subscription )。接下来我让 Cursor 直接根据这份清单,写查询从上游的 bronze 数据流的表生成我所需要的 silver 表。我觉得 AI 的表现还是可以的,不是说所有的查询都能一次性完成,但是至少能省我很多力气,总体来说就是把 boilerplate 给自动化了。对于一些比较简单的数据模型,只有 3-4 张表,又不需要非常复杂的变换的那种,基本上可以一次性生成数据模型和所有文档,就是还得自己审查一下。
这个月中,我还用 AI 帮忙生成 JIRA 工单、撰写文档、数据辞典等等。我感觉这方面它的确是个很好的助手。接下来我想要尝试把 AI 接入到 On-Call 中。我们 On-Call 经常会有一些不重要但是必须要处理的问题,而且每次处理方法完全相同。我决定让 AI 筛选一下 On-Call 的警报,如果是这类警报,那就完全交给它,最后搞完之后,重新跑一次警报查询,确认一下,就行了。如果确认不了,或者是其他警报,那么就什么也不做,还是交给我们。但是细细想来,这里其实很多细节问题,还不确定能不能比较好的自动化。
总体来说,我认为 AI 帮助很大。但是也需要接入到内部系统中,写好指示,才能真正发挥作用。我感觉 AI 对各个系统的接合可能是个难题,如果在撰写系统的时候就直接把 AI 考虑进去,那就最好了。只好有待将来继续挖掘了。AI 如果了解数据库的话,就可以回答“我想要这个数据,从哪里拿?“这个下游组经常问我们的问题,也能帮我们解除掉一点压力。
我的感觉,如果进一步整合好的话,AI 起码能够让我的效率增加 50%以上。
1
webszy 16 小时 37 分钟前 严肃的用 Cursor ?我感觉你用 ai 最多的地方就是写了这个帖子
|
2
yingqi1 15 小时 28 分钟前 分享一下 DBT 官方的 Skill: https://github.com/dbt-labs/dbt-agent-skills
|
3
levelworm OP |