指定表和分区来预先缓存,查询分析更高效 | 学习笔记

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 快速学习指定表和分区来预先缓存,查询分析更高效。

开发者学堂课程【数据湖 JindoFS + OSS 实操干货36讲指定表和分区来预先缓存,查询分析更高效】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/833/detail/13974


指定表和分区来预先缓存,查询分析更高效


内容介绍

一、背景介绍

二、功能介绍

三、实观原理

四、实操演示


一、背景介绍

1.1传统集群架构  

 存储计算一体  

 存储量与计算量无法始终匹配  

 存储无法水平扩展  

计算节点 计算节点 计算节点

NodeManager NodeManager NodeManager

DataNode DataNode DataNode

为什么需要指定表和分区来预先缓存,首先讲一下传统的集群架构。

传统的大数据分析,通常采用存储、计算一体的方式,计算节点上既有存储服务,也有计算服务。

这种方式存储量和计算量没法做到始终匹配,比如扩充一台节点,就需要计算资源和存储资源一起。

然后第二点,它存储服务无法做到水平扩展,因为受到 HDFS 的单点限制,集群扩大到一定规模的时候就无法继续扩展,因为一般它都将原数据都保存在内存,单机的内存毕竟是有限的,现在我们通常建议采用的是存算分离的架构。

1.2存算分离架构  

 计算资源动态伸缩  

 海量的存储空间  

 稳定可靠的存储服务  

 计算节点剩余的磁盘、内存资源可以用于缓存加速  

计算节点 计算节点 计算节点

NodeManager NodeManager NodeManager

缓存 缓存 缓存

OSS 对象存储

计算节点上只部署计算服务,部署存储服务存储,使用远端的OSS对象存储。

这种方式,有四个优点

第一点,是计算资源,可以动态的扩缩容释放节点,不会导致数据丢失。

第二,它具有海量的存储空间,OSS的存储空间非常大。

第三,OSS 的服务非常稳定可靠。

第四,点式计算节点,剩余的磁盘内存资源可以用于缓存加速,利用缓存加速,我们可以同时利用本地磁盘 OS 的贷款,提高计算速度。

这是 TBCDS 生成的一份标准输仓的数据,其中的围表,比如说是比较经常访问的,因此我们可以先缓存适时表,通常采用时间分区,对于接近最近几天的数据,也可以预先缓存有一些比较老的,比如说一两个月之前的数据,是比较冷的,这些数据只保存在 OSS 就可以了。


二、功能介绍

 Jindo Namespace Service  

 Jindo Storage Service  

 Jindo SDK

JindoFS缓存服务的架构图,包含三个部分,Namespace服务保存文件的元数据和缓存原始信息的元数据。

Jindo SDK 是客户端,部署spark服务上。

Storage服务负责管理缓存块的数据,整个流程是计算服务,通过Jindo SDK访问数据,记录 SDK,从Namespacs服务查询缓存位置信息,然后向集群中的 storage 服务,读取出缓存数据,如果命中缓存直接返回,如果没有命中缓存,则从OSS读取数据,并且将缓存写入到 storage 服务供下次使用。


三、实观原理

 部署缓存服务  

1. 下载最新 Release 包 b2smartdata-x.x.x.tar.gz,解压并部署到集群所有节点上  

2. 修改配置文件conf/bigboot.cfg

[bigboot-storage]  

storage.rpc.port - 6101  

storage.data-dirs =/mnt/disk1/bigboot,/mnt/disk2/bigboot,/mnt/disk3/bigboot,/mnt/disk4/bigboot  

storage.data-dirs.capacities = 527371075584,527371075584,527371075584,527371075584

storage.namespace.rpc.address = emr-header-1:8101  

storage.watermark.high.ratio-0.4 storage.watermark.low.ratio-0.2  

[bigboot-namespace] namespace.rpc.port = 8101  

namespace.meta-dir =/mnt/disk1/bigboot  

3. 修改 sbin/nodes,配置所有storage service的节点列表  

4. 启动所有服务./sbin/start-service.sh  

详细文档可参考:https://github.com/aliyun/alibabacloud-jindofs/blob/master/docs/jindofs_cache_mode deploy.md

 部署Jindo SDK  

1. 安裝jar包:下载最新的jar包 jindofs-sdk-xx.xjar,在所有 Hadoop 节点安裝。  

cp ./jindofs-sdk-*.jar/share/hadoop/hdfs/lib/jindofs-sdkjar  

2. 配置 JindoFS 实现类:将 JindoFS 实现类配置到Hadoop的core-site.xml中。  

3. 将 OSS 的 A ccess Key、Access Key Secret、Endpoint 等预先配置在 Hadoop 的core-site.xml中。

 指定表和分区来预先缓存

-cache  

•语法  

jindo table -cache {-t}[-p] 【-pin]  

•功能  

表示缓存指定表或分区的数据至集群本地磁盘上。  

表或分区的路径需要位于 OSS 或 JindoFS。指定表时使用 database.table 的格式;指定分区时使用 partitionCol1  

=1,partitionCol2=2,...的格式;指定-pin 时,在缓存空间不足时尽量不删除相关数据。  

•示例:缓存2020-03-16日db1.t1表的数据至本地磁盘上。  

