通过我其他的zeppelin分析文章,大家可以从中了解zeppelin是什么样的。本篇试着阐述问题的另外一面,zeppelin为什么是这样的?本文从需求出发,探寻zeppelin的架构设计、技术选型、代码的模块划分和依赖关系最初的“出发点”。
zeppelin的核心功能用一句话总结就是:支持多语言混合的REPL(Read-Evaluation-Print-Loop)。这个核心功能的价值体现在:
站在使用者的角度,意味着:
1. 可以在一个Note中混合使用多种语言。用户可以根据需要完成的任务的类型,选择最合适的语言来实现,不再受限于单个语言的特性。例如:MarkDown能做出漂亮的文档,python和R有大量的科学计算、机器学习和可视化包,scala与Spark有天然的血缘关系,Shell处理本地文件非常方便……,可以想象一下将这些语言的优点都结合起来,会产生多么强大的生产力。
2. 数据分析和机器学习,从来都不是一个“一蹴而就”的过程。分析过程和机器学习算法一样,本质是不断迭代和试错的过程。数据科学家和算法工程师对数据分析平台最看中的能力是“有丰富的组件”和“可调试”(至少在我接触到的数据科学家和算法工程师来看是这样的),前者表达了对平台功能全面的需求,后者表达了如何对采用这些功能“平顺”地开展实际业务分析的需求,二者相辅相成。REPL相对于“拖拽式”的数据分析平台,虽然不能像传统IDE一样,设置断点和查看中间变量,但是相对于“纯黑盒”的拖拽式数据分析工具,能在很大程度上实现“调试”功能。
站在管理者的角度,意味着:
1. 使得统一工具环境成为可能。一个数据分析团队中,各成员由于擅长的语言不同,可能需要同时维护多种环境,如R、Python远程桌面开发环境,R和Python都是通过第三方扩展包进行扩展的,成员熟练使用的包,也有所不同,给运维造成了较大压力。实现一个集中式的分析工具,在服务端集中于一处,统一配置R、Python、Spark、Hadoop、Hive等开发环境,显著降低运维成本。
2. 使得进行统一安全控制成为可能。B/S系统,方便进行集中式用户权限控制,并且由于该平台”看到”的是各种语言的源码,可以对恶意代码进行监测和过滤,避免有意或者无意地对系统造成的损害。此外,可以限制所有过程都在线操作,不存在跨机器传递数据的问题,可限制导出数据,保障数据安全。
现在,让我们抛开对zeppelin的已有认知,假设让我们重新设计一个平台,实现上述核心功能,会面临哪些问题,这些问题都有哪些解决方案,各种方案又孰优孰劣,在此过程中,探寻zeppelin的设计动因和它要解决的问题。
首先看一下该平台要应对的典型场景:
平台要解决的是:在服务端资源一定的情况下,如何尽可能正确和高效地执行多个用户混合了多种语言的Notes问题。