AWS MWAA(Airflow)环境下requirements.txt导入dask包失效问题

这个问题是MWAA自定义依赖加载的高频故障，大量开发者在安装dask、分布式计算类依赖时都碰到过。故障核心逻辑是：MWAA启动时解析、安装requirements.txt的流程只要触发任意错误，就会直接终止整个自定义依赖安装步骤，不会加载任何你在文件里声明的包，才会出现加了一行dask配置后，之前能正常导入的自定义包也全部失效的现象。

常见触发原因和对应处理方式如下：

• 首先排查requirements.txt格式合规性问题
  MWAA对requirements文件的格式要求比本地pip严格很多：必须是UTF-8无BOM编码、采用LF换行符（不能用Windows默认的CRLF换行）、不能包含全角字符、中文空格、非PEP440规范的版本写法，文件末尾需要保留一个空行。很多人加dask==2022.6.0这行的时候，不小心带入了全角等号、行尾多余空格，或者保存文件的时候用了系统默认编码，会直接导致MWAA完全无法解析文件，所有自定义依赖都不会加载。
  可以先把文件内容清空，逐行把之前能正常运行的配置和dask==2022.6.0重新手打一遍（不要复制粘贴避免带入隐形字符），转成LF换行、UTF-8无BOM格式后重新上传测试。
• 其次处理dask与MWAA内置包的版本冲突
  这是安装dask时最常见的故障原因：dask 2022.6.0会强制要求安装对应版本的cloudpickle、fsspec、toolz、partd等基础包，而MWAA的Airflow运行环境本身预装了固定版本的这些依赖，pip安装时如果检测到版本不兼容，会直接抛出错误终止安装流程。
  对应处理步骤：
  1. 打开MWAA对应环境的CloudWatch日志，查找scheduler、worker节点的启动日志，搜索pip install关键字，能直接定位到具体是哪个依赖的版本冲突
  2. 在requirements.txt中显式钉死MWAA预装的冲突包版本，避免pip尝试升级内置包触发兼容问题
  3. 如果版本冲突无法调和，可以更换与当前MWAA Airflow版本依赖匹配的dask版本，比如Airflow 2.4.x版本对应的MWAA环境，使用dask==2022.10.0的兼容性普遍好于2022.6.0版本
• 最后排查依赖包体积/安装超时问题
  MWAA对自定义依赖的总安装体积、pip安装时长都有硬性阈值，dask本身连带全量依赖体积不小，如果requirements里所有包解压后总大小超过120MB，或者安装时长超过5分钟，会直接被系统判定安装失败，终止整个流程。碰到这种情况可以在安装dask时加--no-deps参数，手动补充MWAA环境没有预装的dask依赖，剔除冗余包减少体积。

内容的提问来源于stack exchange，提问作者Khaled