您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
   
 
     
   
 订阅
  捐助
Zeppelin架构原理分析
 
 
270 次浏览     评价:  
2020-8-31 
 
编辑推荐:
本文重点介绍zeppelin整体架构分析,Interpreter组件以及Note模块主要功能,SparkInterpreter的工作原理,希望对您的学习有所帮助。
本文来自程序员大本营,由火龙果软件Alice编辑、推荐。

一、Zeppelin整体架构分析

首先上一张官方给出的Zeppelin整体架构图

Apache Zeppelin的架构比较简单直观,总共分为3层:

1.Zeppelin 前端

2.Zeppelin Server

3.Zeppelin Interpreter

Zeppelin前端是基于AngularJS(目前社区正在升级改造前端,但是对用户体验不会有影响)。

Zeppelin Server是一个基于Jetty的轻量级Web Server,主要负责以下一些功能:

1.登陆权限管理

2.Zeppelin配置信息管理

3.Interpreter 配置信息和生命周期管理

4.Note存储管理

5.插件机制管理

Zeppelin前端和Zeppelin Server之间的通信机制主要有Rest api和WebSocket两种。Zeppelin Server和Zeppelin Interpreter是通过Thrift RPC来通信,而且他们彼此之间是双向通信,Zeppelin Server可以向Zeppelin Interpreter发送请求,Zeppelin Interpreter也可以向Zeppelin Server发送请求。

关于zeppelin采用WebSocket技术的必要性问题,这里也做一下简单分析。zeppelin是共享式、Notebook式的大数据分析环境,以repl的方式执行以Paragraph为最小粒度的代码段。

1. 首先repl的方式强调实时反馈执行结果,特别是在大数据环境下,一段代码可能需要执行很长时间,在执行的过程中,zeppelin的用户期望看到执行进度和中间结果,需要在前后端之间建立一个长连接,便于实时传递数据。

2. 另外zeppelin的另一个亮点是其结果可视化能力,需要在前后台传递图片,并且支持较大数据量的传输的能力(相对传统http技术)。

3. 再者,由于是共享式环境,一个Note可能被多个用户同时看到、甚至编辑,需要在各个已经打开了同一个Note的web客户端之间同步Note的代码、执行结果和进度信息。

基于以上3点,zeppelin采用WebSocket技术是水到渠成的事情。

上图是zeppelin的前后台交互模型,zeppelin采用单独的jvm来启动interpreter进程,该Interpreter进程与zeppelinServer进程之间采用Thrift协议通信,其中RemoteInterpreterProcess是Thrift-Client端,而相应的RemoteInterpreterServer是Thrift-Server端。每一个Interpreter都属于换一个InterpreterGroup,同一个InterpreterGroup的Interpreters可以相互引用,例如SparkSqlInterpreter 可以引用 SparkInterpreter 以获取 SparkContext,因为他们属于同一个InterpreterGroup。当前已经实现的Interpreter有spark解释器,python解释器,SparkSQL解释器,JDBC,Markdown和shell等。

二、Zeppelin-interpreter

2.1、Interpreter概念

Interpreter组件是指各个计算引擎在Zeppelin这边的适配。比如Python,Spark,Flink等等。每个Interpreter都run在一个JVM进程里,这个JVM进程可以是和Zeppelin Server在同一台机器上(默认方式),也可以run在Zeppelin集群里的其他任何机器上或者K8s集群的一个Pod里,这个由Zeppelin的不同InterpreterLauncher插件来实现。InterpreterLauncher是Zeppelin的一种插件类型。

Interpreter支持动态加载maven格式依赖包的能力,多JVM隔离runtime依赖。Thrift-Based跨语言IPC(Inter-Process-Communication)机制(规定repl解释器集成和平台之间的数据交换的格式和时序)。抽象出repl解释器生命周期管理接口,各repl解释器受zeppelinServer端控制。

每一个Interpreter都有一个对应的Scheduler实例,Scheduler将Job的提交与执行变成了一个异步的过程,即Job在Scheduler处进入队列等待提交,用户可以定期收到Job执行相关的信息。Zeppelin内部有三种Scheduler:

1.FIFOScheduler: 适用于Paragraph只能顺序执行的Interpreter,如SparkInterpreter, ShellInterpreter等。

2.ParallelScheduler: 适用于Paragraph可并行执行的Interpreter,如SparkSqlInterpreter, MarkdownInterpreter等。

3.RemoteScheduler: 与RemoteInterpreterProcess配合使用的,RemoteInterpreterProcess以独立的进程启动Interpreter,其内部同样运行了调度器,由于zeppelinServer运行在主进程中,与远程Interpreter进程(通过RemoteInterpreterServer启动的jvm,注意:不是运行InterpreterProcess类所在的进程,InterpreterProcess仍然运行在与ZeppelinServer相同的主进程中)不在同一个进程。RemoteScheduler的作用就作为运行在远程Interpreter进程的远程代理,RemoteScheduler与ZeppelinServer运行在同一个JVM进程中,负责向ZeppelinServer提供远程Interpreter进程中调度器的内部运行情况。

