Hive参数深入浅出，Hive企业应用

1Hive参数介绍

 

 

 特别说明（面试大概率会问）

        一 关于数据倾斜的问题

        1概念说明：

                在大数据处理环境下，数据处理过程出现明显的倾斜现象，导致任务整体迟迟不能完全结束

        2特点特征：

                a在作业或是任务在分布式执行时，经常会出现大部分Task任务很快结束，但可能会有很少一部分Task，往往是1-2个一直卡在99%的情况下。

                b典型的木桶原理，任务执行完成时间，取决于最后一个Task的完成时间

         3应用场景 

                假倾斜场景：

                实际数据并没有倾斜，而是由于认为代码原因导致的倾斜。

         如：数据格式设置不对，导致没有发挥分布式处理的优势。SQL编写不合理---计算用户uv数

进行代码优化就可以了

                真倾斜场景：

                    a 即数据或是任务本身真的存在客观的倾斜性

                如：VIP会员数据的倒卖倒买问题，账号对应的数据量极多，而正常账号较少

                  解决方法：分而治之，将倾斜的数据分类，将正常数据分类，然后进行分别计算

                b 硬件机器本身配置不均衡导致的计算能力倾斜问题

                   解决方法： ①硬性解决即让硬件更加均衡

                                        ②通过nodeLabel方式

二 关于 MapJoin的问题

              1 概念说明 

                    a  将join的本来应该是 reduce进行关联查找的过程改成由纯map端进行关联查找

               2 特点特征

                      a 减少了reduce 的处理，全部放到map端进行操作

                      b 减少了数据移动，替身了 IO和计算效率

                3 应用场景

                        a  大表 join 小表的时候

                        b 大数据join  小数据块的时候

                4 代码实现 

                        在hive 当中已经默认开启了该功能

三  关于二次排序的 问题

        1概念说明：

                在map 到 reduce的 处理过程当中，按照 2个字段进行升序排列，而不是像默认的一次排序那样只按照key 一个字段排序。

           2特点特征：

                a    2个字段排序，第1个字段若有比较结果则按第1个字段排，若相等，则按第 2个字段 升序排列

             3 应用场景：

                当单个字段不能满足排序要求时，均可采用二次排序

                4代码实现

1. Hadoopcore之mapreduce实现
   1. 重写Map和Reduce之前的输入输出的Key和Value。
   2. HiveSQL实现
      1. Select * from table order by c1,c2 asc

HIive 脚本 

        1 创建一个shell 文件   名字 hive_shell.sh：touch hive_shell.sh

        2 编辑文件

#!/bin/sh
db="库名"
table_name="表名"
hive -e "
use $db;
set tez.queue.name=oncourse;
select count(1) from $table_name;

3 执行脚本  sh hive_shell.sh 

                                Hive 企业应用

  数据仓库架构设计

        数据仓库的主要工作就说 ETL，即英文Extract-Transform-Load 的缩写，用来描述数据从来源端经过 装载（load）、抽取（extract）、转换（transform）至目的端的过程。

        数据仓库架构设计，即为公司针对自身业务场景实现的水平分层、垂直分主题的数据仓库构建过程的顶层设计。

   一 数据架构 

        1架构原则： 先水平分层，在垂直分主题域

        2数据架构分三层：

                 源数据落地区（SDF： Source  Data File）

                数据仓库层 （DW： Data  WareHouse）

                数据集市层：（DM： Data  Market）

        3数据仓库层进一步细分为 三层

                源数据层（DWB）

                细节数据层(DWD)

                汇总数据层（DWS）

 

        2数据仓库分层介绍（水平划分）

3按主题划分（垂直划分） 

 二 数据仓库建模

        1概念定义

              a数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事物的相互关系的一种映射

               b数据模型表现的抽象是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

                c 数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型。

                d     数据建模即数2据模型的构建和应用过程。

                e    数据仓库建模即数据仓库模型的构建和应用过程。

2 数据仓库建模的发展历史与意义

   A数据仓库建模的阶段发展

         a 简单报表阶段

                主要解决一些日常工作中业务人员需要的报表及生成一些简单的洪总数据

                大部分表现形式为 数据库和     前端报表工具

                特点：简单。单一

        b 数据集市阶段

                该阶段主要是根据某个业务部门的需要，进行一定的数据采集，整理，提供特定业务指导的数据和提供特定的领导决策数据

                特点：多难度，业务场景化，按需定制性

        c 数据仓库阶段

                该阶段系统主要 按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门的，完全一致的业务报表数据，生成对业务具有指导性的数据，为领导决策体统全面的数据支持。

                特点： 全面，灵活，数据模型支持，体系化。

B数据建模的意义

