Airflow 实践笔记-从入门到精通三

最新推荐文章于 2024-04-27 15:49:01 发布

大数据技术架构

最新推荐文章于 2024-04-27 15:49:01 发布

阅读量1.4k

点赞数

文章标签：分布式 docker 大数据 kubernetes 数据库

本文链接：https://blog.csdn.net/u011598442/article/details/125127735

版权

数据处理逻辑多，脚本相互依赖强，运维管理监测难，怎么办？！为了解决这些问题，最近比较深入研究Airflow的使用方法，重点参考了官方文档和Data Pipelines with Apache Airflow，特此笔记，跟大家分享共勉。

前面文章我们已经讲到了Airflow的搭建，DAG,Operator等特性，这篇文章主要讲述Airflow集群部署。

集群部署

airflow具体运行的时候，有多种executor模式。这个executor可以是SequentialExecutor（默认的），单机LocalExecutor（最多并行32个任务），也可以是集群模式，例如CeleryExecutor and the KubernetesExecutor 可以充分应用集群的计算能力。SequentialExecutor和LocalExecutor差别不大，只是前者是单进程，后者是多进程。

Celery

通过pip install apache-airflow[celery] 来安装包含celery依赖的airflow

Celery是通过Distributed Task Queue分布式任务队列，来实现异步任务调度的工具。分布式决定了可以有多个worker的存在，队列表示其是异步操作，客户端提交一系列的任务，这些任务按照顺序分配给后端的任务执行单元。异步任务可以极大的提升系统的响应速度，无需等一个用户请求执行完毕，就可以接受第二个用户请求，

1. Producer（celery client）：负责生产相关的task，并发送到一个broker中。

2. broker：作为一个task的路由器，将task分发到不同的接收者。例如RabbitMQ 和 Redis 中间人的功能比较齐全。

3. Consumer（celery worker）：接收到task以后，负责根据task的信息结构，执行相关的功能。

4. "消息队列"（message Queue）可以有多个，不同的消息指定发送给不同的队列，通过Exchange通过指定routiing_key实现。每个queue指定对应的worker来完成任务。

Flower, 是一个监测celery运行情况的包，观察每个celery work执行任务的情况，参考 https://link.zhihu.com/?target=https%3A//airflow.apache.org/docs/apache-airflow/2.2.5/executor/celery.html

在每台机器上都要安装airflow,并且其DAGS_FOLDER的内容是实时同步的（使用Chef, Puppet, Ansible），参考 https://link.zhihu.com/?target=https%3A//blog.csdn.net/weixin_41347419/article/details/112423531

Kurbenetes

1998年谷歌开始研发Kubernetes(K8S)，并在2014年开源发展至今。K8S是一个自动化的容器编排平台，用于自动部署，扩展和管理容器化应用程序的开源系统。K8S的产生，主要是基于两个因素：庞大的软件系统架构逐步转向灵活解耦的微服务结构，软件的部署逐渐从本地向云上迁移。因为容器是运行微服务的最佳载体，同时云可以提供无线扩展的计算机资源，因此K8S的目标是管理云平台中多个主机上的容器化的应用，让部署容器化的应用简单并且高效,Kubernetes提供了资源调度、部署管理、服务发现、扩容缩容、监控，维护等一整套功能。Kubernetes 有自动修复功能，当一个节点健康检查的功能，监测这个集群中所有的宿主机，当宿主机本身出现故障，或者软件出现故障的时候，这个节点健康检查会立即发现。Kubernetes有水平伸缩的功能，监测业务上所承担的负载，如果这个业务本身的CPU 利用率过高，或者响应时间过长，可以对这个业务进行扩容。

K8S架构中机器分为Master Node和Worker node。Control Plane控制类型的组件安装在master node上，具体执行任务的组件安装在Worker node上。组件如下：

