airflow元数据库表详解

airflow调度系统，基本介绍看这篇文章：
https://chenzuoli.github.io/2021/10/16/airflow%E4%BB%8B%E7%BB%8D/

airflow架构，看这篇文章：
https://chenzuoli.github.io/2021/10/24/airflow%E6%9E%B6%E6%9E%84%E8%AF%A6%E8%A7%A3/

它能实现我们日常工作中离线任务的调度，下面来看看使用mysql或者postgresql作为元数据库时，库中的各个表都是干什么用的。

注：下面的表，标记黑体的都是用的比较多的表。

ab_开头的表，如果你开启了airflow rbac认证模式，那么这些表就会在你启动airflow的时候自动生成，这些表都是记录用户权限的地方。
alembic_version: 记录当前airflow的初始化时候的版本，注意，这个版本不是airflow的版本，而是airflow在进行初始化的时候，使用alembic包进行版本升级用的版本，它是数据库迁移工具所用到的轻量级的数据库迁移工具，有兴趣的同学，可以去看看alembic这个包的介绍：https://alembic.sqlalchemy.org/en/latest/
celery_taskmeta、celery_tasksetmeta: 记录scheduler发送task，worker消费task的命令，即airflow运行的task命令；
chart: 当我们使用的是airflow无需登录认证模式时，我们可以通过airflow web ui界面添加的表格信息；
connection: airflow提供给我们的连接管理器，可以在这个表里面保存各种数据库的连接信息，比如mysql oracle hive等，在使用的时候，直接指定连接id，即可。
dag: 这个表时我们用的最多的表之一，它就是存储我们定义的dag信息，从dag文件中编译而来，里面存储了dag的schedule_interval，dag_id，owner，状态等信息；
dag_code: 这个表存储的是dag的代码，和dag文件位置，dag文件的hash值，它是在airflow 1.10.12版本开始的新特性，通过在airflow.cfg配置文件中配置store_dag_code=True来的，设为True，那么scheduler就会把编译的dag文件源码写入这张表中；
dag_pickle: 这张表没用过；
dag_run: 这张表也用的比较多，airflow调度系统是以dag为单位进行调度的，每个dag在指定时间进行调度时，会创建一个dag_run实例，然后这个实例中包含多个task，所以一个dag_run，通俗理解，就是这个dg的一个批次。最关键的信息就是dag_id，execution_date（批次运行时间）；
dag_tag: 这个表也是新版本才有的，这个应该也是1.10.12版本的新特性，我们可以为dag添加tag标签，这个标签类似一个分组的概念，将一类dag打上一类标签，另一类tag打上另一类标签，这样我们在web页面上就可以进行搜索。看下图中的example example2均是对dag打上的标签分类
import_error: 这个表记录的是编译有error的dag，就是你在airflow主页上你看到的哪些错误信息，会把错误信息记录在这个表里；
job：这个表也是记录的dag的运行信息，不过与dag_run相比，这个表记录的仅仅是dag运行的简介信息，包括运行用户、服务器、开始、结束时间；
known_event、known_event_type: 这两张表没用过，不用理会他们；
kombu_message、kombu_queue: 这两张表也没用过，不用理会；
kube_resource_version、kube_worker_uuid: 这2张表是在你使用了kubenetes作为task引擎时才会用到的，在工作中没用到kubenetes作为worker，所以不了解；
log: 这张表也用的比较多，我们查看用户的操作记录，这张表都有记录，包括你点击的哪个模块，下期会详细讲解这个log怎么看。
rendered_task_instance_fields: 这个表记录的是你的dag、task运行时，airflow所渲染的一些变量，比如ds next_ds等；
serialized_dag: 这张表记录的是序列化后的dag和task信息，它将我们定义的dag，编译成了一个json，存储在一个字段中，这个json包含dag基本信息，task基本信息，还有task直接的上下游关系，所以说非常地全面，如果我们有元数据管理的需求，可以通过这张表来，也就不需要自己去解析文件了；
sla_miss: 这张表记录的是我们在dag文件中设置的sla告警，sla的意思就是，某个任务设置了截止时间，如果某个它到了截止时间仍然没有启动、或者运行成功，那么就会记录到这张表中，作为告警使用；
slot_pool: 这张表记录的是task运行所在的池子，我们可以设置task运行在不同的池子里，然后worker消费不同池子中的任务，来进行任务划分，不同的任务，运行在不同的服务器上。另外，池子还可以设置大小，限制池子运行的最大任务数；
task_fail: 失败的任务，会单独记录到一张表中，就是这张，但是我们一般看task_instance表，从task_instance表中查看task的运行情况，会更详细一点；
task_instance: 这张表查的最多，它记录了每个task的运行详细信息，包含重试的。关于任务监控这块，我们就是从这张表中去做的task统计，看哪些task失败了，哪些task运行时间突然变长了，哪些task运行超过2小时了，都会有相应的告警发出来，供预警参考等等；
task_reschedule: 这张表，记录的是task重新调度的信息，我们的task是sensor类型时，它去check上游外部task状态时，没有达到自己所满足的要求时，就会处于reschedule状态，等待下一次调度；
users: 这张表是我们使用了password认证模式时，出现所需要用的的一张表，记录我们添加的user；
variable: 这张表我用的比较多，在我们需要通过外部传参时，用的比较多，在web页面设置一个key value键值对，然后我们的任务就可以通过这个key，获取到不同的value，来运行不同的场景，非常的实用；
xcom: 这张表功能很强大，但是用的少，一般在dag中task和task之间需要进行数据传递时用，前面一个task运行的结果，可以push到airflow中，记录在这张表里，然后下游另外一个task去pull，达到数据传输的目的。如果我们不用xcom进行数据传递，那么需要自己实现传递的方式，比如写文件，写数据库，那么就增加了额外的管理开销，airflow是分布式的，写文件的话，一个task运行在worker1上，文件就在worker1上，那么运行在worker2上的task怎么拿worker1上的文件，这就是你需要考虑的问题了，如果使用数据库记录，那么你需要自己去连接数据库，增加了额外的连接成本，那么何不使用xcom呢？airflow已经帮你实现了。