架构组件&查询处理流程 | 学习笔记

简介: 快速学习 架构组件&查询处理流程

开发者学堂课程【大数据Impala教程架构组件&查询处理流程学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/722/detail/12885


架构组件&查询处理流程


内容介绍:

一、Impala 架构

二、CLI

三、Impalad

四、Impala State Store

五、Catalogd

六、总体结构

七、Impala 查询处理过程

 

一、Impalad 架构

Impala 的架构以及查询处理的过程。从架构层面分析 Impala,非常的清晰,大致可以分为四个模块。

 

二、CLI

首先看一下最后一个模块叫做 CLI ,这是一个命令行的方式。

既然是一款提供用户写 SQL 查询数据的软件,必须给出一种方式去写 SQL,当下 Impala 有这几种方式,最传统的是 Shell 命令行,在这个方面可以执行相关的售后语句,传递给 Impala 服务器进行咨询,此外提供了跟整 Hue 合,在 Hue 上进行查询的能力,包括 JAVA API 方式进行访问,属于外围操作的客户端。

 

三、Impalad

重点看一下自身所携带的三个架构服务模块。第一个叫做 Impalad,通俗理解,可以把它叫做 Impala Server 服务器,它是一个集群的概念,可以部署在任何集群上,也可以部署在多个。

image.png

1.Impalad 来源

通常会把 Impala 服务器部署在跟 Datenode 在同一个节点上,在它的底层上,Impala 追求计算的高效率,尽量要求满足能够在本地计算。把 Datenode 放在 A 机器上,把Impala 安装在 B 机器上,这两台机器之间需要跨网络去读数据,通常把 Impala 服务与 Datenode 部署在同一个节点上,这台机器上的服务的进程叫做 Impalad

2.指责明细

Impalad 的职责明细,主要用于第一点接收用户的 SQL 请求。要去操作 Impala 服务到底连接到哪台机器上,比如说现有 abc 三台机器都部署在 Impala,这时候指定连接到哪台机器,那台机器的 Impalad 负责查询需求,返回结果。当我们没有用户去连接的时候,它就是一个普通的Impala 服务叫做 Impalad

3.Coordinator

一旦接受到请求负责后续的查询,这时候把这台接收为查询请求的称作为 Coordinator 协调者。例如,我们三个本来都是普通的 Impala 服务,当中如果必接受请求,就针对这次的请求,它负责给出后续的协调处理。接收请求,编译成为查询计划树,调用其他 Impala 进行数据的咨询,返回结果。负责本次具体查询的 Impalad 叫做 CoordinatorImpalad 通过我们的本地调用,把身后语句转换为计划树传给后端,后端读数据,进行并行的咨询查询,把结果返回给前端。这是 Impalad 的职责。

 

四、Impala State Store

1.概念

Impala 的第二个架构叫状态存储。状态概念是由于当在多个机器上都去部署 Impala 服务 Impalad 后,就产生一个问题,哪个是存活的,哪个是死亡的,Impala 服务健康状态如何,这时候如何知道,因此需要一个进程去管理他,这个进程叫做 Impala State Store 状态存储服务。

2.内容

主要去保存整个 Impala 集群中,每个 Impalad 的健康状况以及它位于的机器的位置信息。比如,整个机器有100台。在奇数台当中不属于 Impalad ,这些 Impalad 都要跟 State Store 进行新教,包括注册,汇报信息,是成功还是失败。在 State Store 当中,会有一个表对数据进行记录。每个 Impalad 服务的健康状况,与此同时,每一个 Impalad 自己本地也会缓存一份 State Store 中的信息。缓存的原因是接收到用户请求之后,需要协调其他部分一起进行数据计算。正因为不知道有哪些部分,所以都会去缓存一份状态信息,通过信息可以知道当下整个渠道当中。除了自身之外还有其他的 Impalad。有一个数据在那里,需要计算一下,再将结果返回,因此就会缓存一份状态信息。

3.恢复模式

这时候有一个现象需要注意一下,一旦 State Store 进程属于离线,这时候会有一个 recovery 恢复的模式,在恢复模式下已经缓存的可以继续的工作,但缓存之后进程已经结束了,数据不会接着更新。因此如果这时候突然某个部分结束了进程,拿到的是缓存之前的数据,数据就不会更新。所以导致一些执行机而分配的时候会出错,分配给 A 其实 A 已经结束了进程。所以进入恢复模式下,会不断进行尝试,等待 State Store 的启动。这是第二个模块,用来追踪整个集群当中,Impalad 的健康状况以及它的位置信息。


