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
本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号