正文
Airflow
和
数据工程
的简短访问。以下为相关问答：
［问题1］Airflow下一版本发布是在什么时候，最令你激动的特性是什么？
8.0rc4（版本候选4号）刚刚被Apache委员会投票通过，但是被Airbnb技术人员发现一些故障后暂停发布。技术人员正全力移除这些障碍，新的发布马上就来。我们应该期待1.8.0这周或下周问世。
这是第一个非Airbnb主导的版本，荷兰国际集团的Bolkede Bruin为了这次发布做了出色的工作。这次发布相较上次发布，时间和工作量上都增加了不少。这是自2016年6月13日颁布的1.7.1.3之后的第一次发布。
这次的版本同1.7.1.3相比有相当大的改变，在我看来，以下几点是需要强调的：
-
一个多线程调度器，允许更快的日程循环并提高导入DAG文件时的容错能力。先前的版本，一个DAG文件里的简单sys.exit()语句就可以使调度器停止运行。
-
用NVD3替代Highcharts的图表库。Highcharts有一个非Apache兼容许可证，拿掉它将把我们带出法律灰色地带。
-
Unix系统模拟和控制组，允许以特殊Unix用户方式运行任务，特定的控制组可以在任务级限制资源利用率。这可以避免一个任务占用所有资源以致威胁Airflowworker(工作节点)。
-
谷歌云服务（GCS）与改进后的操作元（operator）和挂钩集（hooks）集成。
-
一个更好更依赖于模型的引擎，可以实现更多的可维护性和扩展性代码，在UI上添加新特性“为何不是我的任务在运行”。
-
可修复所有关于“僵尸”和“不死”进程。
-
比之前版本有更好的（资源）池区处理超负荷任务。
-
新操作元和挂钩集。
-
极其容易的操作性和全面地故障修复
我们希望能够有一系列更稳定的版本遵循这个安排表，虽然还没有官方承诺要这样做。
［问题2］从Airbnb内部工具到Apache项目工具是如何过渡的？
这个过渡还是很顺利的。Apache社区通过允许很多外部贡献者合并pull请求来衡量社区贡献，一方面加速了项目改进的速度。另一方面它减慢了版本发布的步伐，强迫我们管理自己版本的分支，这由之前官方发布的版本和代表我们添加在每个版本顶部的提交表单的“樱桃”列表组成。我们现在也倾向于开发这样一个内部分支，一旦发行版在我们这边的生产上稳定下来就将其推出社区。
我们很享受在上次发布之后收到的帮助，看到项目在我们自己自愿有限的情况下(借助社区)依然欣欣向荣。我习惯于独自检查和合并每个性能需求，过去几年就这样交出自己的成果。很开心看到这些良性循环和令人开心的“传销”一次次进化。
［问题3］你怎么看待Airflow的用途改进？接下来的5年，会出现什么新的Airflow应用？
数据基础建设生态系统还没有表现出任何聚集到什么东西上更具管理性的信号。似乎我们仍然在急剧扩张的阶段，每天都有新的分布式数据库、新的框架结构、新库和新合作对象。由于这些系统更加复杂和快速发展，拥有像Airflow这样可以让所有的东西聚集在一个健全的环境下是非常重要的。这个环境可以让任何一个小难题与完善的API协调调度起来。
由于Airflow在调度范畴内达到了特性的完善。我们可以假设集成其他系统（例如hooks和operators）是一个可发展的区域。
Airflow最初的设想是更多地作为一个调度器而不会承载真正的工作量，但似乎人们更愿意用Airflow运行R脚本、Python数据处理任务、机器学习模型训练和排列等等更多复杂的工作量。
当我们内部鼓励人们去开发像Kubernetes或Yarn 这类型的服务和杠杆基础设施的时候，显然地有一个需求需要Airflow直接演变成这样一个方向，并支持集装箱化（请运行这一任务在Docker控件内！）和资源管理（请分配4个CPU和64G内存给这个功能）。我们意识到人们可能在他们系统环境中的限制条件而又想发挥Airflow 的最大作用。所以如果你的Kubernetes集群部署在其中我们应该充分利用，即使没有部署，我们也想你能够同时在Airflow上运行你的任务。
我相信Airflow被定位为批量处理调度器即将在未来5年成为主导
。我们有一个可靠的技术基础和庞大高动力的社区！
［问题4］你怎么看待同一领域的相同技术，例如Luigi，Azkaban等？
个人来讲自从加入Airflow社区之后我没有用过Luigi,Azkaban 或Oozie所以我更会照本宣科的给你说一些来自这些社区的难民或者被抛弃的人所说的话。