五、Catalogd

第三个模块叫做 Catalogd ,这个模块是 Impala 后续内容新加的,它相当于一个媒介用来维护 Impala 元数据与 Hive 的元数据。虽然 Impala 最终使用的是跟 Hive 的同一个元数据,但这时候需要做一个中间的协调者。就是这个一个进程叫做Catalogd,会把 Hive 当中的元数据拉取过来,放到 Impala 自己的元数据中。如果 Impala 中的元数据涉及到更新,也会把它同步到 Hive 当中。这样相当于做了一个网关,维护着 Impala 本身的元数据与 Hive 的元数据。但是反过来,比如在 Hive 中做了一个修改,它不能自己主动地拉取过来,需要进行强制的刷新或是按照命令指定的刷新,这是一个架构。

 

六、总体结构

1.交互

如果画一个图,数据架构大概可以理解为部署三台服务器。分别是 node-1node-2node-3。每个机器上首先都有一个存储数据的节点 dn。接下来部署 Impalad 服务,首先第一个 Impalad,通常与 DateNode 在同一个节点上而可以部署多个。在每个 DateNode 位置上可以部署一个叫 Impalad 的服务,可以部署多个。部署完之后,node-1上有一个,同样剩下的机器上都要部署同样的,它可以在本地进行数据处理交互。

2.进程

第二点,部署一个状态存储的进程,这个进程主要是维护进程中哪个死亡,哪个健康,比如,这里找一台 node-3机器,再增加一个进程,叫做 State Store,其他的 Impalad 服务启动之后,就要向它进行注册,叫做注册 Impalad 的状态信息并且维持心跳保持联系。这一个维持心跳的目的是知道是活还是死亡,比如心跳超时,说明这个节点有问题,而且反过来每一个 Impalad 当中,还会维护的一个状态信息的缓存。

3.网关

第三个模块叫做 Catalogd ,主要是一个元数据访问的网关。在画布上增加一台机器,这台机器叫做 node-4,这上面主要是有 Hive metastor,那么这时候作为 Impalad 服务,它需要一个进程,维护着跟 Hive 之间的关系。例如,简单画一个 Catalogd,它会通过自身跟 Hive 元数据进行交互,维护的网关。比如,有数据需要更新,把它拉过来做一个维护,最终来说使用的是同一个 Hive metastor 元数据。

4.客户端

需要新增一个 Impala client (shell hue jdbc)客户端。当下用的最多的客户端是 shell 命令行,但不只有 shell 客户端,通过 hue 整合和 jdbc 都可以。作为客户端,不管在哪个机器上,当连接到任何一个 Impala 机器上都可以进行访问。比如将其连接到 node-2 Impalad 之后,就可以写 Impala SQL。把 SQL 发送出去,这时候接收到的 Impalad 就是上文提到的谁接收 Impalad 请求,谁就称之为 Coordinator, 在这种情况下,第二台机器的 Impalad,它就有一个别名是负责本次查询的 Impalad ,称之为 Coordinator,它就会针对 Impalad SQL 做一个解析,编译成执行计划树。在执行计划树中让其他部分进行处理,比如,发送了 SQL 需要计算一个数据,数据在另外的机器上,就会需要帮助计算再返回结果。这样就完成了一个配合。这就是整个 Impalad 的架构,看起来非常简单,也是一个集群的状态。

 

七、Impala 查询处理过程

接下来有了这个架构之后,处理其它的查询流程就非常的简单,非常清晰。准确来说,每个 Impalad 服务分为两个部分,叫做 Java 前端与 c++ 处理的后端。对于 Java 这一端比较熟悉,对于 c++ 不用担心,也不用管理。怎样进行查询处理。

image.png

1.三种方式

首先进行 Impalad CLI ClientODBC/JDBC DriverHue Beeswax 这三种交互的方式,当写下 SQL 回车,SQL 语句就会提交给 Impalad 服务。

2.协调者

每个 Impalad 服务都与 DateNode 位于同一个节点上,但是连接的时候必须要指定一个 Impalad,不管指定谁。比如说指向第三个,负责接受 SQL 提交的 Impalad,称之为 Coordinator 协调者,协调帮助执行的 SQL

3.计划树