• • 进行全面的业务梳理，改进业务流程。
    • 对公司进行全面梳理
    • 了解公司的业务运行架构和运行状态
    • 为改进公司架构、提升运营效率、指导生产提供科学支撑。
  • 建立全方位的数据视角，消灭信息孤岛和数据差异。
    • 提供公司数据的全面视角，不再是部门各自为战。
    • 清晰化部门间的内在联系，消灭部门之间的信息孤岛。
    • 保证公司全局数据的一致性，消灭差异性。
  • 解决业务的变动和数据仓库的灵活性。
    • 将底层技术实现与业务表达展现解耦。
    • 需求的变动或新需求，可以最小化的成本达到目标。
  • 帮助数据仓库系统本身的建设。
    • 技术开发人员和业务需求人员较容易达成一致意见。
    • 各方人员明确当前数据状况，便于做当前任务评估和长远构建规划。

2 如何构建数据模型

                数据模型的层次的一般划分

 

• 各层次说明
  • 业务建模，生成业务模型，主要解决业务层面的分解和程序化。
  • 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
  • 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
  • 物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
• 构建方法
  • 数据建模构建与数据仓库架构设计有紧密关系，要优先吸收数据仓库架构设计即上一节内容。
  • 数据仓库的建模方法有很多，每一种建模方法则代表哲学上的一个观点，代表了一种归纳，概括世界的一种方法。
  • 目前的构建方法主要有三种：
    • 范式建模法
    • 维度建模法
    • 实体建模法
• 具体构建方法详解
  • 范式建模法
    • 范式建模法其实是我们在构建数据模型常用的方法之一。
    • 主要解决关系型数据库得数据存储，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
    • 数据库六大范式说明
      • 第1范式-1NF：无重复的列、列不可再拆分。
      • 第2范式-2NF：属性完全依赖于主键
      • 第3范式-3NF：属性不依赖于其它非主属性，即属于依赖于主键不能出现传递依赖。
      • 巴斯-科德范式（BCNF），第四范式(4NF），第五范式（5NF，又称完美范式）
    • 特别说明
      • 范式建模优点
        • 从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。
      • 范式建模缺点
        • 其建模方法限定在关系型数据库之上，在有些时候(需要冗余的时候)反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要灵活调整才能达到要求。
      • 使用建议：当不需要冗余设计提高易用性和计算效率时，可以采用这种模式。（常见的即为web项目开发中）

• • 维度建模法
    • 即按照事实表，维度表来构建数据仓库，即最被人广泛知晓的名字就是星型模式（Star-schema）和雪花模式（Snowflake-schema）。
    • 重要概念说明
      • 事实表：
        • 发生在某个时间点上的一个事件，即具体的实体内容。比如以电商订单为例：下单是一个事实、付款是一个事实、退款是一个事实，所有事实的累计形成的表，均为事实表
      • 维度表
        • 维度表是从事实表中抽离出来的分析粒度。
        • 维度表可以看作是用户来分析数据的窗口(视角)，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息.
    • 星型建模法
      • 定义:维度表全部直接关联到事实表中，其形状类似星星，故称之

 

 

• • • 雪花建模法
      • 定义
        • 维度表并非全部关联到事实表中，存在一个或多个表没有直接关联到事实表中时，其形状类似雪花，故称之。
      • 举例如上：
        • 将地域维表又分解为国家，省份，城市等维表。
        • 优点是通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
        • 如下图所示：

         

• • • 关于星形和雪花模型进行维度建模的对比说明
      • 定义
        • 星形模型：维度表全部直接关联到事实表中，其形状类似星星，故称之。
        • 雪花模型：维度表并非全部关联到事实表中，存在一个或多个表没有直接关联到事实表中时，其形状类似雪花，故称之。
      • 相同点
        • 雪花模型属于星形模型的扩展，属于星形模型。
        • 都是围绕事实表、维度表展开模型构建，只是层次设计不尽相同。
      • 差异点
        • 星型架构的设计由于没有像现实世界当中的抽象情况进行层级依赖，所以是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余设计。
        • 雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的“层次”区域，这些被分解的表都连接到主维度表而不是事实表。
      • 对比总结说明
        • 数据规范性：雪花胜于星型。
        • 性能：雪花的表关联较多，并行性和计算性能上会低于性能上往往低于星型。
        • ETL开发:雪花关系多则关联多，代码量较复杂一些。而星型数据较集中，关联少，代码量会少一些。
        • 实际使用，两者应用的均比较多，但星型略胜一筹。
    • 关于维度建模法的总结说明
      • 广泛被使用的原因：在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等，能够极大的提升数据仓库的处理能力。
      • 维度建模优点
        • 由于其可以有必要合理的冗余和其它范式建模的严格限制，相对于针对3NF 的建模方法，星型模式在性能上占据明显的优势。
        • 维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。
      • 维度建模缺点
        • 由于在构建星型模式之前需要进行大量的数据预处理，会带来大量的数据处理工作。
        • 业务发生变化后，往往需要更新维度的预处理。
        • 存储和处理过程中，数据冗余量较大
        • 依靠维度建模的话，其维度必然会且维护成本增大，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
      • 使用建议：在数据架构设计中的细节数据层、汇总数据层、数据集市层等需要提升计算性能的时候，均可以使用，也是建模过程中逻辑建模阶段最常用的方法之一。（常用于数据仓库模型设计）
  • 实体建模法
    • 实体建模法并不是数据仓库建模中常见的一个方法。
    • 源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。