API Server：属于control plane, 管理K8S的命令都是以HTTP请求的形式发送给APISever，由它负责跟其他组件交互。
etcd：属于control plane,是一个分布式的一个存储系统，APIServer通过读写etcd来记录和管理整个集群的运行状态。
Kublet: 属于work node，它时刻跟API sever 保持信息通讯，接受指令传递给Container engine。
Kube-proxy:属于worker node，负责节点中pods之间的网络通讯功能，例如K8S中的Service就是基于proxy组件实现的
Scheduler：属于control plane,起到资源调度的功能。观察正在被调度的这个容器的情况，比如说任务所需要的 CPU 以及它所需要的 memory，然后在集群中找一台相对比较空闲的机器来进行一次 placement放置，就是一次调度。
Controller-manager：属于control plane，是控制器，完成对集群状态的一些管理，确保每个节点的实际工作状态和etcd里面记录的是一致的。
Container engine(docker):属于worker node，根据kublet的指令来完成容器部署。
Kubectl:客户端，用户通过客户端来发送指令给集群。

重要的概念：

Pod 是 Kubernetes 的一个最小调度以及资源单元。用户可以通过 Kubernetes 的 Pod API 生产一个 Pod，让Kubernetes 对这个 Pod 进行调度，也就是把它放在某一个 Kubernetes 管理的节点上运行起来。一个 Pod 简单来说是对一组容器的抽象，它里面会包含一个或多个容器。

Volume 就是卷的概念，它是用来管理 Kubernetes 存储的，是用来声明在 Pod 中的容器可以访问文件目录的，一个卷可以被挂载在 Pod 中一个或者多个容器的指定路径下面。

Deployment 是在 Pod 这个抽象上更为上层的一个抽象，它可以定义一组 Pod 的副本数目、以及这个 Pod 的版本。一般大家用 Deployment 这个抽象来做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。

Service 提供了一个或者多个 Pod 实例的稳定访问地址。

Namespace 是用来做一个集群内部的逻辑隔离的，它包括鉴权、资源管理等。Kubernetes 的每个资源，比如刚才讲的 Pod、Deployment、Service 都属于一个 Namespace，同一个 Namespace 中的资源需要命名的唯一性，不同的Namespace 中的资源可以重名。

官方教程推荐使用Helm chart来在K8S集群上安装airflow。Helm（https://link.zhihu.com/?target=https%3A//cloud.tencent.com/developer/article/1694640）

本质上是K8S配置文件的管理工具，配置文件的格式为yaml，内容为应用部署到K8S集群时各个组件和对象的配置细节。因为配置文件的内容较为复杂，通过helm有助于借鉴其他团队的经验，基于此进一步补充自己所需的特有配置。A Helm Chart指的是包含一组K8s资源集合的描述文件。Helm的使用步骤如下

从chart仓库中获取chart
使用者配置自己的values文件，根据自己的运行环境对values进行修改；
默认values文件和使用者values文件会进行一个merge，形成最终的配置文件
使用最终的配置文件，渲染chart的template，形成可以被kubernetes执行的yaml
调用kube apply提交yaml到kubernetes

在Docker Desktop默认是有单机版的Kubernetes(minikube)，在linux上，需要安装virtualbox来使用minikube，在Windows系统需要安装Hyper-V hypervisor.

安装docker desktop以后需要开启K8S

K8S启动成功后，在docker desktop界面左下角显示绿色的图案，相当于一个集群已经建立起来了。生成环境，就要使用kind在真实的物理机群上建立K8S集群。

接下来在windows下安装helm。首先用管理员身份运行cmd，输入以下命令安装Chocolatey，这是用来安装helm的工具。

et-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

然后使用chocolatey安装helm，如果速度很慢，考虑其他方法见（https://link.zhihu.com/?target=https%3A//www.lsbin.com/9448.html）

choco install kubernetes-helm

通过系统管理员权限运行CMD，运行以下命令。命令的作用是：把官方的配置加载到本地仓库，根据配置文件的信息，在集群上新建一个namespace(资源空间)，在该空间下安装airflow。命令也可以加上—debug参考以便观察部署的日志信息。

