本文属于【Azure 架构师学习笔记】系列。
本文属于【Azure Databricks】系列。
接上文 【Azure 架构师学习笔记】- Azure Databricks (19) --Lakehouse
DLT 通过自动化data pipeline编排，简化ETL 过程，强化了质量检查和优化性能。在以前，数据工程师只能通过手工调度notebook和校验，处理业务逻辑异常。DLT通过声明式ETL 框架抽象掉很多操作开销。
声明式开发意味着可以以描述形式来处理需求。不需要再显式管理任务调度和集群资源。
Delta Live Tables 工作原理
DLT 由几个核心组件和模式（mode） 组成。
核心组件：pipeline， Live tables， expectations
- Pipeline：以有向无环图的形式传输数据和管理执行。
- Live Tables：在pipeline内部，创建的表或者视图，用于作为目标数据集。通过声明式定义这些表。比如在Python中可以使用@dlt.table。如果表1需要读取表2， 那么DLT会识别这个血缘关系，然后一旦有更新数据要求，会按照先更新表2，然后表1的顺序来更新数据。只需要在定义中声明表包含了什么，那么DLT就会自动处理这些。
- Expectations：DLT 内置的数据质量规则。它本质上就是按照你定义中指定在表上规则而进行的数据检验。比如 age between 0 and 100这种规则。简单来说就类似SQL 中的约束。但是需要适当地处理不符合校验规则的异常。
Modes: Development, Production
DLT有两个模式，在适当的时候使用适当的模式。
- Development：主要用于交互式开发和测试。DLT会尝试以迭代的方式，比如禁用自动retry，可以便于查找问题。同时在这个模式下，集群通常会2小时内活动以免频繁关闭带来测试过程重启等待时间。但是也意味着有一些闲置时间所带来费用的风险。
- Production：针对Pipeline中的稳定性进行了优化。每次更新运行都使用全新的集群启动（确保干净的环境并解决内存泄漏或过时的凭证等问题），并且 DLT 将自动重试某些失败（例如，如果集群预置失败或发生暂时性错误）。在 prod 模式下，一旦pipeline运行完成那么默认情况下，集群会立即终止从而减少费用。
总体而言，正如其名，开发过程可以使用dev 模式， 一旦上线到了生产环境，则建议切换成prod 模式。
Delta Live Table Pipeline设计建议
Tutorial: Run your first DLT pipeline
- 确保源和目标都是Delta格式：由于Delta具有ACID，架构增强和性能提升等特性， 可以使得DLT更加稳定。
- 选择streaming还是批处理：DLT支持两种源，流和批，所以在开始设计之前要了解使用哪种源，如果是持续更新比如kafka， IoT等，那么就应该使用streaming表。这样PL就会持续运行并以低延时的方式处理新数据。反之则使用批处理。虽然DLT 的PL 可以混合使用这两种源，不过由于机制不一样所以不建议混用。
- 尽早定义Expectations：正如合理的数据库表设计一样，尽早在表定义中设置约束可以保证数据的有效性，避免后续清理垃圾数据的工作量。
- 管理血缘关系和依赖：虽然DLT 可以使用图形化来展示数据操作，但是如果没有定义好各个表的关系，那么图形会变得非常混乱，同时注意要避免形成环路，简单来说就是要把处理逻辑设计好。
DLT Pipeline
下面看看如何配置PL， 首先从Databricks的UI 界面进入，并点击左下角的pipelines， 可以看到右边的create pipelines，有好几种方式，格局具体需求选择：
在创建界面有很多选项，具体选项可以点击对应的叹号：
选择数据源和目标：
配置集群：
其他配置：
可以点击【create pipeline from sample data】感受一下：
点击右边的【start】
会出现一些流程图：
通常会在notebook里面编写好代码，然后通过pipeline调用代码文件来生成实际的图。