dbt观点
dbt的观点是建立一个成熟的分析工作流程
在2015-2016年，RJMetrics的一个团队有机会观察并参与分析生态系统的重大演变。dbt的种子是在这种环境中孕育出来的，下面的观点是为了反映我们所总结到的东西，以及我们认为这世界应该如何不同。dbt是我们试图解决我们观察到的工作流挑战，因此，这一观点是dbt项目目标的最基本陈述
今天的分析现状¶
成熟分析组织的重心已经从专有的端到端工具转向更可组合的解决方案，这些解决方案由以下部分组成：
- 数据集成脚本和工具,
- 高性能分析数据库,
- SQL, R, Python分析语言
- 可视化分析工具.
这一变化释放了巨大的可能性，但分析团队（包括我们的团队）在持续提供高质量、低延迟的分析方面仍然面临挑战。
我们认为分析团队存在工作流程问题。分析师往往是孤立运作的，这不能产生最优的结果。知识是孤立的。我们经常重写一位同事已经写过的分析。我们无法掌握我们不太熟悉的数据集的细微差别。我们对共享度量的计算方式不同。
经过数百次的讨论，我们确信，这些条件基本上是复杂分析团队的现状。因此，组织的决策速度降低，决策质量降低。
分析不一定非得这样。事实上，解决这些问题的策略已经存在我们的软件工程团队中。软件工程团队用于协作快速创建高质量应用程序的技术也可以应用于数据分析。我们认为，现在是时候建立一套开放的工具和流程来实现这一点了。
分析是协作的¶
我们认为，一个成熟的分析团队的技术和工作流程应该具有以下协作功能：
版本控制¶
分析代码无论是Python、SQL、Java还是其他任何语言，都应进行版本控制。分析随着数据和业务的发展而变化，知道谁在什么时候改变了什么很重要。
质量保证¶
糟糕的数据可能导致糟糕的分析，而糟糕的分析可能导致错误的决策。任何生成数据或分析的代码都应该经过审查和测试。
文档¶
你的分析是一个软件应用程序，和其他所有软件应用程序一样，人们会对如何使用它有疑问。尽管它看起来很简单，但实际上“收入”这一数据可能会有十几种含义。您的代码应该附带一个关于如何解释的基本描述，并且您的团队应该能够在出现其他问题时添加到该文档中。
模块化¶
如果你对公司的收入进行了一系列分析，而你的同事也这样做了，那么你们应该使用相同的输入数据。复制粘贴在这里不是一个好方法，如果基础数据集的定义发生了更改，则需要在所有使用过的地方对其进行更新。相反，将数据集的schema视为其公共接口。创建表、
分析代码是一种数据资产¶
生成该分析所需的代码、流程和工具是组织的核心投资。我们认为，一个成熟的分析组织的工作流程应该具有以下特征，以保护和增长资产：
环境¶
分析需要多个环境。分析师需要在不影响用户的情况下自由工作，而用户需要服务级别保证，这样他们才能信任他们工作所依赖的数据。
服务水平保证¶
分析团队应支持所有已推广到生产中的分析的准确性。错误应该以与生产环境产品中的错误以相同的紧急程度来处理。任何从生产环境中退出的代码都应该经过弃用过程。
可维护性设计¶
软件开发所涉及的大部分成本开支都是在维护阶段。正因为如此，软件工程师编写代码时应着眼于可维护性。然而，分析代码往往是脆弱的。底层数据的变化以难以预测和修复的方式破坏了大多数分析代码。
编写分析代码时应确保可维护性。应该预料到未来对schema和数据的更改，并且应该编写代码以最大限度地减少相应的影响。
分析工作流程需要自动化工具¶
通常情况下，大部分分析工作流程都是手动的。将数据从源传输到目的地，从一个阶段传输到另一个阶段，可能会占用分析师的大部分时间。软件工程师构建了大量的工具来支持他们工作中的手动部分。为了实现我们建议的分析工作流程，将需要类似的工具。
以下是自动化工作流程的一个示例：
- 从多个源代码管理库下载模型和分析，
- 为给定环境配置代码，
- 测试代码
- 部署代码
像这样的工作流应该可以使用单个命令来执行。