精华内容
下载资源
问答
  • 为什么要用压缩 压缩和解压本质上:CPU的计算(执行算法) 它们就是一种特殊的加密算法,这个加密的要求是,加密后的体积要比原本更小 本质的原因是:CPU的速度远大于硬盘同时也远大于网络传输速度 ...

    为什么要用压缩

    压缩和解压本质上:CPU的计算(执行算法)

    它们就是一种特殊的加密算法,这个加密的要求是,加密后的体积要比原本更小

    本质的原因是:CPU的速度远大于硬盘同时也远大于网络传输速度

    核心点:将硬盘负载或者网络负载转移到CPU负载,是一种收益行为

    行存储和列存储的区别

    • 列存储,每个文件存储一个列,多个文件存储多个列,多个文件合成一张二维表

      • 优点:列过滤,列查找,针对列相关操作更快。扩展列,增删列很容易。列单独存储

        • 列相关查询、过滤性能更快
        • 扩展列、删除列更简单
        • 列单独存储,每个列均可以进行单独排序,性能更好
        • 列单独存储,可以针对每个列的数据类型设置针对性的压缩算法,使得压缩率更好
        • 数据加载可以选择指定的列加载到内存中。更加节省内存。

        数仓的特性很大一部分是针对列的过滤,列的搜索,列的匹配,所以很多数仓结构比较适合使用列存储

        列存储也比较适合做OLAP

      • 缺点:整行相关操作性能低。同时对事务的支持性不行(因为把列都拆开存储,每个列单独做事务,整体还要同步很麻烦)

    • 行存储,数据行存储,一个文件可表达一个二维表。

      • 优点:

        • 概念简单容易理解,和很多现实中的数据模型概念相通,比如CSV文件,文本数据文件等

          概念简单容易理解是一个很大的优势,毕竟性能低点可以忍,难以理解就不可以忍了。

          人天生懒。

        • 针对行操作更快捷

        • 事务支持比较好

      • 缺点:

        • 针对列的操作性能比列存储低,因为无论操作哪个列都要取出来整行数据
        • 只能针对整行数据选定压缩算法,无法针对列选定,压缩率不高(对比列存储)
        • 排序只可基于某一个列排序,然后整体行和行之间排序(索引等额外的解决方案除外,这里只是指原始状态下)
        • 扩展列、删除列不方便

    Hive分区数据的写入

    • 静态分区

      insert into … partition(year=‘2020’, month=‘09’)

    • 动态分区

      insert into … partition(year, month)

      开启动态分区,同时要求非严格模式

      set hive.exec.dynamic.partition=true; 是开启动态分区

      set hive.exec.dynamic.partition.mode=nonstrict; 这个属性默认值是strict,就是要求分区字段必须有一个是静态的分区值,当前设置为nonstrict,那么可以全部动态分区

    • 混合分区

      insert into …partition(year=‘2020’, month)

      这种方式要求静态在前。

    image-20201225091146258

    Hive分桶优化

    分桶的概念

    分桶和分区不同,分区是粗粒度的划分数据,并且是大范围的

    分桶是细粒度的数据划分

    分区划分的是文件夹

    分桶划分的是文件

    分区的规则是:按照指定key的值来确定文件夹

    分桶的规则是:按照hash散列来计算数据应该落入哪个分桶的文件中。

    总结:分区就是通过文件夹的方式大范围切分表数据

    分桶就是通过区分文件的方式在细粒度上切分表数据

    什么时候用分桶

    • 查询性能优化(在有JOIN的场景下)

      • 如果分区数量过多,会对文件系统造成负载压力。
      • 分桶是hash散列,如果分桶key相同,一定在一个文件内。当进行JOIN的时候,分桶就可以帮助完成文件对文件的对应。提升JOIN的性能
    • 数据采样

      我们用的都是大数据系统,特点是数据量够大。

      大量的数据如果做验证,比较消耗性能。

      如果能够抽取一部分数据做验证

      分桶就比较适合做数据采样用。

    分桶表的数据写入

    分桶表,不能够用load data的形式加载,也就是说只能够INSERT 来执行数据插入。

    也就是,分桶表不能够直接用sqoop导入数据

    sqoop导入的方案

    创建一个不带分桶的临时表,用sqoop将数据导入临时表

    执行:INSERT INTO 正式表 SELECT * FROM 临时表;

    MapJoin优化

    分桶本身也能提供优化,除了标准分桶外,还有一个MapJoin的优化。

    MapJoin优化:将Join发生在Map端,而不在Reduce端。

    如果在map端进行Join,每一个map都要有对应的数据存在内存中,也就是:

    • 主表可能数据是分散在各个map的
    • 被关联的表,肯定要全量的存在各个map的内存中

    场景限制

    一般用于,大表 Join 小表的场景

    参数

    # 开启自动执行MapJoin(达到条件,会自动走Map的Join而不是Reduce的Join)
    set hive.auto.convert.join=true;
    # 使用MapJoin的阈值设置,默认是20MB
    set hive.auto.convert.join.noconditionaltask.size=512000000
    /* 这个设置表示,如果N张表执行Join,N - 1张表的大小小于这个阈值,即可走MapJoin */
    

    显示的告知Hive走MapJoin

    在查询中加入:/*+mapjoin(表)*/

    示例:

    # 显示的告知Hive,这个查询要走MapJoin
    select /*+mapjoin(A)*/ f.a,f.b from A t join B f  on ( f.a=t.a and f.ftime=20110802) ;
    

    Bucket-MapJoin

    桶MapJoin

    大表对大表的场景下,无法使用MapJoin(因为大表指的就是超过了MapJoin允许的大小阈值)

    我们可以使用Bucket-MapJoin来进行优化。

    表整体无法在Map中hold住,可以将表的分桶在Map中hold

    相当于,两个表的分桶和分桶之间,做局部的MapJoin

    限制条件

    • 必须有分桶

    • bucket数是另一个表bucket数的整数倍

      也就是可以做1个文件对一个文件,或者1个文件对2个文件等。

      但是不能出现1个文件对1.3个文件

      所以要求整数倍

    • 分桶列也是JOIN列

    参数

    # 开启bucket mapjoin的优化
    set hive.optimize.bucketmapjoin = true;
    

    SMB Join 优化

    Sorted Merge Bucket Join

    MapJoin优化了整表的Join流程(整表在Map内存中Join)

    BucketMapJoin优化了表的局部Join(桶文件和桶文件之间在Map端的内存中Join)

    SMB Join 优化的是,在shuffle过程中的性能提升。

    MapReduce执行流程,Map和Reduce之间有Shuffle,Shuffle是需要耗费一定的时间的。

    如果提供的数据就是已排好序的,Shuffle就可以被加速吧

    SMB的核心就是:

    • 在BucketMapJoin的基础上,对桶文件进行排序

    通俗说就是:分桶 + 桶排序

    CLUSTERED BY(xxx) SORTED BY (xxx) INTO 10 BUCKET;
    

    参数

    # 开启排序
    set hive.enforce.sorting = true;
    # 开启SMB优化的自动尝试
    set hive.optimize.bucketmapjoin.sortedmerge = true;
    

    分桶优化小总结

    bucket mapjoin SMB join
    set hive.optimize.bucketmapjoin = true; set hive.optimize.bucketmapjoin = true; set hive.auto.convert.sortmerge.join=true; set hive.optimize.bucketmapjoin.sortedmerge = true; set hive.auto.convert.sortmerge.join.noconditionaltask=true;
    一个表的bucket数是另一个表bucket数的整数倍 小表的bucket数**=**大表bucket数
    bucket列 == join列 Bucket 列 == Join 列 == sort
    必须是应用在map join的场景中 必须是应用在bucket mapjoin 的场景中

    参数总结

    # 开启自动执行MapJoin(达到条件,会自动走Map的Join而不是Reduce的Join)
    set hive.auto.convert.join=true;
    # 使用MapJoin的阈值设置,默认是20MB
    set hive.auto.convert.join.noconditionaltask.size=512000000
    # 开启bucket mapjoin的优化
    set hive.optimize.bucketmapjoin = true;
    # 开启排序
    set hive.enforce.sorting = true;
    # 开启SMB优化的自动尝试
    set hive.optimize.bucketmapjoin.sortedmerge = true;
    

    Hive索引

    索引的概念

    索引:本质上就是将数据查询的检索次数需要加载的数据量进行优化的一种手段

    大白话:加速查询的过程

    优点:

    • 就是查的超快

    缺点:

    • 增、删、改都是性能拖累

    对数据库表而言,只对频繁使用过滤条件或者关联条件的列,加索引最好。不要全都加。

    索引是以时间+空间时间的操作

    • 前面的时间指的是,插入、更新、删除等操作变慢
    • 后面的时间指的是,查询的速度变快
    • 空间指的是:额外的存储来记录索引信息

    Hive索引类型

    • Hive原始索引(3.0废弃)
      • 不会自动跟随数据更新而更新,每次更细数据都需要自行的执行重建索引的操作
    • Row Group Index(行组索引)
    • Bloom Filter Index(布隆过滤器索引)

    行组索引和布隆过滤器索引,都需要使用ORC

    行组索引

    针对某个列,行组索引是在ORC文件的每一个分块上,构建分块中针对这个列的最大值和最小值的记录

    通过这个记录,来确保索引数据,查询数据的时候可以pass掉大部分数据。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ezvFNQFv-1619097949231)(https://image-set.oss-cn-zhangjiakou.aliyuncs.com/img-out/image-20210105153702771.png)]

    条件:

    1. Hive的表存储是ORC
    2. 创建表的时候指定TABLEPROPERTIES中有:orc.create.index = true
    3. 数据插入的时候是有序插入
    4. 主要应用数值类型的列,用于:> >= < <= !=的判断

    使用

    创建表

    CREATE TABLE xxx stored AS ORC
    TABLEPROPERTIES(
    	-- 开启压缩
    	'orc.compress' = 'SNAPPY',
    	-- 开启行组索引
    	'orc.create.index = true'
    );
    

    插入数据

    INSERT INTO TABLE xxx SELECT ......
    DISTRIBUTE BY id SORT BY id;
    

    查询数据

    set hive.optimize.index.filter=true; -- 自动使用索引优化
    SELECT * FROM xxx WHERE id < 100;
    

    布隆过滤器

    原理

    对ORC中每个分块的数据,做分块索引

    确保=的查询是很快的。

    如果确定了分块,那么=判断很快。

    如果不确定分块,需要挨个判断。

    最好和行组索引一起使用,行组可以加速对分块的判断。

    布隆索引可以加速对分块内数据的=判断

    条件

    1. 必须是ORC存储
    2. 创建表的时候指定TABLEPROPERTIES中有:orc.bloom.filter.columns = '字段列表逗号分隔'
    3. 只用于=判断

    如何使用

    布隆过滤器索引可以和行组过滤器索引一起使用,效果更好。

    建表

    CREATE TABLE xxx stored AS ORC
    TABLEPROPERTIES(
    	-- 开启压缩
    	'orc.compress' = 'SNAPPY',
    	-- 开启行组索引
    	'orc.create.index = true',
        -- 开启布隆过滤器
        "orc.bloom.filter.columns" = "id,price"
    );
    

    插入数据

    无要求(针对布隆过滤器)

    如果使用了行组,请有序写入

    查询数据

    set hive.optimize.index.filter=true; -- 自动使用索引优化
    SELECT * FROM xxx WHERE id = 1000;
    

    索引使用的限制

    不要乱加索引,有消耗

    作为关联条件的可以用索引

    经常被WHERE的可以选择行组过滤索引

    经常被=的,可以选择布隆过滤器

    Hive的常见函数

    IF 函数

    语法:

    IF (表达式, true结果, false结果)

    意义:对表达式进行判断,如果表达式为,将返回true的结果

    如果为将返回false的结果

    举例:

    SELECT IF (1=1, '是', '否');
    -- IF也可以嵌套比如
    IF (a=b, IF(c=e, 1, 2), 0);
    

    nvl函数

    语法:

    NVL(被判断的值, 默认返回值)

    意义:对被判断的值进行判断,如果它为NULL,将返回默认值,否则就返回这个值本身

    举例:

    SELECT NVL(NULL, '是空');
    

    COALESCE函数

    帮助查找第一个不为空的数据

    语法:

    COALESCE(参数列表*);
    

    作用:从参数列表中,返回第一个不为NULL的数据

    -- 示例
    SELECT COALESCE(NULL,NULL,'你好', '哈哈');
    -- 将会返回你好
    

    CASE WHEN THEN

    作用就是对数据进行判断,返回想要的值

    语法1:

    -- 以CASE开始
    CASE
    	WHEN 表达式 THEN 返回值
    	WHEN 表达式 THEN 返回值
    	......
    	ELSE
    END -- 以END结束
    

    示例sql

    CASE
    	WHEN name='张三' THEN '帅哥'
    	WHEN name='李四' THEN '丑男'
    	ELSE '呵呵'
    END
    

    语法2:

    -- 以CASE开始
    CASEWHENTHEN 返回值
    	WHENTHEN 返回值
    	......
    	ELSE
    END -- 以END结束
    
    CASE
    	name
    	WHEN ’张三' THEN '帅哥'
    	ELSE '丑男'
    END;
    

    isnull

    语法:isnull( a )

    返回值:boolean

    说明:如果a为null就返回true,否则返回false。

    isnotnull

    语法:isnotnull(a)

    返回值:boolean

    说明:如果a为非null就返回true,否则返回false。

    Hive优化2

    并行优化

    并行编译

    Hive默认情况下,只能同时编译一个SQL到MapReduce代码的转换,并对这个过程上锁。

    为了提高效率,同时减少死锁发生的可能性,我们需要将这个一次只能编译一个的操作,优化为并行执行。

    参数:

    set hive.driver.parallel.compilation=true;

    默认这个参数是False;

    搭配参数:

    hive.driver.parallel.compilation.global.limit

    表示,最大的并行度是多少。默认是3

    这个优化不能提交性能,但是能够提高体验

    并行Stage执行

    Hive的SQL在翻译成MR任务的时候,可能会有很多的stage(阶段)

    阶段之间都会有依赖关系:

    • 前后依赖(前面的MR执行完成,后面的MR才可以去运行)
    • 无依赖

    如果多个State之间没有依赖,他们如果能够并行执行就能够提高集群的整体资源利用率

    参数:

    set hive.exec.parallel=true,可以开启并发执行,默认为false。
    set hive.exec.parallel.thread.number=16; //同一个sql允许的最大并行度,默认为8。
    

    小文件优化

    建议在企业中去使用,个人虚拟机电脑的性能不足,会导致性能下降。

    前置条件:MapReduce的执行结果,不是一个单独的文件。而是多个文件。

    如果MR任务的结果产生了很多的小文件存储在HDFS中,那么就会造成性能的下降(对NameNode的压力会很大)

    小文件的HDFS影响

    • 对磁盘寻道不友好(排除SSD,这里指的是机械硬盘)

      • 95%的HDFS集群底层都是机械硬盘(少量土豪用SSD)
      • 机械硬盘在随机读写上的性能是非常弱势的(对比SSD)
      • 因为小文件代表了更多的block,更多的block代表了更多的数据并非连续的存储在磁盘的某一区域而是分散存储。
      • 因为block多带来的分散存储,导致磁盘会频繁的进行随机寻址。
    • 对NameNode的压力很大

      在HDFS中文件是以block存储的。每一个块在HDFS中都有记录。如果文件较小,并且比较多的话,就导致block的数量会变的更多,更多的block会消耗更多的NameNode的资源。

    举例:

    磁盘占用率100%,但是每秒传输数据量,不到5MB/s

    底层原因就是:小文件太多,磁盘在做频繁的随机寻址

    Hive执行MapReduce也会产生很多的结果文件。

    这些结果文件,都不一定每一个都达到了一个block的大小。

    随着时间的推移,结果文件会越攒越多,最终还是导致了文件过多对HDFS的影响,以及文件都不一定达到block的大小,也是一种小文件过多的问题。

    对于这个问题,我们可以要求Hive在执行完毕后,合并结果文件。

    合并后不是一个文件,而是可能多个文件。

    每一个文件默认是按照HDFS的block大小来设定的

    参数

    # 是否开启合并Map端小文件,在Map-only的任务结束时合并小文件,true是打开。
    hive.merge.mapfiles
    
    # 是否开启合并Reduce端小文件,在map-reduce作业结束时合并小文件。true是打开。
    hive.merge.mapredfiles
    
    # 合并后MR输出文件的大小,默认为256M。建议设置为255M
    hive.merge.size.per.task
    
    # 对小文件判断的平均大小阈值(结果文件的平均大小如果小于阈值,才会进行合并的操作)
    hive.merge.smallfiles.avgsize
    

    矢量化查询

    对于分布式系统的优化,有两个方向:

    1. 增加分布式能力(增加并行计算能力)(横向拓展)

      说白了就是加机器,加CPU数量

    2. 增加单机的处理能力(纵向拓展)

    矢量化查询,就是类型2的优化。

    MapReduce默认情况下,对数据的处理是一条条的处理的。

    一条条处理是很正常的处理方式,写到这里,没有任何歧义,只是为了烘托矢量化查询而已。

    矢量化查询是指,对数据一批批的处理。

    要执行矢量化是有要求的:

    • 必须是ORC存储

    参数

    # 开启矢量化查询
    set hive.vectorized.execution.enabled=true;
    # 开启矢量化在reduce端
    set hive.vectorized.execution.reduce.enabled = true;
    

    这种带有enable类型的,只是指开启某个功能,功能能不能用得上,是hive的判断。

    比如前面将的map join

    读取零拷贝优化

    概念:尽量减少在读取的时候读取的数据量的大小。

    条件:

    • ORC存储(列存储)
    • 查询只用到的部分的列

    一般情况下,我们写SQL是有一部分的SQL是只会用到表中的部分的,并不是要全部的列。

    这种场景下,就可以只加载用到的列即可。不用到的不去加载(必须是列式存储)。

    参数

    set hive.exec.orc.zerocopy=true;
    

    依旧是开启功能,能否用上,看hive的判断

    数据倾斜优化

    数据倾斜:在分布式程序分配任务的时候,任务分配的不平均。

    数据倾斜,在企业开发中是经常遇到的,以及是非常影响性能的一种场景。

    数据倾斜一旦发生,横向拓展只能缓解这个情况,而不能解决这个情况。

    如果遇到数据倾斜,一定要从根本上去解决这个问题。而不是想着加机器来解决。

    JOIN的时候的倾斜

    方案一

    用前面讲过的map join SMB join 这些优化去解决。

    效果不太好,本身这些提高执行性能的方案,顺带着将倾斜的性能也提升一点,本质上不是解决倾斜的方案。

    方案二

    Sekw Join

    方案的方式是:

    对倾斜列的数据,进行单独处理。也就是遇到倾斜列的数据的时候,直接找一个中间目录临时存储,当前MR不去处理

    等当前MR完成后,在单独处理这个倾斜的数据集。

    这种解决方式有一个前置条件,Hive必须要知道,哪个列的数据倾斜了。

    如何让Hive知晓哪个列是倾斜列,就有2种方式

    方式1:运行时判断

    在执行MR的过程中,Hive会对数据记录计数器,当计数器的值大于某个阈值的时候,认为这个数据是倾斜的列,对其进行单独处理。

    方式2:编译时判断

    指的就是,执行SQL的人提前知晓某个列就是倾斜列。

    在建表的时候,就指定某个列是倾斜列即可。

    参数

    # 开启倾斜优化,针对倾斜优化的总开关
    set hive.optimize.skewjoin=true;
    
    # 设置运行时判断的时候,对倾斜数据量的阈值
    set hive.skewjoin.key=100000;
    
    # 开启编译时的倾斜优化,针对编译时的开关
    set hive.optimize.skewjoin.compiletime=true;
    
    # 示例语句,这个语句用于编译时判断,提前告知Hive哪个列是倾斜的
    CREATE TABLE list_bucket_single (key STRING, value STRING)
    -- 倾斜的字段和需要拆分的key值
    SKEWED BY (id) ON (1,5,6)
    --  为倾斜值创建子目录单独存放
    [STORED AS DIRECTORIES];
    
    
    
    -- 上面的参数可以组合一块使用
    -- 当表有SKEWED BY的设置,走编译时优化
    -- 如果表没有这个设置,就运行时优化
    

    在企业场景中,满足编译时的判断的场景不多,多数时候还是靠运行时来优化。

    编译时的一种场景举例:

    比如,传智播客的北京和上海校区很火爆,90%的学生都来这俩校区。

    学生报名的事实表,铁定在北京和上海两个校区的ID上产生倾斜。

    这样的场景才是适合编译时的,也就是在干活之前就分析出来哪个地方是倾斜了。

    数据倾斜,无法避免,这是事实产生事件的现实映射。

    只要你没有能力解决现实事件,那么事件的产生就会倾斜。

    我们要做的是,在数据倾斜的前提下,完成性能优化。

    Union优化

    在前面的优化中,不管是运行时优化,还是编译时优化,都会产生两份结果。

    这两份结果最终都需要进行Union操作合并为一份结果

    参数:

    set hive.optimize.union.remove=true;

    开启这个参数的时候,对中间数据进行重复性利用。提升union的性能。

    重复利用:不会单独开启任务对多份数据执行合并,而是每一个任务在执行之后直接将结果输出到目的地。

    不开启Union合并优化:

    MR1 对普通数据进行处理,输入路径:/tmp/1

    MR2 对倾斜数据进行处理,输入路径:/tmp/2

    合并后,数据写入最终目的地:/user/hive/warehouse/xxx.db/xxxtable/

    如果开启了优化:

    MR1 对普通数据进行处理,输入路径:/user/hive/warehouse/xxx.db/xxxtable/

    MR2 对倾斜数据进行处理,输入路径:/user/hive/warehouse/xxx.db/xxxtable/

    GROUP BY分组统计的倾斜处理

    对于数据倾斜,典型的两个性能点:

    • Join操作
    • Group BY操作

    分组聚合。

    前提条件:对数据走平均打散,不按照hash散列

    优化1:

    利用MapReduce的Combina 机制,在Map端完成预聚合操作。

    因为,分组是必聚合的,所以,我们可以做预聚合

    参数:

    hive.map.aggr=true;
    

    优化2:

    大combina机制,对预聚合产生在第一个MR的reduce端。

    最终聚合产生在第二个MR中

    将Map端的Combina扩散到真个MR,最终的聚合交由第二个MR来做。

    在绝对的性能上:优化1是性能最好的,因为节省了很多的中间数据传输。同时一个MR搞定,不需要搞第二个MR来做。

    但是,如果数据量巨大,这个MapReduce的任务的压力就会很大,同时执行时间可能很长。

    执行时间过长,中间的变量就不好控。一旦出现问题,重头再来。

    所以,对于海量数据一般使用优化2的方式,因为如果出现问题,起码可以从第一阶段的结果再来。

    参数:

    hive.groupby.skewindata=true;
    

    MapReduce迭代计算的概念(补充)

    迭代计算,就是一步步的计算出结果的方式。

    方式比一次性计算出结果效率要低,但是稳定性和数据的可复用性更好。

    在很多的企业业务计算中,有的数据计算是很复杂的。

    可能:

    • 如果要在一个MapReduce中完成这个业务,代码写起来很复杂
    • 根本就不可能在一个MapReduce中完成整个业务的计算。

    MapReduce的计算模型

    上面提到:有可能会:根本就不可能在一个MapReduce中完成整个业务的计算。

    这个是因为MapReduce的计算模型,就2个:

    • Map模型
    • Reduce模型

    严格意义来说,MR叫做可供使用的算子就2个,一个是map算子一个是reduce算子

    很多的业务计算都受限map和reduce方法的限制,因为,比如map方法

    map(传入参数固定){

    ​ 我们只能在这个部分,做自由处理。

    ​ return 返回形式固定

    }

    reduce(传入参数固定){

    ​ 我们只能在这个部分,做自由处理。

    ​ return 返回形式固定

    }

    MR的迭代

    基于前面的概念,所以很多的业务计算本质上是迭代的计算。

    image-20210111115155248

    如图,某些复杂的业务场景可能会如图所示执行MR的迭代计算。

    上图中,MR之间基于HDFS完成数据的共享。

    迭代计算中,中间产生的数据,都是中间结果。

    这些中间结果就类似数仓中,ODS->DWD->DWM->DWS->APP的迭代过程。

    上图本质上是一个有向无环图(DAG)

    有向是指:MR1走向MR6的方向

    无环:没有形成闭环

    前面分组倾斜处理优化中的优化2方案,就是一种迭代计算的思想延伸。

    Hive优化小总结

    Hive在各方面优化的东西乱七八糟一堆。

    我们这个数仓项目,70%时间都在Hive上,30%的时间在业务分析,建模分析上。

    很痛苦,我们只想专心做业务分析,不想搞乱七八糟的这优化那优化的。

    后面学习Spark和Flink的时候就能体会到专心做业务的快感了。

    HIVE提到的所有优化项大全

    --分区
    SET hive.exec.dynamic.partition=true;
    SET hive.exec.dynamic.partition.mode=nonstrict;
    set hive.exec.max.dynamic.partitions.pernode=10000;
    set hive.exec.max.dynamic.partitions=100000;
    set hive.exec.max.created.files=150000;
    --hive压缩
    set hive.exec.compress.intermediate=true;
    set hive.exec.compress.output=true;
    --写入时压缩生效
    set hive.exec.orc.compression.strategy=COMPRESSION;
    --分桶
    set hive.enforce.bucketing=true;
    set hive.enforce.sorting=true;
    set hive.optimize.bucketmapjoin = true;
    set hive.auto.convert.sortmerge.join=true;
    set hive.auto.convert.sortmerge.join.noconditionaltask=true;
    --并行执行
    set hive.exec.parallel=true;
    set hive.exec.parallel.thread.number=8;
    --小文件合并
    -- set mapred.max.split.size=2147483648;
    -- set mapred.min.split.size.per.node=1000000000;
    -- set mapred.min.split.size.per.rack=1000000000;
    --矢量化查询
    set hive.vectorized.execution.enabled=true;
    --关联优化器
    set hive.optimize.correlation=true;
    --读取零拷贝
    set hive.exec.orc.zerocopy=true;
    --join数据倾斜
    set hive.optimize.skewjoin=true;
    -- set hive.skewjoin.key=100000;
    set hive.optimize.skewjoin.compiletime=true;
    set hive.optimize.union.remove=true;
    -- group倾斜
    set hive.groupby.skewindata=false;
    

    示例千亿级别的数据倾斜优化实操

    https://www.bilibili.com/video/BV1Tv411B7Cf

    展开全文
  • MySQL的查询执行计划中,Extra列经常会出现“Using where; Using index”。 MySQL官方手册解释: Using indexThe column information is retrieved from the table using only information in the index tree ...

    MySQL的查询执行计划中,Extra列经常会出现“Using where; Using index”。

    MySQL官方手册解释:

    Using index
    The column information is retrieved from the table using only information in the index tree without having to do an additional seek to read the actual row. This strategy can be used when the query uses only columns that are part of a single index.
    Using where
    A WHERE clause is used to restrict which rows to match against the next table or send to the client. Unless you specifically intend to fetch or examine all rows from the table, you may have something wrong in your query if the Extra value is not Using where and the table join type is ALL or index.

    这表明:

    Using index不读数据文件,只从索引文件获取数据

    Using where过滤元组和是否读取数据文件或索引文件没有关系

    但MySQL手册在Using index处又说:

    If the Extra column also says Using where, it means the index is being used to perform lookups of key values. Without Using where, the optimizer may be reading the index to avoid reading data rows but not using it for lookups. For example, if the index is a covering index for the query, the optimizer may scan it without using it for lookups.

    所以有朋友如此理解:

    1 没有Using where只有Using index:则不读数据文件,所有字段都可以从索引上获得(Without Using where, the optimizer may be reading the index to avoid reading data rows but not using it for lookups)

    2 同时有Using where和Using index:因为“Without Using where...”这句上下文,则意味着同时有Using where和Using index则一定需要读取数据文件

    其实不然。“Using where只是过滤元组,和是否读取数据文件或索引文件没有关系”。

     



    .


     

    展开全文
  • 查询优化技术概念

    千次阅读 2017-12-04 00:42:50
     查询优化技术主要包括查询重用技术、查询重写规则技术、查询算法优化技术、并行查询的优化技术、分布式查询优化技术和其他优化技术6个方面的技术。 1.1 查询重用  查询重用是指尽可能利用先前的执行结果,以...

    本文摘取自《数据库查询优化器的艺术》

    一、查询优化技术简介 

       查询优化技术主要包括查询重用技术、查询重写规则技术、查询算法优化技术、并行查询的优化技术、分布式查询优化技术和其他优化技术6个方面的技术。

    1.1 查询重用

        查询重用是指尽可能利用先前的执行结果,以达到节约查询计算全过程的时间并减少资源消耗的目的。
        目前查询重用技术主要集中在两个方面:
    1. 查询结果的重用。在缓存区中分配一块缓冲块,存放该SQL语句文本和最后的结果集,当遇到同样的SQL输入是,可直接把结果返回。查询结果的重用技术节约了查询计划生成事件和查询执行过程的时间,减少了查询执行全过程的资源消耗。
    2. 查询计划的重用。缓存一条查询语句的执行计划及其相应语法树结构。查询计划的重用技术减少了查询计划生成的时间和资源消耗。
        查询重用技术有利有弊:弊端,如结果集很大会消耗很大的内存资源,同样的SQL不同用户获取的结果集可能不完全相同;益处,节约了CPU和IO消耗。在使用过程中,趋利避害,应根据实际情况选用。

    1.2 查询重写规则

        查询重写是查询语句的一种等价转换,即对于任何相关模式的任意状态都会产生相同的结果(相同的关系替代两个表达式中相应的关系,所得到的结果是相同的)。查询重写有两个目标:
    1. 将查询转换为等价的、效率更高的形式,例如将效率低的谓词转换为效率高的谓词、消除重复条件等。
    2. 尽量将查询重写为等价、简单且不受表顺序限制的形式,为物理查询优化阶段提供更多的选择,如视图的重写、子查询的合并转换等。
        查询重写的一句,是关系代数。关系代数的等价变换规则对查询重写提供了理论上的支持。查询重写后,查询优化器可能生成多个连接路径,可以从候选者中择优。
        对查询优化技术进行分类,可有以下4个角度:
    1. 语法级。查询语言层的优化,基于语法进行优化
    2. 代数级。查询使用形式逻辑进行优化,运用关系代数的原理进行优化
    3. 语义级。根据完整性约束,对查询语句进行语义理解,推知一些可优化的操作
    4. 物理级。物理优化技术,基于代价估算模型,比较得出各种执行方式中代价最小的。
        查询重写是基于语法级、代数级、语义级的优化,可以统一归属到逻辑优化的范畴:基于代价估算模型是物理层面的优化,是从连接路径中选择代价最小的路径的过程。
        查询重写技术优化思路主要包括:
    1. 将过程性查询转换为描述性的查询,如视图重写
    2. 将复杂的查询(如嵌套子查询、外连接、嵌套连接)尽可能转换为多表连接查询
    3. 将效率低的谓词转换为等价的效率高的谓词(如等价谓词重写)
    4. 利用等式和不等式的性质,简化WHERE、HAVING和ON条件
        如何改进现有查询重写规则的效率,如何发现更多更有效的重写规则,是查询优化的研究内容之一。常见的查询重写技术类型,每一类都有自己的规则,这些规则每月确定的、统一的规律。但重写的核心一定是”等价转换”,只有等价才能转换,这是需要特别强调的。

    1.3 查询算法优化

        查询优化即求解给定查询语句的高效执行计划的过程。
        查询计划,也成为查询树,它由一系列内部的操作符组成,这些操作按一定的运算关系构成查询的一个执行方案。
        查询优化的目的就是生成最好的查询计划。通常有以下两个策略:
    1. 基于规则优化。根据经验或一些已经探知或被证明有效的方式,定义为规则。用这些规则简化查询计划生成过程中符合可被简化的操作,使用启发式规则排除一些明显不好的存取路径,这就是基于规则的优化。   ???基于规则的优化和查询重写有什么区别???
    2. 基于代价优化。根据一个代价评估模型,在生成查询计划的过程中,计算每条存取路径的花费,然后选择代价最小的作为子路径,这样直至所有表连接完毕得到一个完整的路径。

    1.4 并行查询优化

        在并行数据库系统中,查询优化的目的是寻找具有最小响应时间的查询执行计划,这需要把查询工作分解为一些可以并行运行的自工作。
        一个查询是否能并行执行,取决于以下因素:
    1. 系统中可用资源(如内存、缓存等)
    2. CPU
    3. 运算中特定代数运算符。在同一个SQL内,查询并行可以分为以下几种
      1. 操作内并行:将同一操作分解成多个独立的子操作,由不同的CPU同时执行
      2. 操作间并行:一条SQL查询语句可以分解成多个子操作,由多个CPU执行

    1.5 分布式查询优化

        在分布式数据库系统中,查询策略优化(主要是数据传输策略)和局部处理优化(传统的单节点数据库的查询优化技术)是查询优化的重点。
        在查询优化策略中,数据的通信开销是优化算法考虑的主要因素。分布式查询优化以减少传输的次数和数据量作为查询优化的目标。
        在分布式数据库系统中,代价估算模型如下:
        总代价 = IO代价 + CPU代价 + 通信代价

    1.6 其他优化

        如数据库集群系统中的SD(Share Disk)集群和SN(Share Nothing)集群。

    二、逻辑查询优化

        查询优化器在逻辑优化阶段主要解决的问题是:如何找出SQL语句等价的变换形式,使得SQL执行更高效。
        逻辑查询优化的思路包括:
    1. 子句局部优化,如等价谓词重写、WHERE和HAVING条件简化。
    2. 子句间关联优化,如外连接消除、连接消除、子查询优化、视图重写等,它们的优化都需要借助其他子句、表定义或列属性等信息进行
    3. 局部与整体优化,需要协同考虑局部表达式和整体的关系,如OR重写并集规则需要考虑UNION操作的花费和OR操作的花费
    4. 形式变化优化,多个子句存在嵌套,可以通过形式的变化完成优化,如嵌套连接消除。
    5. 语义优化,根据完整性约束,SQL表达的含义等信息对语句进行语义优化
    6. 其他优化,根据一些规则对非SPJ做的其他优化。根据硬件环境进行的并行查询优化。

    2.1 关系代数基础

        关系代数是关系型数据库查询语言的基础。关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。
        关系代数的运算符包括以下4类:
    1. 传统集合运算符。并UNION、交INTERSECTION、差DIFFERENCE、积EXTENDED CARTESIAN PRODUCT
    2. 专门的关系运算符。选择SELECT、投影PROJECT、连接JOIN、除DIVEDE
    3. 辅助运算符。包括算术比较符和逻辑运算符
    4. 关系扩展运算符。如半连接SEMIJOIN、半差SEMIDIFFERENCE、扩展EXTEND、合计COMPOSITION、传递闭包TCLOSE

    2.2 查询重写规则

        传统的OLTP使用基于选择(SELECT)(选择类似于filter)、投影(PROJECT)、连接(JOIN)3种基本操作相结合的查询,这种查询成为SPJ查询。
        数据库针对SPJ查询有一系列的优化规则,如下:
    1. 选择操作:优化方式是选择操作下推,目的是尽量减少连接操作前的元组数,使得中间临时关系尽量少,减少IO和CPU消耗,节约内存空间
    2. 投影操作:优化方式是投影操作下推,目的是尽量减少连接操作前的列数,使得中间关系尽量小,节约内存空间
    3. 连接操作:这里涉及以下两个子问题
      1. 多表连接中每个表被连接的顺序决定着效率
      2. 多表连接每个表被连接的顺序由用户语义决定

    2.2.1 子查询的优化

        子查询是查询语句中经常出现的一种类型,是比较耗时的操作。优化子查询对查询效率的提升有着直接的影响,所以子查询优化技术,是数据库查询优化引擎的重要研究内容。
        从子查询出现在SQL语句的位置看,它可以出现在目标列、FROM子句、WHERE子句、JOIN/ON子句、GROUPBY子句、HAVING子句、ORDERBY子句等维值。子查询出现在不同维值对优化的影响如下:
    1. 目标列位置:子查询只能是标量子查询,只能返回一个字段
    2. FROM子句位置:不能是相关子查询
    3. WHERE子句位置:作为表达式的一部分,需要符合操作符和操作数的规范
    4. JOIN/ON子句位置:JOIN同FROM,ON同WHERE
    5. GROUPBY子句位置:目标列必须和GROUPBY关联(在GROUPBY中就必须在SELECT中)
    6. ORDERBY子句位置:子查询在ORDERBY子句上没有实际意义

    2.2.1.1 子查询分类

        根据子查询中涉及的关系对象与外层关系对象间的关系,子查询可以分为以下两类:
    1. 相关子查询:子查询依赖于外层父查询的一些属性值
    2. 非相关子查询:子查询具有独立性,可以独自求解,形成一个子查询计划先于外层的查询求解
        从语句构成的复杂程度看,可以分为以下三类:
    1. SPJ子查询
    2. GROUPBY子查询
    3. 其他子查询
        从结果集的角度看,可以分为以下四类:
    1. 标量子查询:返回一个单一值
    2. 列子查询:返回一条单一列
    3. 行子查询:返回一个单一元组
    4. 表子查询:返回多行多列

    2.2.1.2 子查询的优化思路

    1. 子查询合并:在某些条件下(语义等价:两个子查询产生同样的结果集),多个子查询能够合并成一个子查询,减少表扫描次数
    2. 子查询展开:又称为子查询上拉,即把某些子查询重写为等价的多表连接操作。减少查询层次
    3. 聚集子查询消除:聚集函数上推,将子查询转变为一个新的不包含聚集函数的子查询,并与父查询的部分或全部表做左外连接

    2.2.2 视图重写

        视图重写就是将对视图的引用重写为对基本表的引用。视图重写后的SQL多被元作为子查询进行进一步优化。所有的视图都可以被子查询替换,但不是所有的子查询都可以用视图替换。

    2.2.3 等价谓词重写

        数据库执行引擎对一些谓词处理的效率要高于其他谓词,基于这点,把逻辑表达式重写成等价的且效率更高的形式,能有效提高查询执行效率。
        常用的谓词重写规则如下:
    1. 改写LIKE规则为其他等价的谓词,以更好地利用索引进行优化。
    2. BETWEEN-AND 规则
    3. IN转OR
    4. IN转ANY
    5. OR转ANY
    6. ALL/ANY转换集函数规则
    7. NOT规则

    2.2.4 条件简化

    1. 把HAVING条件并入WHERE条件
    2. 去除表达式中冗余的括号
    3. 常量传递
    4. 消除死码
    5. 表达式计算
    6. 等式变换
    7. 不等式变换
    8. 布尔表达式变换

    2.2.5 外连接消除

        外连接分为左外连接,右外连接和全外连接。查询重写的一项技术就是把外连接转为内连接,原因如下
    1. 查询优化器在处理外连接操作是所需执行的操作和时间多于内连接
    2. 优化器在选择表连接顺序时,可以有更多灵活的选择,从而可以选择更好的表连接顺序,加快查询执行的速度。
    3. 一些连接算法将数据量较小的表作为外表时,可以减少不必要的IO开销
        外连接可消除的条件:WHERE子句中与内表相关的条件满足“空值拒绝”,例如
    select a.idb.id from a left outer join b on a.id = b.id where b.id is not null
    可以重写为下面的inner join
    select a.idb.id from a inner join b on a.id = b.id

    2.2.6 嵌套连接消除

        对于一个无嵌套的多表连接,表之间的连接次序是可以交换的,这样能灵活求解不同连接方式的花费,从而得到最小花费的连接方式。
        当执行连接的操作次序不是从左到右逐个进行时,就说明这样的连接表达式存在嵌套。
        关于嵌套连接的消除规则如下:
    1. 当嵌套连接表达式只包括内连接时,括号可以去掉,这意味着表之间的次序可以交换,这是关系代数中连接的交换律的应用
    2. 当连接表达式包括外连接时,括号不可以去掉,意味着表之间的次序只能按照原语义进行,至多能执行的就是外连接向内连接转换的优化

    2.2.7 连接消除

    1. 主外键关系的表进行的连接,可以消除主键表,这不会影响对外键表的查询
    2. 唯一键作为连接条件,三表内连接可以去掉中间表(中间表的列只作为连接条件)

    2.2.8 语义优化

        语义优化的常见方式如下:
    1. 连接消除
    2. 连接引入
    3. 谓词引入
    4. 检测空回答集
    5. 排序优化
    6. 唯一性使用

    2.2.9 针对非SPJ的优化

    1. GROUPBY优化
      1. 分组操作下移:减少关系元祖的个数
      2. 分组操作上移:提高分组操作的效率
    2. ORDERBY优化
      1. 排序消除
      2. 排序下推
    3. DISTINCT优化
      1. DISTINCT消除
      2. DISTINCT下推
      3. DISTINCT迁移
    展开全文
  • JavaScript性能优化-概念

    万次阅读 2020-08-07 10:37:17
    这本栏文章中主要介绍的是ECMAScript/JavaScript的性能优化 我们都知道,随着软件开发行业的不断发展,性能优化呢已经是一个不可避免的话题。 那么什么样的行为才能算得上是性能优化呢?本质上来说,任何一种可以...

    在这里插入图片描述

    介绍
    这本栏文章中主要介绍的是JavaScript的性能优化
    
    我们都知道,随着软件开发行业的不断发展,性能优化呢已经是一个不可避免的话题。
    
    那么什么样的行为才能算得上是性能优化呢?本质上来说,任何一种可以提高运行效率,
    
    降低运行开销的行为,我们都可以看作是一种优化操作,
    
    这也就意味着在软件开发过程中必然存在着很多值得优化的地方。
    
    特别是在前端应用开发过程中性能优化我们可以认为是无处不在的,
    
    例如请求资源时所用到的网络以及数据的传输方式,在负责开发过程中所使用到的框架等他们都可以去进行优化,
    
    而本阶段的我们要探索的是JavaScript语言本身的优化,
    
    具体来说就是从认知内存空间的使用再到垃圾回收的方式介绍,从而呢,
    
    让我们可以编写出高效的JavaScript代码
    
    分类介绍
    1、内存管理
    首先,这里呢,我们首先会说明为什么我们的内存是需要管理的,以及内存管理的基本流程。
    同时呢,我也会去介绍一些常见的GC算法,
    
    2、垃圾回收和常见的GC算法
    提高自己的算法水平,可以灵活的去应对一些所谓的面试
    

    谢谢观看,如有不足,敬请指教

    展开全文
  • 优化问题简单概念

    千次阅读 2017-04-26 15:46:11
    http://cs229.stanford.edu/section/cs229-cvxopt.pdf,从中我们可以大致了解到一些凸优化概念,比如凸集,凸函数,凸优化问题,线性规划,二次规划,二次约束二次规划,半正定规划等,从而对凸优化问题有个初步的...
  • 在学习多目标优化的过程中,尤其涉及Pareto相关知识的一些概念的时候,公式与严谨逻辑的定义,在初学状态下,很难准确的认识并理解这些概念,本文重点就是将学习的过程中,对这些概念的自己理解,用较通俗的语言整理...
  • http://www.cnblogs.com/tornadomeet/p/3300132.html没有系统学过数学优化,但是机器学习中又常用到这些工具和技巧,机器学习中最...从中我们可以大致了解到一些凸优化概念,比如凸集,凸函数,凸优化问题,线性规...
  • 优化笔记(1) —— 基本概念

    千次阅读 2019-01-29 22:57:40
    优化笔记 —— 基本概念1. 数学优化 基本准备 本科没学过凸优化,想趁着还不是太忙,恶补下数学知识,终究是绕不过去的山。应该会不定时的更新凸优化、矩阵论的相关笔记吧,PRML、计算机视觉、概率图模型希望以后...
  • 优化一(基本概念介绍)

    万次阅读 多人点赞 2018-05-10 22:33:13
    优化是一类数学优化问题,介绍凸优化前先简单介绍数学优化问题。 优化问题定义(形式): minimizef0minimizef0 minimize \quad f_{0} subject&amp;nbsp;tofi≤bi,i=1,...,msubject&amp;nbsp;tofi≤bi,i...
  • IGD反转世代距离-多目标优化评价指标概念及实现

    千次阅读 多人点赞 2020-04-17 22:15:47
    IGD反转世代距离-多目标优化评价指标概念及实现 觉得有用的话,欢迎一起讨论相互学习~ 参考资料 多目标进化优化[1]-郑金华老师,邹娟老师著 实验室人手一本人人必看的宝藏图书! IGD(Inverted Generational ...
  • 在介绍凸集等概念之前,首先介绍一下空间几何体的向量表示,下面在定义凸集概念时便用到了线段的线段表示。先通过一个例子来认识一下如何使用向量表示线段 已知二维平面上两定点A(5, 1)、B(2, 3),给出线段AB的方程...
  • 在正题之前,首先明确几个相关概念:(1)凸集(convex set):集合C内任意两点的连线都在集合C内。 (2)凸函数(convex function): 如:(3)Lp范数: (4) L0范数: 一个向量的L0范数等于该向量中非零元素的...
  •     本文由@唐三十胖子出品,转载请注明...这篇文章由唐三胖ヾ(•ω•`)o网络整理总结,针对DrawCall概念的系列优化教程。 通过这篇文章,你可以知道 1)DrawCall概念 2)DC优化勘误 DrawCall概念 ...
  • 以下是我曾在学习“最优化”理论与实践中遇到的一些概念,我刚开始学的时候,有些东西看了很多遍都还觉得很别扭、晦涩难懂,在比较清楚地理解了之后,我打算把它们写下来,并试图以很通俗、但可能不十分严谨的方式...
  • 我们知道MySQL的性能优化方法,一般有建立索引、规避复杂联合查询、设置冗余字段、建立中间表、查询缓存等,也知道用EXPLAIN来查看执行计划。但对MySQL复杂查询语句执行过程和内部机制,MySQL Optimizer本身所做优化...
  • 多目标优化

    千次阅读 2019-01-05 14:22:03
    多目标优化概念 实际问题中大都具有多个目标且需要同时满足,即在同一问题模型中同时存在几个非线性目标,而这些目标函数同时需要进行优化处理,并且这些目标通常是互相冲突的,称此类问题为多目标优化问题。 这些...
  • 动态规划的基本概念和最优化原理

    万次阅读 2015-12-18 15:04:06
    § 2 动态规划的基本概念和最优化原理   多阶段决策过程的特点是每个阶段都要进行决策,具有n个阶段的决策过程的策略是由n个相继进行的阶段决策构成的决策序列。由于前阶段的终止状态又是后一阶段的初始...
  • 视频编解码优化的几个概念

    千次阅读 2017-09-14 17:30:12
    视频编解码优化可以考虑neon,但是gpu不行。 neon 在移动平台上进行一些复杂算法的开发,一般需要用到指令集来进行加速。目前在移动上使用最多的是ARM芯片。 ARM是微处理器行业的一家知名企业,其芯片...
  • 以前做项目一直没有SQL优化概念,直到真正接触到这方面的知识和内容,才发现实际应用上有多重点,此处简要介绍一下关于SQL慢查询的内容,主要是为了有一个大致的概念。 慢SQL的特征 数据库CPU负载高 IO负载高导致...
  • 但是机器学习中又常用到这些工具和技巧,机器学习中最常见的优化当属凸优化了,这些可以参考Ng的教学资料:http://cs229.stanford.edu/section/cs229-cvxopt.pdf,从中我们可以大致了解到一些凸优化概念,...
  • 1、生产力有限,要求取得最大收益,更一般性的说法,是资源分配模型,用来解决在资源有限的情况下,如何将资源分配给彼此竞争的需求,从而实现资源的优化配置。 2、运输问题(产销问题)  要求运输费用...
  • 优化笔记 —— 基本概念之重要的例子1. 简单的例子2. 超平面与半空间3. Euclid球和椭球4. 多面体(较为重要,主要是单纯性)半正定锥 在无尽的酒桌上终于爬了出来,终于可以干点正事了。想看完一部分就写篇博客...
  • 第十二、十三章 查询处理和查询优化
  • 【多目标优化】Pareto优胜的概念

    千次阅读 2008-03-27 11:22:00
    我又参阅了许多源代码,其中Non-dominated Sorting Genetic Algorithm II developed by Kalyanmoy Deb et al.NSGAII--ProfessorKalyan的源代码最具参考价值,显然我对Pareto优胜的概念认识是正确的,但是群体中的...
  • Cocos Creator DrawCall优化

    千次阅读 2019-07-11 00:10:03
    Cocos Creator DrawCall优化概念说明drawCall 是什么如何减少DrawCall在哪里查看 DrawCall合批的流程注意事项不打断合批的操作打断合批的操作其他 概念说明 drawCall 是什么 Draw Call 就是CPU调用图形编程接口,...
  • 1. 基本概念 1.1 Mali-400 MP GPU架构
  • 一些概念介绍 说明: 支配(dominate)也译占优。 非支配解/Pareto最优解/非劣解:无法进行简单相互比较的解,不存在比它更优越解的解,也就是说该解体现了若干 fi(x)f_i(x)fi​(x)的最优(不是所有 fi(x)f_i(x)fi...
  • storm第一篇--概念,例子,参数优化

    万次阅读 2014-10-15 18:30:25
    1 如何优化性能

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 557,618
精华内容 223,047
关键字:

优化的概念