jindo table -cache -t db1.tl -p date=2020-03-16  

-uncache  

•语法  

jindo table -uncache {-t}[-p]  

•功能  

表示删除集群本地磁盘上指定表或分区的缓存数据。  

对应的路径需要位于 OSS 或  JindoFS。指定表时使用 database.table 的格式,指定分区时使用 partitioncol1=1,  

partitionCol2=2,...的格式。

相关资源  

JindoFS SDK https://github.com/aliyun/alibabacloud- jindofs/blob/master/docs/indofs _sdk download.md  

JindoFS 缓存服务 https://github.com/aliyun/alibabacloud- jindofs/blob/master/docs/indofs cache mode deploy.md


四、实操演示

下载最新版本的 SDK 和s martdate

程序安装好后进行配置部署

然后准备测试数据

Overview  

Start Time: Sun Jun 27 23:06:53 2021

Status:   Active

Meta Backend:  RocksDB (Standalone) emr-header-1.cluster-234515:8101 [192.168.0.30](Active)

Node:  Live Nodes:[3], Decommission Nodes:[0]  

Version:  3.6.0

Build No:  1d2d462e9844d63d587127504ece7c87b58ad/42

Namespace Info (3)  

Namespace: ifs:/ftest/  

Namespaces:  test

Mode:  BLOCK_MODE

Backend URI:  oss://chengli-sh-test/uyue/C-DBD8BBF30589E5BE  

Summary:  Directory Count:[1], File Count: [0], File Size:[0], Task Count:[0], Computed at 2021-06-27 23:07:01

Storage Overview  

Node: emr-worker-2.cluster-234515:6101

Start Time:  Sun Jun 27 23:06:53 2021

Status: online  

Version:  3.6.0

Build Version: 1d2d462e9844d63d587f27504ece7c87b58adf42

Storage Lists (1)  

Volume Storage Type Used/Capacity  Last Eviction Time  Diskid

/mnt/disk1/bigboot Disk oBRp3.57 GB

 1

 

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
19天前
|
缓存 Java Shell
Android 系统缓存扫描与清理方法分析
Android 系统缓存从原理探索到实现。
43 15
Android 系统缓存扫描与清理方法分析
|
17天前
|
缓存 监控 NoSQL
Redis 缓存穿透的检测方法与分析
【10月更文挑战第23天】通过以上对 Redis 缓存穿透检测方法的深入探讨,我们对如何及时发现和处理这一问题有了更全面的认识。在实际应用中,我们需要综合运用多种检测手段,并结合业务场景和实际情况进行分析,以确保能够准确、及时地检测到缓存穿透现象,并采取有效的措施加以解决。同时,要不断优化和改进检测方法,提高检测的准确性和效率,为系统的稳定运行提供有力保障。
46 5
|
1月前
|
存储 缓存 索引
从底层数据结构和CPU缓存两方面剖析LinkedList的查询效率为什么比ArrayList低
本文详细对比了ArrayList和LinkedList的查询效率,从底层数据结构和CPU缓存两个方面进行分析。ArrayList基于动态数组,支持随机访问,查询时间复杂度为O(1),且CPU缓存对其友好;而LinkedList基于双向链表,需要逐个节点遍历,查询时间复杂度为O(n),且CPU缓存对其帮助不大。文章还探讨了CPU缓存对数组增删操作的影响,指出缓存主要作用于读取而非修改。通过这些分析,加深了对这两种数据结构的理解。
35 2
|
3月前
|
存储 缓存 关系型数据库
查询缓存效果
【8月更文挑战第14天】
34 2
|
3月前
|
存储 缓存 NoSQL
微服务复杂查询之缓存策略
微服务复杂查询之缓存策略
|
3月前
|
缓存 NoSQL 网络协议
【Azure Redis 缓存】Azure Redis Cluster 在增加分片数时失败分析
【Azure Redis 缓存】Azure Redis Cluster 在增加分片数时失败分析
|
3月前
|
存储 缓存 NoSQL
【Azure Redis 缓存】当使用Azure Redis 集群服务时候,发生了Moved的几点分析
【Azure Redis 缓存】当使用Azure Redis 集群服务时候,发生了Moved的几点分析
|
3月前
|
缓存 关系型数据库 MySQL
【缓存大对决】Memcached VS MySQL查询缓存,谁才是真正的性能之王?
【8月更文挑战第24天】在现代Web应用中,缓存技术对于提升性能与响应速度至关重要。本文对比分析了Memcached与MySQL查询缓存这两种常用方案。Memcached是一款高性能分布式内存对象缓存系统,支持跨服务器共享缓存,具备灵活性与容错性,但受限于内存大小且不支持数据持久化。MySQL查询缓存内置在MySQL服务器中,简化了缓存管理,特别适用于重复查询,但功能较为单一且扩展性有限。两者各有所长,实际应用中可根据需求单独或结合使用,实现最佳性能优化。
112 0
|
3月前
|
缓存 Java 数据库连接
Hibernate 中的查询缓存是什么?
【8月更文挑战第21天】
35 0
|
3月前
|
缓存 数据库 SQL
查询缓存 面试准备
【8月更文挑战第13天】
30 0