集成開發環境-大數據平台的門戶

什麼是集成開發環境

這一篇，來談一下大數據開發平台的門面，集成開發環境。什麼是集成開發環境？顧名思義，就是IDE，哪個碼農不知道IDE的，有膽你站出來！

不過IDE這個詞也太普通了，在那些大廠玩大數據的同學們當然不會甘於平凡。所以，還得換個名字，土一點的，比如數加的開發環境，加上一個限定詞叫做 Data IDE，中文名曰：大數據開發套件。稍微洋氣一點，Data Works，大數據工坊，也是數加這個體系的名字之一。

企鵝爸爸這邊的名字也差不多，什麼TDF (Tencent Data Factory）數據工廠，TBDS (Tencent Big Data Suite) 大數據套件等等。兩家的平台，不光名字雷同，開發同學也是跳來跳去的，跳完以後，又是老死不相往來的節奏。

P.S. 嚴格的說，各種公有雲的大數據套件不光指的開發環境，還包括背後的各種存儲計算組件，不過，用戶才不在乎呢，用戶看到的，就是門面 ；）

至於開源的IDE嘛，比如HUE，大家應該不陌生了，雖然，全稱 「Hadoop User Experience」，也是相當的直白，然而縮寫完的名字，相比各種Data XXX，逼格立分，隱隱透著一點清新脫俗的味道。

此外，其它比如，阿里系對外面對商家的御膳房，對內的在雲端，還有不少大大小小的分析平台，開發平台之類的東西，大抵也是類似的系統。

你問我司的集成開發環境叫什麼？那絕對不能落入俗套啊，如前文所述，我司大數據開發平台的核心組件之一調度系統取名Jarvis，所以集成開發環境叫什麼，可以猜一下 ；）

集成開發環境的功能定位

你會問，IDE能有啥需求，不就是一個代碼編輯器么！作為一個服務平台，那就是Web版的代碼編輯器唄？

從某種的角度來說，的確如此。作為一個數據開發平台的用戶交互窗口，所提供的主要服務，在用戶看來，當然就是讓他能夠在上面寫代碼，然後運行。就這麼點簡單的要求，支持起來能有多複雜？

只可惜，簡單是從用戶的角度來說的，平台開發者的目標當然是讓用戶需要做的事情越簡單越好，但反過來說，用戶要做的事情越簡單，往往也就意味著系統要承擔的工作越多，對上下游流程和周邊系統的封裝，抽象和簡化工作就需要做得越完善。

所以，作為集成開發環境，最重要的工作絕對不只是提供一個代碼編輯窗口，而是需要將各種流程和組件儘可能簡單的串聯起來，提升用戶的開發效率和平台的管控能力。提供一個能夠顯示語法高亮的編輯器，只是其中的手段之一。

集成開發環境需要提供哪些服務

從業務流程的角度來說，理想情況下，集成開發環境所提供的服務，需要貫穿大數據處理鏈路的全過程，包括數據的採集，計算，管理，查詢，展示等環節。代碼編輯器僅僅是支持其中部分環節所需要的服務之一。具體這些環節所需要的各類服務，是否應該納入到集成開發環境中來，支持到什麼程度，功能組件如何劃分，不同的集成開發環境都會有自己的定位實現。

以Hue為例，主要的服務組件就包括4個：用做作業腳本開發的Editor編輯器模塊，用作數據展示和互動式查詢的Dashboard數據可視化模塊，用作任務管理的Scheduler工作流調度模塊，以及用作數據meta信息瀏覽的Browser模塊。

而阿里雲的數加平台呢，從產品形態上來看，也分為數據集成，數據開發，數據管理和運維中心這幾個模塊，大致對應了數據的導入導出，作業腳本的開發管理，表格元數據信息的編輯查詢，許可權的管理，以及任務的監控，管理，報警等幾項內容。

你可能會說，這不是幾乎把整個大數據離線開發平台的服務組件都囊括進來了么？ 確實如此，作為開發平台的門戶，終極目標自然是讓用戶通過這個門戶能夠順暢的完成所有的工作。以這個目標來說，上面舉的兩個例子，覆蓋的內容還遠遠不夠，遠還沒有達到集成開發環境一統天下的最高境界 ；）

但是，集成並不代表沒有分工，靠一個大而全的系統完成所有的功能，顯然是不現實也是不科學的。在前文論「跪舔式」構建「服務化」數據平台的崇高理想 中，我也提到，以我司的數據平台服務構建歷程為例，我們走的不是一站到底直接構建一個大而全的系統的路，而是針對抽象通用的功能需求，分別構建獨立的系統，然後再通過各個系統的疊加配合完成對業務場景的支持。

而集成開發環境，就是完成這個串聯各個系統，為用戶提供一站式服務的關鍵所在。所以，其建設水平的高低，體現在各種服務組件融合的順暢程度上。無縫的服務融合，用戶對底層系統的完全無感知，固然是理想的目標，但實際情況下，我們不僅要考慮組件的分層結構，平台的既有技術沉澱，開發的代價；還需要在系統的易用性和功能性之間做取捨平衡，也並不是把所有功能都集成到一起的全家桶就是最好的方案。

因此，集成哪些服務，集成到什麼程度，如何串聯業務流程，也就因時因事因公司而異了。以我司當前的情況為例，代碼編輯開發模塊是由集成開發環境自身提供的，而任務調度環節在集成開發環境中只是封裝了一個界面對比如作業的調度參數等進行配置，具體的功能和更複雜的交互管理服務，還是由獨立的調度系統組件來承載的。再還有一些功能，比如數據血緣信息，則只提供了一個信息的鏈接索引，將用戶引導到對應的系統中去。當然，這也不是我司集成開發環境的最終目標形態，事實上，當前的實現離我們期望的形態還有很大的差距，所以重構改造的工作也在實施中。

總之，提供一站式的服務，相信站在用戶的角度來看，大家都會認同，這是集成開發環境的重要的目標。但是，到底為什麼重要呢？顯然，最終的衡量標準，還是要體現在其價值收益上。一站式的服務只是一個手段，最終目的還是降低用戶的學習和使用成本，提高生產效率。

集成開發環境的產品目標

前文，從服務用戶的角度討論了集成開發環境需要提供哪些功能。不過，我們也說了，服務用戶其實也只是手段，而非目標，真正的衡量標準是價值收益。因此，除了通過一站式的服務提高用戶的生產效率，不難想像，在集成開發環境的建設的過程中，我們還應該考慮平台的運維成本，系統和數據的安全可靠性，以及所支持的業務的運行穩定性。

正所謂規模產生效益，集成開發環境之所以有可能取得這些收益，本質上還在於它是一個集中式的平台，不僅僅是一個集中式的開發平台，更是一個集中式的管理平台。通過集中管理各種服務，來降低服務成本，最大化價值收益。

那麼怎麼管理這些服務，管理的內容和目標又是什麼呢？

簡單的說，集中管理，管理什麼，我個人歸納為：組件，集群，腳本，任務，數據，用戶，許可權，流程這八項內容。下面就讓我從這個角度出發，按這種奇怪的維度劃分來分析一下集成開發環境的產品建設目標：

組件

集成開發環境，首當其衝的，當然是要管理各種服務組件。你固然可以通過SDK包或者集成發行版之類的方式將組件分發出去，讓用戶自己搭建服務環境，你對外提供技術支持（就像HDP／CDH這些服務套件發行版那樣）。但作為公司內部的團隊，理想的情況下，你應該提供的是PaaS或SaaS服務而非技術方案。

而服務組件的管理，也不簡單的是把各個服務搭建起來，然後在一個入口頁面提供各種服務的鏈接。更重要的是服務的整合，各個服務組件的功能，相互之間能否交叉跳轉或者進一步做到信息的融合。舉個例子，比如你的腳本編輯組件能否自動補全表格對象的欄位信息？能否將腳本與工作流調度組件中的任務流水關聯起來？各個組件的用戶，許可權等關係能否打通？這些都將影響到最終用戶的開發使用效率。

集群

集群的統一部署管控，顯然是提高工作效率和流程標準化的必要手段。但你可能會說，這項工作似乎更多的是一個運維層面的問題，通過統一部署管理，減少重複建設，提高生產力和資源利用率。這和集成開發環境又有什麼關係？

有沒有關係，取決於你對大數據平台所設定的服務目標是什麼。理論上來說，最理想的情況，當然是做到底層集群的具體信息對用戶是透明的。因為一旦用戶的業務通過API或客戶端直連集群，那麼很顯然集群與業務的耦合性就大大提高了，更重要的是，平台對業務的控制管理能力也就弱了很多。

舉個簡單的例子，比如你提供HDFS集群給用戶使用，用戶通過Hadoop client API或命令行上傳下載文件。那麼，業務方就需要知道你的集群地址，集群的版本，需要配置正確的環境變數和Hadoop conf文件等等。而從平台的角度來說，這麼一來，有多少業務方使用你的集群，怎麼使用，什麼時候使用你可能都很難搞清楚。而如果你要變更集群配置，升級，遷移，拆分或者進行流量，許可權控制，灰度測試等等，也會有不小的難度。

如何解決呢？不外乎就是兩種方案，一來，你可能可以通過提供定製的客戶端Jar包來封裝邏輯，或著通過改造服務端的介面增加各種監控管理手段來解決上述問題。二來，你可以通過代理的方式來解決，比如上述示例中，以Rest介面的形式提供對象存儲服務來屏蔽底層的集群，第二種方式如果做得徹底一點，那最好是連這個介面都和集成開發環境的服務融合，用戶只看到服務看不到介面。兩種方案沒有對錯之分，具體哪種方案更合理，當然需要具體case具體討論了。

總之，對集群的統一管控，著眼的目標，不光是從運維的角度出發，提高部署效率和安全穩定性，也需要從業務的角度出發，儘可能屏蔽底層細節，降低業務耦合度，留出騰挪空間，提升系統監管能力。

腳本

管理腳本，這個很好理解，畢竟集成開發環境的代碼編輯功能擺在明面上呢。

那麼，管理腳本是不是就是為用戶提供集中式的腳本編輯，儲存和運行環境呢？這的確很重要，畢竟，用戶如果自己管理和存儲腳本，在運行的時候才提交到平台上來，那麼對平台上日常運行的業務的維護將會是一個很大的挑戰。想想看你公司的代碼要是沒有統一的代碼倉庫進行管理，大家自己玩自己的，那會是個什麼樣的情況。。。

但從平台的角度來說，腳本的統一存儲管理，除了便於業務的長期維護，還能帶來更多的收益。

因為腳本，其實也就是業務邏輯，如果你能對它進行解析，那麼平台上運行的業務，對你來說就不再是一個黑盒。這也是為什麼我們會希望將各種計算框架的開發方式儘可能的SQL化，腳本化的原因之一。管控了腳本，也就有了管控業務邏輯的可能性。

舉例來說，你可以通過代碼掃描，來監控代碼質量，落實業務規範，你也可以通過解析腳本，來判斷業務之間的血緣依賴關係，你還可以通過集中掃描分析，為系統升級做好腳本的兼容性評估工作，你甚至可以通過對腳本內容的改寫替換，來實現對業務邏輯行為的監管調控。

總之，掌握了腳本就掌握了業務，在集成開發環境下，腳本管理能力的建設，在考慮如何為用戶的開發流程提供便利功能的同時，也應該適當考慮如何藉助集中管理的地利，挖掘創造出更大的價值，否則真的是浪費了這一有利條件。

任務

腳本和任務這兩者的管理，基本上可以說是密不可分的，畢竟所謂任務也就是靜態的腳本被賦予了一個動態的執行概念而已。

所以任務的管理，一方面是管理任務自身的動態執行過程，另一方面則是管理腳本和任務之間的映射關係。

前者，任務自身的動態執行過程的管理，多數的功能最終還是通過調度系統組件來承擔，涉及到的內容在前面的調度系統相關文章中也做了詳細闡述，這裡就不再重複，而後者，腳本和任務之間的映射關係，則多半要靠集成開發環境自身來管理了。

管些什麼呢？簡單的說，就是要讓腳本的編輯管理和任務的生命周期儘可能的無縫對接。比如作業腳本如何提交成為線上任務，線下腳本發生了增刪改，線上任務的版本是否同步？如何同步？腳本的開發測試過程能否隔離對線上任務的影響，從任務執行流水能否快速反向定位到對應的腳本等等。這些工作，大家或多或少都會做一些，關鍵是整體的完善程度和自動化程度。

數據

數據的管理，是不是就是搭建好各種數據存儲系統，保證數據的安全可靠，然後提供各種計算，查詢服務讓用戶去使用這些數據呢？應該說，這些工作是要做，不過更多的是透過集群／組件的管理去支持。

從集成開發環境的角度來說，數據的管理，更多指的是元數據的管理，那麼什麼是元數據？說實話，我覺得並沒有準確的定義，常見的表述比如：「描述數據的數據」只是對metaData的一個狹義解釋。廣義的來說，你基本可以理解為，除去你的業務邏輯直接讀寫處理的那些業務數據，所有其它用來維持整個系統運轉所需的信息／數據都可以叫作元數據信息。比如數據表格的Schema信息，任務的血緣關係，用戶和腳本／任務的許可權映射關係等等

你可能會說，把數據管理的範圍定義得這麼寬泛，固然滴水不漏，可是對指導集成開發環境的建設工作又有什麼實際意義呢？確實如此，所以除了數據管理的對象，我們還需要進一步明確一下數據管理的目標：數據管理的目標是讓用戶更高效的挖掘和使用數據，不是從計算效率的角度，而是從數據業務開發和管理效率的角度。

比如管理表格的schema信息或維度指標信息，是為了讓用戶更好的檢索和理解數據所承載的業務信息；管理任務的血緣關係，是為了幫助用戶理順數據的來源去向，更好的分析和開發業務；簡單來說，只要對提高業務開發效率和質量有幫助的數據，都可以成為優先管理的對象。因此集成開發環境在這方面的建設目標，也就是圍繞著對這些元數據信息的收集，查詢，管理和應用流程的完善和改進來進行的，通過對數據管理能力的提升，來提高平台管理和用戶開發的效率。

用戶

用戶的管理，最直觀的來說，首先當然就是對用戶登陸賬號的管理了。

從開發平台的角度來說，就是要打通各個系統服務組件之間的用戶賬號體系。靠各個組件自己維護一套賬號登陸體系顯然是不現實的，管理不方便，用戶體驗也很差，這也往往是各種第三方的系統難以無縫的集成到開發平台中來的一個重要原因之一。通常為了解決這個問題，大家都會採用一套統一的登陸認證體系，比如可以用LDAP來對用戶賬號和群組進行統一管理。而我司平台的用戶賬號則是通過公司統一的用戶登陸服務介面進行管理認證的。

要使用自定義的用戶登陸認證體系，當然就需要相關的系統主動進行對接。開發平台的各類用戶服務，比如集成開發環境和調度，數據交換，數據可視化等等各種服務系統，完全由自己掌控，那麼顯然是可以和統一登陸服務進行定製對接的，但是集群服務往往不能這麼做，開源的大數據組件和服務通常都會有自己不同的賬號管理方式。所以，你需要解決的問題是：如何對接開發平台服務和底層組件／集群之間的用戶賬號體系，映射？同步？使用Gateway？遵守約定？提供特權賬號？你需要考慮在什麼情況下，採用哪種對接方式。

此外，用戶賬號的管理並不僅僅是對用戶個人身份的映射這麼簡單，用戶登陸的賬號身份和底層集群服務執行時的賬戶身份，兩者之間也未必是一一映射的，出於許可權管控，業務共享，安全隔離等等因素的考慮，你可能會需要處理角色映射，用戶代理等方面的問題。

再有，有人的地方就有江湖，用戶往往不是作為一個個體孤立存在的，而是以業務團隊的形式組織起來的。這時候你還需要考慮：如何管理用戶的業務組歸屬，如何組織用戶的層級體系關係，如何讓一個業務組的管理員自主管理組內的成員？

最後，管理用戶的最終目標是什麼？很重要的一個目標，當然是是對許可權的分配管控。上述工作，一定程度上都是為了讓許可權的管理能夠更加清晰，合理，高效。但這並不是唯一的目標，另外一個很重要的目標，是在一個集中式的服務平台上，通過用戶和業務體系的管理，為用戶隔離出一個相對獨立的業務環境，理想的情況，是讓用戶能且只能接觸到與自己工作相關的那部分業務，簡化用戶的使用成本，降低租戶之間的相互干擾。所以如何規劃多租戶的產品交互形態，為用戶提供一個既能統觀大局，又能屏蔽干擾，關注自身業務的開發環境，往往是開發者在整個集成開發環境產品的設計過程中需要重點考慮的內容。

許可權

許可權的管控，歷來是大數據平台中最讓人頭疼的問題之一。管得嚴了，業務不流暢，用戶不開心，放得寬了，安全沒有底，你能放心？而且大數據平台組件，服務眾多；架構，流程複雜，有時候，就是你想管，也未必能管得起來。

涉及到具體的技術方案層面，Kerberos，LDAP，Sentry，Ranger，Quota，ACL，包括各個組件自己的許可權管控方案，這些話題，不是一小節的篇幅能夠覆蓋的，所以，我也不打算在這裡詳細討論各種技術方案。

所以，還是讓我們來談一下許可權管控的目標。從我司當前階段來看，我們的許可權管控目標，是防君子不防小人。此話怎講？許可權管控，大家都知道，有兩個步驟：認證（authentication）和授權（authorization）。前者鑒定身份，後者根據身份賦予許可權。

我司當前的許可權建設重點目標在於授權這個環節。如何對許可權點進行集中統一的管理；如何讓用戶自主的申請許可權；如何把許可權的管理工作交給具體的業務負責人而不是平台管理員；如何在不同的組件之間，不同的用戶之間打通許可權關係。這些工作，在當前複雜的生態環境中已經夠我們忙一陣子了。

至於用戶身份的鑒定這個環節，比如Kerberos這種方案，我們就暫時沒有採用。原因很簡單，覆蓋面不全，應用代價太高，收益不明顯。對於用戶身份的鑒定，我們的主要目標是防止無意的誤操作，而非蓄意的身份偽造。有很多種代價更低的用戶認證方式能達到這個目標。

所以，許可權的管控，做多少，怎麼做，花多少代價，取決於你的目標出發點，我司集成開發環境的許可權管控目標：是對用戶常規的業務行為範圍進行限定，敏感數據的控制固然是一方面，但更重要的是對業務邏輯和流程的約束，通過減少用戶不必要的許可權，減小受害面，降低可能的業務風險，同時也便於明確用戶的權責歸屬關係。

P.S. 即使長遠來說，在用戶身份鑒定這個環節，我們可能也更傾向於通過開發平台的服務來封裝底層的各種大數據組件，減少用戶和集群組件之間的直接交互渠道，在開發平台這一層面統一進行與具體組件無關的用戶身份鑒定，而不是Kerberos這種在所有組件的客戶端和服務端都需要深度介入的方案。

流程

追求自由，是人的天性。集成開發平台的服務目標之一就是儘可能的為用戶提供便利，降低門檻，提供工具讓用戶能夠自由自主的完成各項查詢，開發乃至管理工作。

然而，就像許可權管理一樣，適度的許可權控制是為了讓用戶行動時更加放心大膽。適度的流程式控制制，也是為了劃定邊界，有約束的自由才是真的自由。

舉個例子，任何人都可以擁有提交線上任務的權利和自由。但是，比如：我們可以要求線上的腳本任務，必須遵守腳本語法規則的約定，任務修改後，需要完成測試工作才能發布。核心任務變更，需要負責人評審等等。這些流程約束，依靠開發人員的自覺，顯然是不夠的。要保證流程的嚴格執行，就需要把它內建到集成開發環境的服務中去，通過工具來保證流程的實施。

需要注意的是，管理流程不僅僅是為了約束不合理的行為，控制風險。最終目的，還是為了提升整體的工作效率，降低風險只是其中一個角度的手段。其它有助於提升效率的行為，也可以通過流程來進行約束／推薦／管理，比如：有助於提升效率的最佳實踐，有助於確保協同的公共規範和約定，有利於降低溝通成本的業務信息的完善等等

最後，集成開發環境本質上就是一個黏合劑，四通八達，增益各組件之所不能固然是它作為開發平台門戶的價值所在，但是通過流程的建設和管理，在複雜的開發環境中為用戶指出一條明確的路徑也是必不可少的。沒有規矩不成方圓，這句話算是說爛了，但是想想看，扔給用戶一大堆系統，服務和功能選項，所有的行為都由用戶自己來控制，充分的自由是否能帶來最大的收益，還是混亂？自由意味著責任，責任意味著負擔，規則固然是用來打破的，但是對於多數用戶來說，打破規則的結果未必是他們想要的。適當的流程約束有時候也是降低用戶學習成本和開發負擔的一種有效手段。

總結

這篇文章務虛務得有點厲害，也是有些無奈，因為集成開發環境的建設目標，根本就是涵蓋了整個數據平台的方方面面。可以做的事情太多，應該做的事情因各個公司具體的目標和階段而異，正確的做事方式也未必只有一種，條條大路通羅馬

加上我司在這方面的實踐也在初級階段，所以只好結合我們在為人民服務的實踐過程中的一些體會，較為寬泛的討論了一下集成開發環境建設過程中，各個環節目標的出發點和產品形態及價值的取捨導向。

總之，做好集成開發環境，不僅要從系統的視角考慮問題，更要從業務的視角考慮問題，成敗的關鍵，在於能否有效的打通流程，融合信息。具體的一些產品和功能細節，歡迎各位同行來人來函進行交流 ：）

常按掃描下面的二維碼，關注「大數據務虛雜談」，務虛，我是認真的 ；）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！