关于为什么要采用单独的JVM进程来启动repl解释器,原因有以下两点:

1.zeppelin旨在提供一个开放的框架,支持多种语言和产品,由于每种语言和产品都是各自独立演进的,各自的运行时依赖也各不相同,甚至是相互冲突的,如果放在同一JVM中,仅解决冲突,维护各个产品之间的兼容性都是一项艰巨的任务,某些产品版本甚至是完全不能兼容的。

2.大数据分析,是否具有横向扩展能力是production-ready一项重要的衡量指标,如果将repl进程与主进程合在一起,会验证影响系统性能。

因此,在有必要的时候,zeppelin采用独立JVM的方式来启动repl进程,并且采用Thrift协议定义了主进程ZeppelinService与RemoteInterpreterService进程(解释器进程)之间的通信协议。

2.2、Interpreter模块其他部分概念

InterpreterFactory:维护所有Interpreter的配置信息并存储在interpreter.json文件中,并管理所有的Interpreter

InterpreterGroup:一个InterpreterGroup中包含多个Interpreter,同组内的Interperter共享相同的配置信息,例如Spark和SparkSQL interpreter在一个InterpreterGroup内。

InterpreterSetting:一个InterpreterGroup会有一个InterpreterSetting,其中包含着相应的配置信息,例如Spark Master。

所有的InterpreterSetting都被持久化在Interpreter.json文件里。用于维护Note与InterpreterGroup直接的绑定关系,即每篇Note可以绑定不同的InterpreterGroup.

InterpreterContext:用于存储Paragraph相关的信息,Interpreter在具体解析执行Paragraph时会用到InterpreterContext。

InterpreterResult:用于存储Job的状态信息以及执行结果,具体包括:

状态码:SUCCESS,INCOMPLETE,ERROR,KEEP_PREVIOUS_RESULT

类型:Text(Default),Table,Html,Angular等

内容:字符串数组

三、Zeppelin-Note

3.1、Note模块概念

Notebook部分有一些重要的概念是需要理解的:

Notebook Server:用于建立并维护前端网页与后端服务器之间的Websocket连接;它其实是一个job listener,接收并处理前端网页发来的Note执行请求,在后端生成并执行相应的job,并将job执行的状态信息广播到所有的前端页面。

Message:Message类是前端网页与后端Notebook Server之间的通信协议,传输在Websocket上,主要用于描述Note执行相关的信息。

Notebook,Note,Paragraph,Job:

Notebook:Zeppelin认为整个运行实例是一个Notebook,其中可以用很多篇Note。

Note:每一篇Note就是一个具体的页面,其中可以有很多个Paragraph,就是代码段落。

Paragraph:每一个Paragraph就是一个代码段落,因此Paragraph是一个可执行单元,等同于一个Job。

Job:Job是Zeppelin后端调度和执行的单位,会在具体的Interpreter上运行。

3.2、Note模块主要功能

Note是单个’记事本’的内存对象,是zeppelin管理的最小单位,无论是做权限控制、共享、还是持久化,都是以Note为粒度的。从类关系上看,Note是由一些列的有序Paragraph组成,因此其绝大部分职责都是与管理Paragraph有关:

1. Paragraph的CRUD、相对顺序控制

2. 与处理前后端数据双向推送的AngularObject的管理

3. 整体和单个Paragraph 执行,以及执行过程的基于Observer模式的执行过程Hook

4. Note基本的样式外观控制

为了“分离关注点”,其他的功能,如:

1. Note相关的Interpreter加载和初始化

2. 持久化与反持久化,包括延迟持久化

3. 权限控制

四、Zeppelin-paragraph

Paragraph代表着一段代码以及支撑其执行所需要的“环境信息”,是代码执行的最小单位。Paragraph的职责如下:

1. 获取代码文本,并解析分离类似%spark的interpreter声明段和可执行代码段。

2. 代码执行,以及执行过程控制(进度和终止)

3. 代码执行结果获取

4. 代码中变量查找以及替换

五、一次Query的执行过程

以SparkInterpreter举例

SparkInterpreter的工作原理如下:

1.内部基于SparkILoop以及SparkIMain实现,功能类似于Spark-Shell,即逐行的解析代码。

2.用zeppelin-<Interpreter hash code>-<Paragraph Id>作为Spark中的Job Group Id,进而用Job Group Id来从SparkContext中获取执行进度信息。

3.将SparkInterpreter进程内创建的SparkContext绑定到SparkIMain里面,进而预定义一些环境配置以及语法糖,例如ZepplinContext。

4.用ByteArrayOutputStream来捕获SparkIMain的输出,并转化为可显示的输出结果。

SparkSqlInterpreter的工作原理如下:

1.运行在SparkInterpreter之上,即在SparkInterpreter中运行SqlContext或者HiveContest

2.SparkSqlInterpreter的执行结果都会以Table的类型返回给前端,因此前端页面会用相应的Angular JS代码将结果呈现为图表。

 
   
270 次浏览     评价: 订阅 捐助
相关文章

我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
 
相关文档

数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
相关课程

高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
最新课程计划
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...