DBT(Data build tool)情况简述：
1，ELT(数据抽取, 数据加载, 数据转换) 数据处理流程，dbt框架主要用于做T(官方只认T)和L的工作，主要依赖配置文件的定义，实现数据的L和T；
例如：配置文件内配置数据文件路径 ，数据文件格式(列名称)，数据探测类型(unique,not_null,accepted_values等)，数据处理转换模板；
dbt框架基于配置文件对数据做自动化处理：将数据文件加载到数据仓库，探测数据规范性，将数据做转换处理，生成可以用来分析的数据集；
2，配置文件有两类，.yml，.sql , .yml用于定义项目信息，数据连接信息，数据格式，数据探测类型信息；.sql用于定义数据处理转换逻辑；
3，整个数据处理流程按层次进行划分：数据加载层、数据预处理层、数据集市层，配置文件在每个层次都存在，用于定义所在层的配置；
4，数据处理过程产出文档：原始数据载入数据仓库后，根据.yml定义的数据探测类型，对数据做质量探查，并产出数据探查描述信息，附图1；
整个数据处理完毕，能够生成数据模型报告/数据地图，描述数据定义及模型间血缘关系，附图2，附图3；
DBT优势：
1，如官网述，开发只用关注逻辑代码的开发，不用关注表及视图的创建，不用关注代码执行顺序，DBT框架自动实现这些工作；
2，DBT框架已定义一套数据开发流程及规范，可以约束项目的规范性；
3，DBT框架已抽象出的通用功能，可以降低工作复杂度及重复性编码工作，如：数据探查，将探查的内容，在配置文件定义，DBT自动输出探查结果，避免开发代码，降低数据探查难度；
DBT不足：
1，DBT目前只能从文件读原始数据，如，CSV文件；
2，支持的数据仓库种类偏少，如：Postgres，Presto，Spark等，若使用其他数据仓库，需开发DBT插件；
3，数据逻辑处理代码，需根据.sql配置文件的格式定义，实际的项目中，数据代码达到上百行，在.sql配置文件格式的规范下，代码管理复杂度会提升，复杂的项目.sql配置文件数量会很多，带来代码梳理及管理上的复杂度；
4，实际项目数据对象的字段会比较多，.yml配置文件定义字段，会比比较繁琐；