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

1元 10元 50元





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



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
Zeppelin架构原理分析
 
 
  1721  次浏览      
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代码将结果呈现为图表。

 
   
1721 次浏览       
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

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