接收到 SQL 后,协调者调用 JNI 方法去处理 SQL,把它解析成一个执行计划树,编译好之后会把这个树,以 Thrift 格式返回给 C++后端,每个 Impalad 服务分为 Java 前端和 C++后端。真正进行数据处理的是 C++后端。这个执行计划树中,类似于树结构当中有不同的阶段,每个阶段可以并行执行,有的必须按照顺序执行。整个执行计划树,根据编译分配规则,有的数据在这里,有的数据在那里,把具体的执行逻辑交给不同的 Impalad 进行执行。

4.数据存储

根据执行计划,数据位于的路径。要提交一个 SQL 查询表,表的数据位于另一台机器的 DateNode 上,它知道数据在这里的原因是,数据存储信息 Impala 底层通过 libhdfs HDFS 进行交互。交互的时候就知道,要查询一个数据文件,会了解到这个文件被切成了几块,分别在第一台机器上还是第二台机器。Impalad 服务通过查询发现在机器上有一个数据块是需要计算的。这样叫做协调者,协调由哪个 Impalad 来具体的进行查询,查询之后把结果进行返回。

5.insert 语句

如果不是查询语句而是一个插入语句,这个数据最终要写到 HDFS 上。在底层还会调用 libhdfs ,把数据写到 HDFS 上。就完成了整个的查询,把最终汇总的结果返回给客户端,就得到了结果。当中每个 Impalad 必须要跟状态服务器 State Store 做一个注册和心跳的保持联系。因为不保持联系的话,就不知道哪个已经发生了故障,哪个已经死去。这就是整个查询处理过程,结合架构以及图示做了解即可。

相关文章
|
25天前
|
存储 数据库 Android开发
构建高效安卓应用:采用Jetpack架构组件优化用户体验
【4月更文挑战第12天】 在当今快速发展的数字时代,Android 应用程序的流畅性与响应速度对用户满意度至关重要。为提高应用性能并降低维护成本,开发者需寻求先进的技术解决方案。本文将探讨如何利用 Android Jetpack 中的架构组件 — 如 LiveData、ViewModel 和 Room — 来构建高质量的安卓应用。通过具体实施案例分析,我们将展示这些组件如何协同工作以实现数据持久化、界面与逻辑分离,以及确保数据的即时更新,从而优化用户体验并提升应用的可维护性和可测试性。
|
2月前
|
存储 监控 安全
金石推荐 | 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式
金石推荐 | 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式
73 1
|
2月前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
34 0
|
2月前
|
NoSQL Java Redis
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件(二)
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件
15 0
|
2月前
|
SpringCloudAlibaba 负载均衡 Java
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(目录大纲)
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(目录大纲)
69 1
|
2月前
|
Java Nacos Sentinel
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(九)Nacos+Sentinel+Seata
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(九)Nacos+Sentinel+Seata
220 0
|
2月前
|
消息中间件 SpringCloudAlibaba Java
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
786 0
|
2月前
|
SpringCloudAlibaba Java 网络架构
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(七)Spring Cloud Gateway服务网关
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(七)Spring Cloud Gateway服务网关
115 0
|
22小时前
|
设计模式 Kubernetes 数据库
构建高效可靠的微服务架构:后端开发的新范式
【5月更文挑战第7天】在现代软件开发的浪潮中,微服务架构已经成为一种流行的设计模式。它通过将应用程序分解为一组小的、独立的服务来提高系统的可维护性和扩展性。本文深入探讨了微服务架构的核心概念、优势以及如何利用最新的后端技术构建一个高效且可靠的微服务体系。我们将讨论关键的设计原则,包括服务的独立性、通信机制、数据一致性和容错性,并展示如何在云环境中部署和管理这些服务。
|
1天前
|
监控 负载均衡 数据安全/隐私保护
探索微服务架构下的服务网格(Service Mesh)实践
【5月更文挑战第6天】 在现代软件工程的复杂多变的开发环境中,微服务架构已成为构建、部署和扩展应用的一种流行方式。随着微服务架构的普及,服务网格(Service Mesh)作为一种新兴技术范式,旨在提供一种透明且高效的方式来管理微服务间的通讯。本文将深入探讨服务网格的核心概念、它在微服务架构中的作用以及如何在实际项目中落地实施服务网格。通过剖析服务网格的关键组件及其与现有系统的协同工作方式,我们揭示了服务网格提高系统可观察性、安全性和可操作性的内在机制。此外,文章还将分享一些实践中的挑战和应对策略,为开发者和企业决策者提供实用的参考。