helm repo add apache-airflow https://airflow.apache.org
helm upgrade --install airflow apache-airflow/airflow --namespace airflow --create-namespace

安装成功后，会有如下的提示：

our release is named airflow.
You can now access your dashboard(s) by executing the following command(s) and visiting the corresponding port at localhost in your browser:


Airflow Webserver:     kubectl port-forward svc/airflow-webserver 8080:8080 --namespace airflow
Default Webserver (Airflow UI) Login credentials:
    username: admin
    password: admin
Default Postgres connection credentials:
    username: postgres
    password: postgres
    port: 5432

按照提示，运行以下命令就可以在本地机访问web管理界面

kubectl port-forward svc/airflow-webserver 8080:8080 --namespace airflow

运行以下命令，检查集群各个组件和服务的运行情况

kubectl get pods -n airflow
kubectl get services -n airflow

如果要卸载airflow在集群上的部署，运行如下命令

helm delete airflow --namespace airflow

在K8s环境里，DAG文件同步的方法有如下，我们采用其中第一种方法

1）容器初始化的时候使用git来同步文件

2）在pods之间通过PersistentVolume来共享

3）每次把新更新的代码做成镜像，在dockerfile里把开发者目录最新的代码拷贝到DAGs文件夹下

基于官方的helm chart，我们可以进一步自定义集群的配置。下载官方的chart，注意下面第二个命令的version指的是char的version

helm search repo apache-airflow/airflow -l
helm show values apache-airflow/airflow --version 1.6.0 > airflow_values.yaml
helm show values apache-airflow/airflow > values.yaml

在下载的yaml文件中，行数很多但当前只关注以下的配置

- defaultAirflowRepository、defaultAirflowTag、airflowVersion约定了默认的镜像，如果需要集群加载我们自己的镜像，需要在这里设置

- 符号~，指的是采用默认值; IfNotPresent指尽量使用本地镜像

- executor: "CeleryExecutor"改成KubernetesExecutor

- gitSync 的enabled改为True，我们将使用git来同步DAG文件

- subPath的值，要根据放在github里面的具体文件路径来设置，例如默认是tests/dags

配置gitSync的部分

gitSync:
    enabled: true
    # git repo clone url
    # ssh examples ssh://git@github.com/apache/airflow.git
    # git@github.com:apache/airflow.git
    # https example: https://github.com/apache/airflow.git
    repo: ssh://git@github.com/yzengnash/learngit.git
    branch: main
    rev: HEAD
depth: 1
    # the number of consecutive failures allowed before aborting
    maxFailures: 0
    # subpath within the repo where dags are located
    # should be "" if dags are at repo root
    subPath: "tests/dags"
--------------省略很多行------------------
    # If you are using an ssh clone url, you can load
    # the ssh private key to a k8s secret like the one below
    #   ---
    #   apiVersion: v1
    #   kind: Secret
    #   metadata:
    #     name: airflow-ssh-secret
    #   data:
    #     # key needs to be gitSshKey
    #     gitSshKey: <base64_encoded_data>
    # and specify the name of the secret below
    sshKeySecret: airflow-ssh-secret

在集群上建立一个secret，即把github上的个人秘钥转成secret的形式存储。（具体git秘钥生成过程见后面章节）

kubectl create secret generic airflow-ssh-git-secret --from-file=gitSshKey=$Home/.ssh/id_rsa -n airflow

运行以下命令看看是否secret新建成功

kubectl get secrets -n airflow

运行以下命令更新cluster的安装

helm upgrade --install airflow apache-airflow/airflow -n airflow -f values.yaml --debug

查看运行的pod

kubectl describe pod airflow-scheduler-756d8c548c-67d99 -n airflow

