Transcription
感谢大家今天参加我们的讨论。在整个讨论过程中，请随时在聊天或问答中提问。我们将在最后留出一些时间来回答收到的任何问题。
为了开始，芭芭拉，我给了高层概述，但请允许我重新介绍一下我自己。我叫艾米丽，是 Gloss Genius 的数据工程经理，我在这里的 CoRise 上教授分析工程与 DBT 课程。我住在马萨诸塞州波士顿。
琳赛，你想介绍一下你自己吗？
当然，是的，谢谢艾米丽。我是琳赛。我是一名新讲师，即将加入 CoRise。我将在七月教授高级 DBT。我目前是 Sakota 的数据主管，在分析行业工作了大约 12 年。在过去的几年里，我开始使用 DBT，所以非常兴奋今天能谈论这个话题。
是的，我非常兴奋我们能做这个。
所以，关于我们要谈论的内容，首先，我们只是简单地谈谈为什么选择 DBT，一些核心原则，然后琳赛将深入探讨规模化的一些挑战以及成功规模化 DBT 的技巧。然后，就像我说的，我们将留出最后大约 15 分钟的时间来回答任何问题。所以，再次，请随时在整个过程中提出问题。
开始谈论为什么选择 DBT。这是我今年某个时候或者也许是去年年底发布的图表，基本上显示了使用 DBT 的公司数量持续上升。所以，采用率肯定没有放缓的迹象。甚至还有很多工具不断推出，比如更原生的方式来处理 PBT。
与此同时，分析工程师的角色也在不断增长，并且随着人们发现这个角色，以及有更多的工具和课程来帮助培训人们从事这个领域，它正变得越来越成熟的职业道路。我前几天在 LinkedIn 上搜索了一下，当我只在“职位”部分搜索“分析工程师”时，有超过 84,000 条结果。所以，这绝对是存在的，并且对于那些对数据感兴趣的人来说，它正继续成为一条越来越受欢迎的职业道路。
通过 DBT 学到的那些相关的技能也真的很有价值，无论你走到哪里。所以，比如学习命令行、版本控制（Git 或 GitLab/GitHub）、如何考虑 QA 和测试、数据建模、如何以一种有用的方式记录事物，以便人们能够找到他们正在寻找的东西，所有这些都不会变得不那么重要。
然后，我想快速谈谈我们是如何走到这一步的。那种旧的 ETL 模式。很多公司，无论你在哪里，可能都有生产数据存储在 PostgreSQL 或 MySQL 中，但还有所有这些其他对你的公司很重要的其他数据源，比如 Facebook、Salesforce、HubSpot、iTunes 或 Apple App Store、Google，所有这些东西。事件数据非常重要，需要被整合到一个中心位置。
但在这种旧模式下，转换步骤发生在数据进入数据仓库之前。这确实会引起一些问题。我个人以前在一家公司经历过这种情况。第一，如果你想回填数据，改变一些转换逻辑，那肯定是一个更复杂的过程。通常，这不会落在数据团队身上，通常是其他工程组织，你需要提交一个工单。如果你想更改列名或更改某些逻辑。在进入仓库之前，在提取到转换到加载的步骤中，实际发生的情况的可见性也较低。所以，那些负责数据管道的人也负责数据应该如何被解释。而分析师是使用这些数据的人，并且更接近想要使用这些数据的业务利益相关者，他们对他们使用的数据以及数据如何被转换的控制更少。所以，很难理解数据如何进入数据仓库的“真相来源”以及一个字段的实际含义。
然后，进入这种新的 ELT 模式。这就是 DBT 发挥作用的地方。T 可以是任何东西，但在我们的例子中，我们使用 DBT 来进行转换阶段。在这种模式下，我们刚才谈到的所有源数据都会按原样从源加载到数据仓库。转换逻辑通常由数据团队中的分析工程师或分析师来处理。当然，这仍然存在问题。你仍然需要有流程和最佳实践来统一定义，确保事情不会再次失控，人们仍然知道字段的含义以及如何使用它们。所以，这是琳赛稍后将要谈论的内容，以及关于规模化我们的 DBT 项目的一些最佳实践技巧，这样我们就不会遇到这些问题。
可能在座的大多数人都知道 DBT 是什么，如果你参加了这个电话会议的话。但为了重申，或者也许如果你不太熟悉，DBT 真的只是一个用于编写和编译这些 SQL 查询的框架。有围绕开发、测试、文档和将这些数据模型部署到数据仓库的工具。我真的很喜欢 DBT Lab 的使命，所以我想把它放在这里。他们的使命是赋能数据从业者创建和传播组织知识，所以这确实是 DBT 正在构建的工具以及我们今天讨论的工具的整个使命和目的。DBT 的观点对这个使命非常重要。
我不会详细介绍所有这些领域，但只是快速地谈谈要点。首先，有一种新的现代分析团队。有需要了解如何摄取数据的角色。现在我们很多人都在使用非常强大的分析数据库。我们主要处理数据工具是 SQL 和 Python。然后我们还有这些非常棒的可视化工具，可以帮助我们的利益相关者和其他人可视化和使用我们为他们策划的数据。
然后，最后几点是，分析是协作性的。我们需要有效协作的方式。分析代码是一项资产，所以我们真的需要像对待资产一样对待它。最后，分析工作流程需要自动化。有很多流程是 DBT 帮助我们自动化的。DBT 的一个非常重要的领域是 DAG。也许当你刚开始的时候，你的 DAG 非常简单，易于遵循，你可以真正理解什么逻辑流入什么，并且事情在一个地方定义。如果事情失控，我们没有遵循正确的流程和实践，事情可能会有点失控，我们开始遇到我们最初试图解决的问题，即能够理解逻辑在哪里发生，确保它只在一个地方定义，每个人都引用相同的东西，这样人们就能得出相同的答案。随着我们的 DBT 项目的增长，我们真的需要非常谨慎地确保这种情况不会发生。
现在我将把它交给琳赛，她将谈谈如何确保我们的项目保持我们开始时的样子。
是的，谢谢艾米丽。是的，正如艾米丽提到的，当你开始一个 DBT 项目时，事情可能相当直接。所以，你可能只有几个模型，也许有几个人在贡献这个项目。但随着时间的推移，当你开始添加新的模型和新的数据源时，事情可能会很快变得非常紧张。所以，艾米丽在上一张幻灯片上展示的图片显示了事情可能变得多么复杂。这是我在我最后一家公司亲身经历过的。我们开始时大约有 200 个 DBT 模型，在我任职期间，我们扩展到了大约 400 到 450 个。我开始注意到一些模式正在发生。
所以，我们可以进入下一张幻灯片，艾米丽。我认为这现在正在 DBT 中发生。所以，很多长期使用 DBT 的团队正在达到这个规模化点。所以，虽然大多数初创团队可能有不到 100 个模型，但实际上有一些 DBT 项目现在可以看到，在某些情况下有超过 5000 个模型，这是一个非常大的项目。所以，这张图表是 DBT 在去年年初发布的，他们实际上看到大约 5% 的 DBT 安装量拥有超过 5000 个模型。当你的项目有 100 个模型和 5000 个模型时，你面临的问题非常不同。要从 100 个模型发展到 5000 多个模型，你必须经历很多相当大的挑战。
所以，我在我最后一家公司开始注意到这些事情，并且我开始注意到行业中也在讨论的模式。所以，如果我们进入下一张幻灯片。
我注意到的事情，以及我经常听到的事情，我认为艾米丽你提到你也处理过这些事情。当你开始向你的项目执行中添加更多项目、更多测试以及更多东西时，项目构建时间会开始变慢。当你开始时，只有几个模型，运行你的项目可能只需要几秒钟或几分钟。当你开始添加非常复杂的模型和越来越多的数据源时，项目构建时间真的会攀升。所以，在我最后一家公司，我看到了这一点。我认为当我开始时，一个 DBT 构建大约需要 14 分钟，然后在我任职期间，这个时间开始攀升到超过一个小时，有时高达一个半小时。
所以，会发生什么？所以，如果有人在开发中工作，或者如果他们需要在自己的开发环境中构建所有模型，这会大大减慢速度。所以，这会导致人们不以同样的方式测试事物，它只会让开发过程对代码库的贡献者来说不太愉快。然后，这会滚雪球般地导致其他问题。所以，这会进入你的持续集成检查，如果你正在做那些检查的话。在我以前的公司，我开始时并没有使用 slimci，这是一个将你的持续集成缩减到你只需要运行的模型，也就是你更改过的模型。每次我们需要重新运行某项内容时，我们都只是进行一次完整的构建。所以，你可以想象，每次有人想要代码检查或代码审查时，他们都必须等待一个小时左右，直到 CI 完成，然后它会告诉他们有一个错误，他们必须回到代码中修复错误。所以，这真的减慢了过程。从功能构思或请求到实际在生产中发布产品需要很长时间。
另一个大问题是数据质量。随着模型变得越来越复杂，并且事物之间有越来越多的依赖关系，当某个地方出现问题并且某项失败时，就很难理解要去哪里修复它。所以，当事情只有几个模型时可能很容易，但如果你开始有非常复杂的依赖关系，这会大大减慢速度。而且，我认为这也会导致一种“不敢触碰别人代码”的恐惧。如果某件事非常复杂，有人构建了一个非常复杂的模型，或者很多开发人员都为某个非常复杂的模型做出了贡献，那么进入并实际更改某件事可能会有点棘手。
然后，显然，这一切都会滚雪球般地导致成本增加。所以，如果你使用云数据仓库（如果你使用 DBT，你很可能就是这样），在大多数情况下，你不仅要为存储付费，还要为计算时间付费。所以，如果你的项目运行时间更长，你就要为此支付更多费用。然后，只是移动数据。所以，如果你有像 Fivetran 或 Stitch 或其他 ELT 工具来移动数据的工具，你添加到项目中的数据，如果你添加更多源，成本就会增加。所以，总的来说，事情只会变得有点贵。而且，我们知道在当前环境下，这相当具有挑战性。
最后，我个人发现这一点，我认为随着你发展你的数据实践并取得一些 DBT 和其他方面的成功，人们只是想要更多你的团队。虽然这很好，但这可能是一件难以平衡的事情。如果你的项目非常复杂，并且你遇到了一些我提到的挑战，那么很难让新团队成员入职。然后，在引进这些人的同时，你还要管理入职、维护你已经构建的东西，并且仍然要处理新的请求。
所以，下一张幻灯片。
所以，如果我们考虑将这些挑战分类，它们会落入三个大类。第一个是关于流程，这只是我们团队做事的方式。所以，在某些情况下，我的团队手动完成了一些我们可以自动化的事情，这样可以节省时间，并确保事情在某个流程的某个点以某种方式得到检查，这有助于加快速度。所以，找到一些流程效率，并思考我们如何一步一步地完成我们的工作，并从 A 点到达 B 点，并在你的流程中找到效率。
另一个大的是关于人。所以，这主要是关于你的团队内部或你的成人利益相关者之间缺乏一致性。让人们在编码约定、我们如何处理传入的工作、我们如何确定优先级等方面达成一致。这实际上也会对你团队的生产力和效率产生很大的影响。
最后，这可能是每个人首先想到的，但我喜欢把它放在最后，因为工具确实是在你弄清楚流程和人员之后，你才能开始做事，并确保你拥有适合这项工作的工具。我认为最好是退一步，先看看其他两个，然后弄清楚什么样的工具可以帮助我们解决这个问题。在某些情况下，在这个例子中，我们今天谈论的将是有点不同地使用 DBT，但也可能添加包，查看其他第三方工具添加到你的技术栈中，以帮助你克服某些挑战。
所以，只是稍微详细地解释一下。所以，当我们考虑克服我之前提到的一些规模化挑战时，我认为重要的一点是，在你开始的时候打下坚实的基础。当事情真的简单的时候，如果你没有遵循最佳实践，你就会走上这条路，最终你将不得不回来修复事情，这在很多方面都没有帮助。你将不得不找到时间和资源回来修复事情，而你可能一直在偷工减料，或者只是没有以最优化方式做事，而没有意识到。所以，我认为理解 DBT 的最佳实践，然后使用工具来帮助你强制执行它们。有不同的包，有不同的元数据可观测性工具，以及你可以实现的工具来了解我的项目的健康状况，以及我如何长期保持良好的状态。
然后，我认为考虑为现在需要的东西构建，但也要考虑我未来一年、未来六个月需要什么，并根据这些来做你的建模和测试约定决策。所以，我们 last company 学到的一件事是，我们有相当广泛的测试约定。我们有一些相当直接的规则，我认为是关于每次有主键时，确保你添加了非空和唯一测试。但我们在不同类型的数据（暂存、中间和核心级别）之间有非常相似的约定。所以，这意味着我们可能在重新测试相同的东西，而没有真正以任何方式转换模型。所以，虽然这是一个非常全面和强大的测试模型的方式，但它最终并没有很好地规模化，因为随着时间的推移，你将运行相同的测试大约三次。所以，这会大大增加成本并减慢你的项目。所以，早期考虑这些事情实际上非常重要，这样你就不会走到最后才发现你必须回去改变很多事情。
另一个是利用自动化。所以，正如我提到的，如果你把你的流程或你从 A 到 B 的步骤考虑进去，看看团队正在做什么，这有点手动。也许是编写你的文档或运行代码检查器。试着找出可以自动化的领域，让你的开发团队更容易，同时也确保每个人都以相似的方式做事，这可以大大加快速度。
构建一个可扩展的数据质量框架。我在第一点中已经提到了一些关于这一点的内容。所以，不仅仅是反应式数据质量，很多 DBT 内置的测试在你失败后会有帮助。但有很多测试功能可以帮助你主动管理数据质量。看看当我更改代码时，这对模型的输出有什么影响？然后，这可以帮助开发人员在他们将代码推送到生产环境之前修复问题，甚至在等待出现问题之前。所以，这些类型的工具可以帮助你提前发现问题，这可以节省大量时间。
然后，测试假设。很多内置的 DBT 测试更多是关于测试数据质量，而不是测试你的模型的逻辑。所以，考虑一些方法来实际测试，这更像是单元测试或模拟测试，以了解我构建的模型是否按预期工作？所以，查看输出并可能将其与一些预期结果进行比较。
最后，考虑你如何负责任地管理你的项目以及如何规模化。所以，很多这都会回到成本控制，这是目前很多数据团队的一个大热门话题，无论好坏，我们现在都受到更深入的审视。但我实际上认为，这促使我们构建负责任的项目，并主动监控性能。我管理我最后一个团队时学到的一件事是，我们总是把构建一些性能指标放在次要位置。我实际上认为这应该是我们的首要任务之一，因为你可以关注事情的进展情况，我们在哪里可能遇到一些我们不完全理解的问题。但 KPI 可以帮助我们更快地识别出来，并在问题变得更大、更难解决之前真正解决一些问题。所以我称它们为“smoldering problems”（潜在问题），但它们是项目运行缓慢，事情效率不高，你总是把它推到一边，直到真的出问题了，然后解决起来就更麻烦了。
是的，我认为这些是规模化挑战的关键点。是的，我认为在进入问答环节之前，只是为了总结一下，正如芭芭拉在开头所说，艾米丽的课程非常受欢迎，是开始分析工程的一个很棒的课程。下一期是九月。然后我的课程更侧重于那些可能使用 DBT 一段时间的人，他们遇到了一些我们刚才谈到的一些规模化问题。这个课程将在下个月推出，也就是几周后。
从那里开始，我认为我们可以开放问答环节。谢谢芭芭拉。
你想在问答环节中回答吗？
艾雅问，为什么 DBT 的学习资源缺乏？我觉得有很多资源。在 DBT Labs 生态系统中有很多免费的学习资源。他们在他们的网站上有几门免费课程。所以，我认为我记不清了，但有一个 DBT 基础，我认为有一个数据建模的，可能还有几个我记不清了，但它在他们的网站上的某个地方。
是的，我在学习 DBT 时找到了那些。我认为艾米丽，你是在很多这些资源可用之前学习 DBT 的。我学得更近一些，我个人发现那些资源对入门很有帮助，但它们没有很多例子。所以，我认为艾米丽的课程以及很多更深入的课程的伟大之处在于，你实际上可以尝试一些例子并完成一个项目，我认为这对于学习很有帮助。DBT 上的那些课程确实有一些很好的例子，但它们并没有真正深入，而且它们只有大约一个小时。但如果你想从某个地方开始，它们绝对是一个很好的资源。
此外，还有很多人在这里发布了大量内容，关于他们正在处理的问题以及他们如何解决它们，特别是像不同的会议演讲、博客文章。有很多东西在 DBT Slack 中。提问绝对是一个好地方。
DBT 和 Dagster Airflow 之间的区别？是的，Dagster 和 Airflow 更多的是编排工具。所以，你基本上会在 Dagster 或 Airflow 或 DBT Cloud 中构建你的 DBT DAG。它们不是 DBT 特有的，所以你可以用这些工具构建任意数量的数据管道。而 DBT 只是用于你的数据转换和特定于 DBT 模型。我想说它们是不同的类别。
你能推荐最好的在线 DBT 培训吗？我认为你已经在之前的回答中涵盖了一些内容，但你可以为你的即将到来的课程做个宣传。
参加我们的课程。
在最初设计你的 DBT 项目/模型时，需要牢记哪些最佳实践可以使未来的规模化更容易？
你想来回答一下吗？
是的，我可以开始，然后我很想听听你的想法，艾米丽。
是的，我认为你想考虑你在未来六个月到一年内的位置。我认为从一开始就采用最佳实践。所以，确保你正在使用建模层，你正在考虑你如何具体化你的模型，你没有重建不需要的依赖关系。我认为我们学到的一件事是，也许我们的团队没有足够地关注 DAG。他们不会回去弄清楚我应该把这个模型放在我的设计中的什么位置，他们可能只是添加了一个实际上可以以不同方式优化的东西。所以，我认为所有这些事情都是很好的实践，只是为了确保你没有过度复杂化事情，并且你尽可能地保持简单。
是的，绝对是从一开始就遵循标准和最佳实践。就像琳赛提到的，从一开始就关注那些性能指标和元数据，这样你就可以关注事情是如何增长的。
Slim CI 听起来很有趣。是否有生产运行的等效方法？例如，如果给定视图的 SQL 在运行之间没有改变，我能否跳过重新创建视图？
我不知道这会有多大帮助。我认为视图只需要一秒钟就可以完成，因为它们实际上并没有运行任何数据，数据并没有被转换成视图，它只是把元数据放在数据仓库里。如果有人调用这个视图，就运行这个 SQL。所以，这可能不值得复杂化。但我明白你的意思。我听说过增量模型，也许可以解决这个问题，即如果你只重建，你只构建当天发生变化的数据。
是的，我知道有一些人也在使用类似反应式编排的东西。所以，在很多方面，主动编排是这样的，你根据计划更新你的模型。所以，你会说这个模型我们每天更新一次，或者我们每天更新几次。在某些情况下，人们使用工具来检测我的源表是否有新数据？然后根据这些触发编排运行。所以，这有点类似。它不完全相同，但对于视图来说，这可能是一个方法，它真的无关紧要，但对于一个你知道除非有数据你真的不想重新运行或重建的东西，比如一个表，这可能是一种不同的方法。
检测未使用的模型？是的，我们有一个流程。也许你也有，琳赛。但取决于你的数据仓库，你可能有一些，我们使用 Snowflake，所以有很多 Snowflake 的元数据表，可以告诉你查询历史等等。所以，我们构建了一些基于这些的报告，告诉我们这个模型在 X 天内没有被查询过，然后我们可以优先清理那些我们决定在多长时间内没有被使用的东西。所以，我认为这也很重要，保持你的数据仓库清洁，并确保人们不使用可能不再应该使用的过时模型。
是的，当然。我在我最后一家公司使用 Redshift，所以我们没有那么好的内置元数据。但是的，无论是 Snowflake 还是有很多第三方工具也有帮助。所以，像连接到你的技术栈的东西，并且不仅帮助你的 DBT 模型，而且在你的 BI 方面，以及某些模型或仪表板的受欢迎程度，这可以帮助我们发现我们构建了这个，但没有人真正使用它了，我们应该把它去掉。
高效的 DBT 代码？我感觉在我们团队里只有几个人关心 DBT 的性能。我认为也许将其构建到你的代码审查流程中，确保这是对 DBT 贡献的期望，你必须达到这些标准，并且人们将在代码审查中持续检查这些标准，呼叫它们，建立这种协作。我不知道我正在寻找的词，但让每个人都负责任，确保数据是优先事项。
是的，是的，我同意。我们过去会开代码约定会议。所以，我们会每季度左右聚在一起说，是否有人想提出任何关于他们想改变我们做事方式的事情？有时我们会更频繁地进行这些对话。但我认为这有助于获得所有人的支持，并使团队作为一个整体更加凝聚，说这是我们做事的方式，原因如下。而且，我认为作为一名数据团队领导者或经理，如果你处于这个角色，也要帮助团队理解为什么你以某种方式做事。如果你正在编写一个低效的 DBT 代码，这会花费更多的钱，因为模型没有以某种方式具体化，或者减慢了团队的速度。我认为点出这些事情并与团队进行坦诚的谈话非常重要，因为有时只是帮助某人理解为什么我们需要以某种方式做事，这可以极大地激励他们并获得他们的支持。
他们是否一定能看到自己在数据科学领域？对 DBT 的知识水平有多大帮助？在拥有数据科学团队的公司里，有多少 DBT 知识会有帮助？有什么想法吗？
我认为，这取决于你的公司。在我以前的角色中，我们有一个数据科学团队，他们为 DBT 做出了贡献，他们所做的绝大多数是建立在我们分析团队构建的基础之上。所以，他们会使用我们那种基础性的维度和事实模型来构建他们的训练数据集或特征集，用于他们的数据科学模型输入，他们会在 Databricks 或其他系统中使用。所以，就像他们会使用数据团队的基础数据模型来为他们的数据科学工作流提供动力。在这种情况下，这真的需要知道如何编写 SQL，并且仍然遵循数据团队关于如何贡献 DBT 的最佳实践。但是的，这真的取决于数据科学角色的公司差异很大。
是的，那个头衔通常是最广泛的头衔之一，我发现。
那非数据科学呢？在一家使用 DBT 的数据科学公司里，一个非数据科学家应该知道多少？
我想这取决于他们的角色。他们是分析师吗？是的。我不知道，从数据消费者的角度来看，比如业务人员或更偏向业务的分析师。我认为任何分析师角色都会受益。但如果你知道 SQL，那么你就可以应对 DBT 中的大多数事情。如果你知道一点 Python，那么你就可以弄清楚 Jinja 和其他一些东西。我认为这是我学习 DBT 时学到的最大的一点。我直到深入了解了一下才真正知道它是什么。它主要是 SQL，学习 Jinja 以及事物如何协同工作。然后，正如艾米丽之前提到的，学习版本控制和 Git 等东西，这对于典型的分析师或数据科学家的工作流程来说有点不同。但是的，我认为这取决于你扮演的角色以及你为数据团队贡献多少。
是的，我发现那些刚开始学习 DBT 的人通常不会在 DBT 本身上遇到困难，而是更多地在相关的技能上，比如如何贡献 Git、命令行。一些更像工程、软件工程类型的技能，这才是很多人遇到的障碍，而不是 DBT 本身。这是我从课程中看到的，也是从我所在的团队中看到的。
是的，当然。这里有一个问题，查理问，我们在设置 DBT CI/CD 方面有很多挑战。涉及多环境变量和项目。这些挑战是否会在高级 DBT CoRise 课程中涵盖？
在一定程度上。所以，我们会稍微讲一下 CI/CD，但这更多地涉及其他领域。所以，我认为对我们来说，我们将更专注于 DBT 本身，我们会稍微谈谈这些领域，但可能还有其他课程会更好。我们肯定会谈论多环境变量之类的事情。所以，如果你对此感兴趣，课程网站上有相当详细的要点，说明我们将涵盖哪些内容以及项目将包含哪些内容。
太棒了。有人问在哪里可以读到更多关于数据管理方面元数据 CDC 的信息？你们有什么推荐的书籍或资源吗？
我真的很喜欢乔·雷森和马特·豪斯利的《数据工程基础》这本书。这是一个更广泛的数据工程主题。我会说分析工程和 DBT 是其中的一小部分。但如果你想更全面地了解数据生命周期，它会谈论很多你问题中提到的事情。所以，这可能是一个非常高层次的起点。但我想这取决于你想深入到什么程度。我不知道艾米丽，你可能有一些更适用的吗？
是的，我脑子里没有其他的了。
太棒了。我认为这是。
有人还问关于规模化 DBT 的最佳实践博客和文章。我认为 DBT 文档有很多内容，比如关于如何设置你的 DBT 项目的指南，以及如何考虑不同类型的物化等等。我不知道琳赛，你知道其他好的地方吗？很难给出一个名字，因为我觉得我关注很多人，他们写了很多很好的博客文章。所以，没有一个真正集中了很多这些东西的地方。但是的，像“西雅图数据 guy”就想到了，他谈论了很多数据工程和一些关于 DBT 的事情。只是想到了几个其他人。查德·桑德森在他的博客上也有很多关于各种数据工程主题的好东西。
是的，我不知道。
有人问关于 y42 及其生态系统与 DBT Cloud 的想法吗？
不知道那是什么。
是的，我以前没用过那个工具。
我认为这是我们最后一个问题。如果还有其他问题，还有几分钟时间，所以请随时将其添加到问答框中。
很多很棒的问题。是的，非常感谢大家的参与。