什么是集成开发环境
这一篇，来谈一下大数据开发平台的门面，集成开发环境。什么是集成开发环境？顾名思义，就是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这种在所有组件的客户端和服务端都需要深度介入的方案。
流程
追求自由，是人的天性。集成开发平台的服务目标之一就是尽可能的为用户提供便利，降低门槛，提供工具让用户能够自由自主的完成各项查询，开发乃至管理工作。
然而，就像权限管理一样，适度的权限控制是为了让用户行动时更加放心大胆。适度的流程控制，也是为了划定边界，有约束的自由才是真的自由。
举个例子，任何人都可以拥有提交线上任务的权利和自由。但是，比如：我们可以要求线上的脚本任务，必须遵守脚本语法规则的约定，任务修改后，需要完成测试工作才能发布。核心任务变更，需要负责人评审等等。这些流程约束，依靠开发人员的自觉，显然是不够的。要保证流程的严格执行，就需要把它内建到集成开发环境的服务中去，通过工具来保证流程的实施。
需要注意的是，管理流程不仅仅是为了约束不合理的行为，控制风险。最终目的，还是为了提升整体的工作效率，降低风险只是其中一个角度的手段。其它有助于提升效率的行为，也可以通过流程来进行约束／推荐／管理，比如：有助于提升效率的最佳实践，有助于确保协同的公共规范和约定，有利于降低沟通成本的业务信息的完善等等
最后，集成开发环境本质上就是一个黏合剂，四通八达，增益各组件之所不能固然是它作为开发平台门户的价值所在，但是通过流程的建设和管理，在复杂的开发环境中为用户指出一条明确的路径也是必不可少的。没有规矩不成方圆，这句话算是说烂了，但是想想看，扔给用户一大堆系统，服务和功能选项，所有的行为都由用户自己来控制，充分的自由是否能带来最大的收益，还是混乱？自由意味着责任，责任意味着负担，规则固然是用来打破的，但是对于多数用户来说，打破规则的结果未必是他们想要的。适当的流程约束有时候也是降低用户学习成本和开发负担的一种有效手段。
总结
这篇文章务虚务得有点厉害，也是有些无奈，因为集成开发环境的建设目标，根本就是涵盖了整个数据平台的方方面面。可以做的事情太多，应该做的事情因各个公司具体的目标和阶段而异，正确的做事方式也未必只有一种，条条大路通罗马
加上我司在这方面的实践也在初级阶段，所以只好结合我们在为人民服务的实践过程中的一些体会，较为宽泛的讨论了一下集成开发环境建设过程中，各个环节目标的出发点和产品形态及价值的取舍导向。
总之，做好集成开发环境，不仅要从系统的视角考虑问题，更要从业务的视角考虑问题，成败的关键，在于能否有效的打通流程，融合信息。具体的一些产品和功能细节，欢迎各位同行来人来函进行交流 ：）
常按扫描下面的二维码，关注“大数据务虚杂谈”，务虚，我是认真的 ；）