Airflow是Airbnb数据流程框架，本文接受访谈的是该工具的研发者，Tylor E.Edmiston增加了介绍和后记。
简介
我时不时会对一些看过的关于未来科技的帖子产生共鸣。
就在几周前让我产生共鸣的是Airbnb数据工程师，公司数据流程框架工具Airflow的研发者MaximeBeauchemin的一篇文章《数据工程师的崛起》（ The Rise of the Data Engineer）。在天文学者公司（Astronomer），Airflow在我们技术堆栈处于非常核心的位置：我们的工作流程集被Airflow中的数据流程(pipeline)定义为有向无回图（DAGs）。这个帖子，证实了为什么现在是天文学者（Astronomer）这样的公司存在的最佳时机。
读完帖子之后，我找到Max想做一个采访，让我高兴的是他愉快的接受了邀请并耐心的回答了我们关于Airflow和数据工程师未来的问题。接下来你会看到他的回答，但首先我想加一点点背景说明。
你可能在想“数据工程是什么，它为什么重要？”
在《数据工程师的崛起》（ The Rise of the Data Engineer）中，Maxime这样定义数据工程的：
- 数据工程领域可以被当作是从软件工程衍生出的，包含了商业智能和数据仓库的一个超集。
- 数据工程师之所以存在是因为企业们现在拥有大量如宝藏一样的数据，但让其产生价值，这些数据必须经过提炼。而数据工程工具箱则让我们快速大量地进行提炼。
闲话少说，让我们来看看对Max的问题：
天文学者（Astronomer）公司的优秀员工们被要求做一个关于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所以我更会照本宣科的给你说一些来自这些社区的难民或者被抛弃的人所说的话。
关于Luigi，有着比Airflow更小的作用域，可能我们更像互补而不是竞争。从我收集到的消息，产品的主要的维护者已经离开Spotify，很显然地他们现在内部（至少）有些用例也使用Airflow。我没有完整版故事但是很乐意听到更多关于它的事。我在想很多今天选择Luigi的公司可能之后也会选择Airflow，因为他们开发了他们需要的额外的特性集，这些特性集Airflow恰好提供。
关于Azkaban，我不确定除了LinkedIn谁还用它。显然这个项目现在还没有真正活跃的社区，我怀疑项目会继续在那个方向发展。而在LinkedIn外部，我听说了一些使用它的公司的奇闻逸事，某人在LinkedIn关闭了这个项目离开公司并在其他地方继续使用。
Oozie是我听过最被否定的一款软件，曾经，试着找出一个不在核心圈的Oozie用户有对其最全面的正面反馈。试一试吧！它可能是解决了核心问题之后仍然会被人们抱怨的，但是我认为它对不起这个名字也无法被拯救了。
我坚定地相信在配置上可以像编程一样的方式去创作工作流，我看到Airflow的关联物在现代数据生态系统中也稳定发展。好像基本上每一个在湾区关于数据和分析的创业公司都是用的Airflow。
http://www.timqian.com/star-history/#apache/incubator-airflow&spotify;/luigi&apache;/oozie&azkaban;/azkaban
［问题5］在接下来的5-10年数据工程学做为一个规程会怎么样改变创业公司呢？
现在创业公司不再将数据和分析作为后面考虑的东西。典型地他们早早的让数据科学家参与进来，第一波工程师会在产品初期版本中测量一些重要的分析结果。总裁们要求责任制和提供一种叫做“增长黑客”的服务早期提供指导服务给创意公司并衡量他们潜在投资回报看看哪还需要加倍投注。
我想未来的创业公司会被推动到刻画数据成熟度中，使其访问更好更便宜更易于访问的分析软件和服务。很多工作已经通过开源包模型化，但是仍然有一批不停增长的完整供应商解决方案例如MixPanel,Interana, Optimizely。不断提供云服务的AWS,GCS 和 Microsoft。
用于最尖端的事物像实时OLAP分析，异常检测，A/B测试量表和用户细分群体分析是现在任何创业公司以最低才能和合适的经费都想接触的。
当这些提供物变得越来越适用，变成保持竞争力的必需品，给敏捷创业公司提供越过领域中既定的慢玩家的机会。（应该是慢速发展的公司）
后记
2011年，MarcAndreessen写了一篇热门论文《为何软件在吞噬这个世界》（WhySoftware Is Eating The World）。2017年机器运行的所有软件都是由一座座数据山产生的，很多都很有价值但是只有使用对的工具才能让其全部搞清楚。
作为一个框架结构，Airflow提供了一个工作流层的抽象物给数据管道。Astronomer的DataRouter在其上构建了一个可以从任何源头到任何目的地的数据流程(管道)服务。你可以在最近的博客中学习更多关于Astronomer怎么使用Airflow和我们的开源理念。
创业公司不再仅仅建造软件－我们创造产品和数据洞察力驱动的公司。随着数据工程生态系统继续蓬勃发展，对于绘制各种各样的数据源的具有洞察力的创业公司的数量和质量的期望也在不断上升。
原文发布时间为：2017-5-6