Hbase性能调优(二)
一、HBase关键参数配置指导
如果同时存在读和写的操作,这两种操作的性能会相互影响。如果写入导致的flush和Compaction操作频繁发生,会占用大量的磁盘IO操作,从而影响读取的性能。如果写入导致阻塞较多的Compaction操作,就会出现Region中存在多个HFile的情况,从而影响读取的性能。所以如果读取的性能不理想的时候,也要考虑写入的配置是否合理。
1、提升写效率
1.1客户端调优
1.1.1 AutoFlush
参数值:setAutoFlush
解析:
autoflush=false的原理是当客户端提交delete或put请求时,将该请求在客户端缓存,直到数据超过2M(hbase.client.write.buffer决定)或用户执行了hbase.flushcommits()时才向regionserver提交请求。因此即使htable.pu()执行返回成功,也并非说明请求真的成功了。假如还没有达到该缓存而client崩溃,该部分数据将由于未发送到regionserver而丢失。这对于零容忍的在线服务是不可接受的。
autoflush=true虽然会让写入速度下降2-3本,但是对于很多在线应用来说这都是必须打开的,也正是hbase为什么让它默认为true的原因,每次请求都会发往regionserver,而regionserver接收到请求后第一件事情就是写HLOG。因此对IO要求是非常高的,为了提高hbase的写入速度应该尽可能地提高IO吞吐量,比如增加磁盘、使用raid卡、减少replication因子数等。
如何调优?
经验设定:
setAutoFlush=false
1.1.2使用PutList方式提交请求
可以极大地提升写性能
1.2 Memstore相关
当regionserver(以下简称为RS)收到一个写请求,会将这个请求定位到某个特定的region。每一个region存储了一系列的Row,每一个Row对应的数据分散在一个或多个ColumnFamily(以下简称为CF)。特定CF的数据都存储在对应的store里面,而每个store都是由一个memstore和数个storefile组成。memstore存储在RS的内存中,而storefile则存储在HDFS上。当一个写请求到达RS的时候,该请求对应的数据首先会被menstore存储,直到达到一定的临界条件,memstore里面的数据才会flush到storefile。
使用memstore的主要原因是为了使存储在HDFS上的数据是有序的(按Row)。HDFS设计为顺序读写的,已有的文件不能被修改。这就意味着,因为hbase收到的写请求是无序的,所以如果直接将这些数据写到HDFS上,以后再对文件里面的内二做排序就会是一件极其困难的事情;无序的数据存储方式,又会大大影响后续的读请求性能。为了解决这种问题,hbase会将最近的某些写请求放到内存中(也就是memstore),并将这些数据在flush到storefile之前做好排序。
除了解决排序的问题,memstore还有其他好处,比如:
它能充当memcache的角色,缓存最近写入的数据。鉴于新数据的访问频率和几率都比旧数据高很多,这就大大的提高客户端的读效率。
注意:每个memstore每次刷新时,都会给CF生产一个storefile。
剩下读取就非常容易了,hbase会检查数据是否在memstore里面,否则就去storefile读取,然后返回给客户端。
1.2.1 根据memstore大小flush hfile
参数值:hbase.hregion.memstore.flush.size
参数解析:
在regionserver中,当写操作内存中存在超过memstore.flush.size大小的memstore,则MemstoreFlusher就启动flush操作将该memstore以hfile的形式写入对应的store中。
如何调优?
默认:128M
A、如果Regionserver的内存充足,而且活跃Region数量也不是很多的时候,可以适当增大该值,可以减少compaction的次数,有助于提升系统性能。
B、这种flush产生的时候,并不是紧急的flush,flush操作可能会有一定延迟,在延迟期间,写操作还可以进行,Memstore还会继续增大,最大值 = “memstore.flush.size” * "hbase.hregion.memstore.block.multiplier"。
C、当超过最大值时,将会阻塞写操作。适当增大“hbase.hregion.memstore.block.multiplier”可以减少阻塞,减少性能波动。
参数值:hbase.regionserver.global.memstore.size
参数解析:
RegionServer中,负责flush操作的是MemStoreFlusher线程。该线程定期检查写操作内存,当写操作占用内存总量达到阈值,MemStoreFlusher将启动flush操作,按照从大到小的顺序,flush若干相对较大的memstore,直到所占用内存小于阈值。
阈值=“hbase.regionserver.global.memstore.size” * "hbase.regionserver.global.memstore,size.lower.limit" * "Hbase_HEAPSIZE"
如何调优?
默认:0.4
该配置与“hfile.block.cache.size”的和不能超过0.8,也就是写和读操作的内存不能超过HeapSize的80%,这样可以保证除读和写以外其他操作的正常运行。
1.2.3 Flush前进行Compaction
参数值:hbase.hstore.blockingStoreFiles
参数解析:
在region flush前首先判断file文件个数,是否大于hbase.hstore.blockingStoreFiles。如果大于需要先Compaction并且让flush延时90s(这个参数可以通过hbase.hstore.blockingWaitTime进行配置),在延时过程中,将会继续写从而使得Memstore还会继续增大超过阈值(“memstore.flush.size” * "hbase.hregion.memstore.block.multiplier"),导致写操作阻塞。当完成Compaction后,可能就会产生大量写入。这样就导致性能激烈震荡。
如何调优?
默认:7
增加hbase.hstore.blockingStoreFiles,可以降低Block几率。
1.3 内存相关
Hbase利用内存完成读写操作。提高Hbase内存可以有效提高Hbase性能。
1.3.1 GC参数
参数值:GC_OPTS
参数解析:
GC_OPTS主要需要调整HeapSize的大小和NewSize的大小。
HMaster:
- -Xms512M -Xmx1G -XX:NewSize=64M -XX:MaxNewSize=128M
RegionServer:
- -Xms4G -Xmx6G -XX:NewSize=64M -XX:MaxNewSize=128M
如何调优?
A、挑战者HeapSize大小的时候,建议将Xms和Xmx设置成相同的值,这样可以避免JVM动态调整HeapSize大小的时候影响性能。
B、调整NewSize大小的时候,建议把其设置为HeapSize大小的1/9
C、HMaster:当HBase集群规模越大、Region数量越多时,可以适当调大HMaster的GC_OPTS参数。
D、RegionServer:RegionServer需要的内存一般比HMaster要大。在内存充足的情况下,HeapSize可以相对设置大一些。
经验设定:
主Hmaster的HeapSize为4G的时候,Hbase集群可以支持100000Region数的规模。根据经验值,单个RegionServer的HeapSize不建议超过20G。
1.4 HFile相关
1.4.1文件同步sync
参数值:hbase.regionserver.hfile.durable.sync
参数解析:
控制HFfile文件在写入到HDFS时的同步程度。如果为true,HDFS在把数据写入到硬盘后才返回:如果为false,HDFS在把数据写入OS的缓存后就返回。
如何调优?
默认为true
把该值设置为false比设为true时在写入性能上会更优。
1.5 Compaction相关
1.5.1Compact文件大小阈值
参数值:hbase.regionserver.thread.compaction.throttle
参数解析:
控制一次Minor Compaction时,进行compaction的文件总大小的阈值。
如何调优?
默认:1.5G
Compaction时的文件总大小会影响这一次compaction的执行时间,如果太大,可能会阻塞其他的compaction或flush操作。
1.5.2 Compact文件个数阈值
参数值:hbase.hstore.compaction.min
参数解析:
当一个Store中文件超过该值时,会进行compact。
如何调优?
默认:3
适当增大该值,可以减少文件被重复执行compaction,但是如果过大,会导致Store中文件数过多而影响读取的性能。
1.5.3 Compact文件数目
参数值:hbase.hstore.compaction.max
参数解析:
控制一次compaction操作时的文件数量的最大值。
如何调优?
默认:10
与“hbase.hstore.compaction.max.size”的作用基本相同,主要是控制一次compaction操作的时间不要太长。
1.5.4 Compact文件大小选择
参数值:hbase.hstore.compaction.max.size
参数解析:
如果一个HFle文件的大小大于该值,那么Minor Compaction操作中不会选择这个文件进行compaction操作,除非进行Major Compaction操作。
如何调优?
默认:2.5G
这个值可以防止较大的HFile参与Compaction操作。在禁止Major Compaction后,一个Store中可能存在几个HFile,而不会合并成一个HFile,这样不会对数据读取造成太大的性能影响。
1.5.5 Major Compaction执行周期
参数值:hbase.hregion.majorcompaction
参数解析:由于执行 Major Compaction 会占用较多的系统资源,如果正在处于系统繁忙时期,会影响系统的性能 。
如何调优?
默认: 24 小时
A. 如果业务没有较多的更新、删除、回收过期数据空间时, 建议设置为 0,以禁止Major Compaction。
B. 如果必须要执行 Major Compaction,以回收更多的空间,可以适当增加该值,同时配置参数“hbase.offpeak.end.hour”和“hbase.offpeak.start.hour”以控制 Major Compaction 发生在业务空闲的时期。
1.6 HLog相关
RS 上有一个 Write-ahead Log (以下简称 WAL),数据会持续的默认写到这个文件中。它包含了所有已经提交到 RS 的,已经保留在 memstore 中但是尚未 flush 到 storefile 的数据编辑历史。
这些在 memstore 中的,尚未持久化的数据,在 RS 发生错误时我们需要借助它进行恢复,它能重现这些尚未持久化的数据的编辑轨迹。 .
当 WAL(Hlog)变得非常大时,重现它的记录会花费非常多的时间。因此,我们需要限制WAL 的大小,当达到这个大小时,会触发 memstore 的 flush。
当数据 flush 到磁盘后,WAL 的大小就会变小,因为我们不需要再保存这些已经完成持久化的数据编辑记录。
1.6.1 文件同步sync
参数值:hbase.regionserver.wal.durable.sync
参数解析:
控制 HLog 文件在写入到 HDFS 时的同步程度。如果为 true, HDFS 在把数据写入到硬盘后才返回;如果为 false, HDFS 在把数据写入 OS 的缓存后就返回。
如何调优?
把该值设置为 false 比 true 在写入性能上会更优。
1.6.2 Hlog Flush条件
参数值:hbase.regionserver.maxlogs hbase.regionserver.hlog.blocksize
参数解析:
A、表示一个RegionServer上未进行Flush的Hlog的文件数量的阈值,如果大于该值,RegionServer会强制进行flush操作。
B、表示每个Hlog文件的最大大小。如果Hlog文件大小大于该值,就会滚动出一个新的Hlog,旧的将被禁用并归档。
如何调优?
这两个参数共同决定了RegionServer中可以存在的未进行Flush的hlog数量。WAL的最大容量 = hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize。当达到这个容量的时候,memstore flush就会被触发。因此,你在调整memstore的设置的时候,你同样需要调整这些值来适应那些编号。否则,WAL容量达到限制可能导致memstore flush的罪魁祸首,你专门配置memstore参数所增加的资源可能永远无法被物尽其用。这个时候可以适当调整这两个参数的大小。以避免出现这种强制flush的情况。
经验设定:
hbase.regionserver.maxlogs:默认32,建议调整为100
hbase.regionserver.hlog.blocksize:默认64M,建议调整为128M
1.7 表设计相关
1.7.1压缩算法
参数值:COMPRESSION
参数解析:配置数据的压缩算法,这里的压缩是HFile中block级别的压缩。对于可以压缩的数据,配置压缩算法可以有效减少磁盘的IO,从而达到提高性能的目的。
如何优化?
默认:None
并非所有数据都可以进行有效的压缩。例如一张图片的数据,因为图片一般已经是压缩后的数据,所以压缩效果有限。推荐使用SNAPPY,因为它有较好的Encoding / Decoding 速度和可以接受的压缩率。
实例:create 'test_table',{NAME => 'cf1', COMPRESSION => 'SNAPPY'}
1.7.2 Block大小
参数值:BLOCKSIZE
参数解析:
配置HFile中block块的大小,不同的block块大小,可以影响HBase读写数据的效率。越大的block块,配合压缩算法,压缩的效率就越好;但是由于HBase的读取数据是以block块为单位的,所以越大的block块,对应随机读的情况,性能可能会比较差。
如何调优?
默认:64Kb
如果要提升写入性能,一般扩大到128kb或者256kb,可以提升写数据的效率,也不会影响太大的随机读性能。
实例:create 'test_table',{NAME => 'cf1', BLOCKSIZE => '32768'}
1.7.3 缓存内存
参数值:IN_MEMORY
参数解析:
配置这个表的数据有限缓存在内存中,这样可以有效提升读取的性能。
如何调优?
默认:false
对于一些小表,而且需要频繁进行读取操作的,可以设置此配置项
实例:create 'test_table',{NAME => 'cf1', IN_MEMORY => 'true'}
2、提升读效率
2.1 客户端调优
A、Scan数据时需要设置caching(一次从服务端读取的记录条数,默认是1),若使用默认值读性能会降到极低。
B、当不需要读一条数据所有列时,需要指定读取的列,以减少网络IO
C、只读取Rowkey时,可以为Scan添加一个只读取Rowkey的filter(FirstKeyOnlyFilter或者KeyOnlyFilter)。
D、在客户端代码中,可以设置caching和batch用来提升查询效率。
例如:Scan.setCaching(caching);scan.setBatch(batch); 当 caching 和 batch 都为 1 的时候,我们要返回 10 行具有 20 列的记录,就要进行 201 次 RPC, 因为每一列都作为一个单独的 Result 来返回,这样是我们不可以接受的(还有一次 RPC 是用来确认 scan 已经完成) 。
a) RPC 次数公式: RPCs = (Rows * Cols per Row) / Min(Cols per Row, Batch Size)/Scanner Caching
2.2 内存相关
Hbase利用内存完成读写操作。提高HBase内存可以有效提高HBase性能。
2.2.1 GC参数
参数值:GC_OPTS
参数解析:
GC_OPTS主要需要调整HeapSize的大小和NewSize的大小。
HMaster:
- -Xms512M -Xmx1G -XX:NewSize=64M -XX:MaxNewSize=128M
RegionServer:
- -Xms4G -Xmx6G -XX:NewSize=64M -XX:MaxNewSize=128M
如何调优?
A. 调整 HeapSize 大小的时候,建议将 Xms 和 Xmx 设置成相同的值,这样可以避免 JVM动态调整 HeapSize 大小的时候影响性能。
B. 调整 NewSize 大小的时候,建议把其设置为 HeapSize 大小的 1/9。
C. HMaster:当 HBase 集群规模越大、 Region 数量越多时,可以适当调大 HMaster 的GC_OPTS 参数。
D. RegionServer: RegionServer 需要的内存一般比 HMaster 要大。在内存充足的情况下,HeapSize 可以相对设置大一些。
经验设定:
主 HMaster 的 HeapSize 为 4G 的时候, HBase 集群可以支持 100000Region 数的规模。根据经验值,单个 RegionServer 的 HeapSize 不建议超过 20GB
2.3 缓存相关
参数值:hfile.block.cache.size
参数解析:
HBase缓存区大小,主要影响查询性能。根据查询模式以及查询记录分布情况来解决缓存区的大小。
如何调优?
默认:0.25
如果采用随机查询使得缓存区的命中率较低,可以适当降低缓存区大小。
3、关键参数配置指导--案例
3.1 活跃Region对集群的影响
HBase在设计上,遵循了LSM-TREE的原理:写数据阶段,尽最大努力先将每一个Region的数据保留在内存(MemStore)中,等达到一定的阈值(默认为128M)之后,再 将这些数据固化(Flush)到文件(HFile)中,在这过程中,为了保证数据的安全性,通过将数据写入到一个人日志文件(Hlog)中:
在当前时间段可能被写入用户数据的Region,称作“活跃"Region”。
举例:
如果一个用户表的Region是按天划分的,那么,第一天的用户数据,只会被写入到第一天的Region中,则这些Region就是活跃的Region。此时,对于其它天的Region,都处于一种“空闲”的状态。
集群中每一个物理节点的内存资源都是有限的,每一个Region的数据都是暂时先保留在内存中然后再固化到HFile文件中的,因此,我们需要控制一个时间段的活跃的Region数目。如果Region过多的话,会导致内存资源紧张,每一个Region在内存中的数据可能还没有达到预先设置阈值的大小就被提前触发Flush操作,这会导致Flush频率升高,产生大量的小HFile(小文件过多会导致读取性能的直线下降,也会加大Compaction的频率和压力)。相反活跃Region过少的话,也会导致并发度提升不上去,读写性能偏低。
如何设置最合理的活跃Region数目?
需要根据MemStore Flush的阈值大小,以及RegionServer堆内存的大小、预留MemStore空间的大小进行合理的计算。
如下列子可以说明这种计算方法:
经验举例:
假设分配给RegionServer堆内存的大小为8G,MemStore所占空间比例为40%,MemStore Flush的阈值大小为128M,则合理的活跃Region数目约为8*1024*0.4/128=26(个/节点)。
以用户交易记录表为例。每一条用户交易记录关联一个USER_ID,也关联一个确切的交易时间点。
如果我们在设计Key值的时候,采用“USER_ID+TIME”的格式,则划分Region的时候,一定会按照USER_ID的范围划分的。对于任意一天的交易记录,可能涉及到各个范围内的USER_ID,即可能涉及到所有的Region,因此所有的Region都可能是活跃的,就会导致前面提到的那种活跃Region过多的问题,而且这种问题会随着时间的持续而不断恶化下去。
如果RowKey采用格式“DAY+USER_ID_TIME”的话,Region一定是按天划分的,那么,第N天的用户交易记录数据只会设计到第N天的Region,也只有这一天的Region是活跃的,这样就有力的控制了活跃Region数目:
4、定位调优
4.1日志收集
日志分类介绍:
当前HBase的日志保存在/var/log/Bigdata/HBase和/var/log/Bigdata/audit/hbase目录下,具体如下:
4、2调优定位
对于读写性能定位和调优,主要查看Regionserver的hbase-XXX-regionserver-XXX.log 运
行日志。
日志中是否出现过以下信息?
**Flush thread woke up with memory above low water.
日志中出现这个信息说明有部分写过程出现过阻塞等待的现象,造成这个现象的原因是各个Region的Memstore使用的大小加起来超过了总的阈值,于是阻塞,并开始找一个Region进行Flush,,这个过程会需要消耗掉一段时间,通常来说造成这个的原因是单台Region server上的Region数太多了,因此单台Region server上最好不要放置过多的Region,一种调节方法是调大split的fileSize,这样可以适当的减少Region数,但需要关注调整后读性能的变化。
**delaying flush up to
当日志中出现这个信息时,可能会造成出现下面的现象,从而产生影响,这个通常是StoreFile太多造成的,通常可以调大点StoreFile个数的阈值。
**Blocking updates for
当日志中出现这个信息时,表示写动作已被阻塞,造成这个现象的原因是memStore中使用的大小已超过其阈值的2倍,通常是由于上面的delaving flush up to 造成的,或者是region数太多造成的,或者是太多的Hlog造成的,这种情况下会造成很大的影响,如内存够用的话,可以调大阈值,如果是其他原因,就对症下药。
4、3、定位调优思路
针对HBase读写变慢的场景,可以按照如下思路进行定位、调优:
开始-->对比性能差距-->查看监控信息-->查看相关日志-->确定具体场景-->进行参数调优-->后续观察
4.3.1通过客户端程序,记录写入、读取速度
在客户端程序中,可以记录HBase写入/读取速度,关注性能差距。或者,通过HMaster的页面来查看各个RegionServer的RPC请求。
4.3.2查看HBase监控信息
Region的分裂、compaction、flush次数过多、flush耗时高、硬件资源抢占等众多元素都会影响性能,因此,需要从Manager监控页面中,查看各个RegionServer的各类监控指标,需要重点关注:RegionServer GC时间、RegionServer GC次数、节点CPU/内存利用率、Compaction的次数,Flush文件次数、Flush操作的平均耗时、Split次数等信息。
4.3.3查看相关日志
结合HBase的监控信息,查看RegionServer的运行日志。
4.3.4举例
4.3.4.1背景说明
某个HBase测试集群,客户端主要是put写入操作,发现写入性能较慢。只有一张hbase表t1,表结构简单(一个cf,一个qualifier),建表时预分5个Region。
4.3.4.2性能差距比较
通过客户端put对t1表put数据计算出,单节点写入速度为416条/s左右。
4.3.4.3监控信息展示
发现各个RegionServer的flush次数较多
RegionServer的内存占用并不高
4.3.4.4日志分析定位
可以查看RegionServer的运行日志,发现Flush被延长90000ms字样:
2016-04-22 02:35:33,820 | WARN | MemStoreFlusher.0 | Region
t1,04,1461259167461.b6e781003392195313a5ec8e39c6bf77. has too many store files;
delaying flush up to 90000ms |
org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.jav
a:448)
初步分析结论:在内存利用不高的情况下,仍然有过多的Flush操作,并且看到有的Flush被延迟。因此,主要根据1.2章节内容,对MemStore相关参数,进行调优。
4.3.4.5参数调整&测试
调整前的参数为:
hbase.regionserver.global.memstore.size=0.1
hbase.hstore.blockingStoreFiles=2
调整后的参数为:
hbase.regionserver.global.memstore.size=0.4
hbase.hstore.blockingStoreFiles=7
调整后,用同样的客户端对同一张表 t1 进行 put 写入测试, 发现写入性能得到提升, 单
节点处理性能达到 1280 条/s
4、4常见问题处理
4.4.1 OOM(内存溢出)
4.4.1.1问题现象
当运行bulkload任务或开启Region操作时,在RegionServer端产生如下的日志:
“java.lang.OutOfMemoryError:Direct buffer memory”
4.4.1.2问题定位过程
由于各种操作,HBase需要许多内存。I/O操作实验direct buffer memory,因此为了更好的性能和提高并发数需要给RegionServer提供更多的direct buffer memory和heap memory。
检查JVM参数,按照使用场景增加heap memory(-Xms/-Xmx)和direct buffer memory(-XX:MaxDirectMemorySize)
4.4.1.3问题解决方法
增加heap memory和direct buffer memory来避免OutOfMemory异常
eg:-Xms32G -Xmx32G -XX:MaxDirectMemorySize=2048M
经验设定:
按照使用场景来修改GC_OPTS,RegionServer并发读写操作越多,需要的内存越大,经验表明一般地上述示例配置能支撑单个RegionServer支持30个长期并发的需求。
Hbase性能调优(二)的更多相关文章
- hbase性能调优(1)
hbase性能调优 标签: hbase 性能调优 | 发表时间:2014-05-17 15:10 | 作者:无尘道长 分享到: 出处:http://www.iteye.com 一.服务端调优 1.参数 ...
- hbase性能调优_表设计案例
hbase性能调优案例 1.人员-角色 人员有多个角色 角色优先级 角色有多个人员 人员 删除添加角色 角色 可以添加删除人员 人员 角色 删除添加 设计思路 person表 ...
- hbase性能调优案例
hbase性能调优案例 1.人员-角色 人员有多个角色 角色优先级 角色有多个人员 人员 删除添加角色 角色 可以添加删除人员 人员 角色 删除添加 设计思路 person表 ...
- hbase性能调优之压缩测试
文章概述: 1.顺序写 2.顺序读 3.随机写 4.随机读 5.SCAN数据 0 性能测试工具 hbase org.apache.hadoop.hbase.PerformanceEvaluation ...
- HDP之HBase性能调优
(官方文档翻译及整理) 一.系统级调优 1.保证充足的RAM 2.64位的操作系统 3.Linux的swappiness设置为0 : sysctl vm.swappiness=10 vim /etc/ ...
- Hbase性能调优(一)
转自:https://blog.csdn.net/yueyedeai/article/details/14648111 1.修改Linux配置 Linux系统最大可打开文件数一般默认的参数值是1024 ...
- hbase性能调优(转载)
一.服务端调优 1.参数配置 1).hbase.regionserver.handler.count:该设置决定了处理RPC的线程数量,默认值是10,通常可以调大,比如:150,当请求内容很大(上MB ...
- HBase性能调优
因官方Book Performance Tuning部分章节没有按配置项进行索引,不能达到快速查阅的效果.所以我以配置项驱动,重新整理了原文,并补充一些自己的理解,如有错误,欢迎指正. 配置优化 zo ...
- HBase性能调优(转)
原文链接:http://www.blogjava.net/ivanwan/archive/2011/06/15/352350.html 因官方Book Performance Tuning部分章节没有 ...
随机推荐
- 第15.19节 PyQt(Python+Qt)入门学习:自定义信号与槽连接
老猿Python博文目录 专栏:使用PyQt开发图形界面Python应用 老猿Python博客地址 一.引言 本文利用中介绍了PyQt中的信号和槽机制,除了使用PyQt组件的已有信号外,PyQt和Qt ...
- GYCTF Web区部分WP
目录: Blacklist Easyphp Ezsqli FlaskApp EasyThinking 前言: 这次比赛从第二天开始打的,因为快开学了所以就没怎么看题目(主要还是自己太菜)就只做出一道题 ...
- 【Azure Developer】VS Code运行Java 版Azure Storage SDK操作Blob (新建Container, 上传Blob文件,下载及清理)
问题描述 是否可以用Java代码来管理Azure blob? 可以.在代码中加入azure-storage-blob依赖.即可使用以下类操作Azure Storage Blob. BlobServic ...
- 大白话详解大数据hive知识点,老刘真的很用心(1)
前言:老刘不敢说写的有多好,但敢保证尽量用大白话把自己复习的知识点详细解释出来,拒绝资料上的生搬硬套,做到有自己的了解! 01 hive知识点(1) 第1点:数据仓库的概念 由于hive它是基于had ...
- 【CSP-S 2019】树的重心(重心的性质)
Description 给定一颗 \(n\) 个顶点的树 \(\text T\),共 \(n-1\) 次断边操作,每次将树分为两部分 \(\text T_1, \text T_2\),求: \[\su ...
- 模块urllib requests json xml configparser 学习笔记
发起http请求 获取返回值 返回值是字符串 第三方模块安装 pip install requests 返回值格式 xml html jaon json 功能 loads 字符串>&g ...
- mysql 8.0 改变数据目录和日志目录(一)
一.背景 原数据库数据目录:/data/mysql3306/data,日志文件目录:/data/mysql3306/binlog 变更后数据库目录:/mysqldata/3306/data,日志文件目 ...
- 微信小程序自动化,记录趟过的坑!
项目思想:关键字+数据驱动混合测试 基于Android-微信小程序自动化的关键是:webview的切换 对于微信App来说如何从NATIVE切换到webview的过程 测试版本信息 1.微信版本:7. ...
- Spark性能调优篇八之shuffle调优
1 task的内存缓冲调节参数 2 reduce端聚合内存占比 spark.shuffle.file.buffer map task的内存缓冲调节参数,默认是3 ...
- 第九章 Nacos Config--服务配置
今天咱们接着 上一篇 第八章 SMS–短信服务 继续写 SpringCloud Alibaba全家桶 -> 第九章 Nacos Config–服务配置,废话不多说,开干 9.1 服务配置中心介绍 ...