通过查看日志，发现错误信息“Failed to pull image http://k8s.gcr.io/git-sync/git-sync:v3.4.0 rpc”，主要原因是由于国内网络防火墙问题导致无法正常拉取。我们使用阿里的国内镜像，参考https://zhuanlan.zhihu.com/p/429685829 在github里面新建一个repository，然后增加一个dockerfile，内容是需要拉取的image，例如 FROM https://link.zhihu.com/?target=http%3A//k8s.gcr.io/git-sync/git-sync%3Av3.4.0

登录阿里云，进入容器镜像服务控制台，创建个人实例，设置过Registry登录密码。创建命名空间

选择上面创建的github镜像仓库，勾选海外机器构建

进入镜像仓库，添加规则，然后点击立即构建

然后进行登录（注意：容器登录镜像服务实例的密码和阿里平台的密码不是同一个）

docker login registry.cn-hangzhou.aliyuncs.com

把刚才的镜像拉下来

docker pull registry.cn-hangzhou.aliyuncs.com/nash_image/image_repo:v1

重新命名

docker tag registry.cn-hangzhou.aliyuncs.com/nash_image/image_repo:v1 k8s.gcr.io/git-sync/git-sync:v3.4.0

再次根据最新的配置文件安装，就成功了

helm upgrade --install airflow apache-airflow/airflow -n airflow -f values.yaml --debug

Git安装配置

CVS及SVN都是集中式的版本控制系统, Git是分布式版本控制系统。分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，只是在联网的时候互相同步一下最新的代码即可，别的机器可以“克隆”代码仓库，而且每台机器的版本库其实都是一样的，并没有主次之分。因此分布式的安全性更高。实际上常用的方法是，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。更多操作教程见https://link.zhihu.com/?target=https%3A//www.liaoxuefeng.com/wiki/896043488029600

在windows安装Git,使用https://link.zhihu.com/?target=https%3A//git-scm.com/downloads

新建一个文件夹，然后在该文件夹右键Git bash here，输入一下命令来建立用户名和密码，global参数会让本机的所有仓库都使用这个配置

git config --global “user.name” 
git config --global ”user.email"

可以运行以下命令看所有配置

git config -l

把该目录变成一个仓库

git init

用命令git add告诉Git，把文件添加到仓库

git add readme.txt

用命令git commit告诉Git，把文件提交到仓库：

git commit -m "write a readme file"

查看当前仓库的状态

$ git status

恢复到上一个版本

$ git reset --hard HEAD^

注册一个GitHub账号，就可以免费获得Git远程仓库。也可以自建自己的Git服务器,创建SSH Key，后续配置远程仓库的时候需要，作为身份认证

$ ssh-keygen -t rsa -C "youremail@example.com"

在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。打开 id_rsa.pub，复制里面的 key（所有文字）。进入到github页面，菜单account->setting->SSH and GPG keys，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容

登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库，例如learngit。然后在本地仓库运行以下命令创建一个叫做origin的remote，并且完成对远程仓库的推送。其中：https以后的内容是有Github新建仓库后生成的地址。

git remote add origin https://github.com/yzengnash/learngit.git
git branch -M main
git push -u origin main

如果报错Connection was reset, errno 10054，就运行以下命令设置解除SSL验证。

git config --global http.sslVerify "false"

然后再进行push的时候，会在浏览器中弹出登录github的窗口，正常登录后选择authorize gitCredentialManager,后续提交就会成功了。

后续会讲述Dolphinscheduler , Dataworks（阿里云）的调度工具后续也会介绍，敬请期待。。。

往期回顾：

Airflow 实践笔记-从入门到精通一

Airflow 实践笔记-从入门到精通二

大数据技术架构

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Airflow 实践笔记-从入门到精通三

数据处理逻辑多，脚本相互依赖强，运维管理监测难，怎么办？！为了解决这些问题，最近比较深入研究Airflow的使用方法，重点参考了官方文档和Data Pipelines with Apache Airflow，特此笔记，跟大家分享共勉。前面文章我们已经讲到了Airflow的搭建，DAG,Operator等特性，这篇文章主要讲述Airflow集群部署。集群部署airflow具...
复制链接

扫一扫