hive相关内容

一UDF

因为系统内置函数无法解决所有的问题，所以这时候就需要开发人员自己定义函数

实现步骤(Java创建自定义UDF类)

1. 自定义一个java类
2. 继承UDF类
3. 约定俗成的重写evaluate方法
4. 打包类所在项目成一个all-in-one的jar包并上传到hive所在机器
5. 在hive中执行add jar操作，将jar加载到classpath中。
6. 在hive中创建模板函数，使得后边可以使用该函数名称调用实际的udf函数
7. hive sql中像调用系统函数一样使用udf函数

代码实现之后就是打包上传到hdfs上，然后去hive里面 add jar hdfs：///路径

在然后create temporary function 名字 as ‘里面写主类’

二 UDAF

1. in:out=n:1,即输入N条数据，返回一条处理结果，即列转行。
2. 最常见的系统聚合函数，如count,sum,avg,max等

实现步骤：

1. 自定义一个java类
2. 继承UDAF类
3. 内部定义一个静态类，实现UDAFEvaluator接口
4. 实现方法init,iterate,terminatePartial,merge,terminate共5个方法.

三 UDTF

这个用的比较少 主要的内容就是1：N

 四 数据仓库架构设计

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

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

数据架构

原则：先水平分层，再垂直分主题域

数据架构分三层

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

数据仓库层(DW:Data WareHouse)

数据集市层(DM:Data Market)

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

2. 源数据层(DWB)

   细节数据层(DWD)

   汇总数据层(DWS)

 数据仓库分层介绍(水平划分)

 

按主题划分（垂直划分）

 

五数据仓库建模

概念定义：

• 数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。  
• 数据模型表现的抽象是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。
• 数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型。
• 数据建模即数2据模型的构建和应用过程。

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

构建数据模型

 

• 各层次说明
  • 业务建模，生成业务模型，主要解决业务层面的分解和程序化。
  • 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
  • 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
  • 物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
• 构建方法
  • 数据建模构建与数据仓库架构设计有紧密关系，要优先吸收数据仓库架构设计即上一节内容。
  • 数据仓库的建模方法有很多，每一种建模方法则代表哲学上的一个观点，代表了一种归纳，概括世界的一种方法。
  • 目前的构建方法主要有三种：
    • 范式建模法
    • 维度建模法
    • 实体建模法
• 具体构建方法详解
  • 范式建模法
    • 范式建模法其实是我们在构建数据模型常用的方法之一。
    • 主要解决关系型数据库得数据存储，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
    • 数据库六大范式说明
      • 第1范式-1NF：无重复的列、列不可再拆分。
      • 第2范式-2NF：属性完全依赖于主键
      • 第3范式-3NF：属性不依赖于其它非主属性，即属于依赖于主键不能出现传递依赖。
      • 巴斯-科德范式（BCNF），第四范式(4NF），第五范式（5NF，又称完美范式）
    • 特别说明
      • 范式建模优点
        • 从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。
      • 范式建模缺点
        • 其建模方法限定在关系型数据库之上，在有些时候(需要冗余的时候)反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要灵活调整才能达到要求。
      • 使用建议：当不需要冗余设计提高易用性和计算效率时，可以采用这种模式。（常见的即为web项目开发中）
  • 维度建模法
    • 即按照事实表，维度表来构建数据仓库，即最被人广泛知晓的名字就是星型模式（Star-schema）和雪花模式（Snowflake-schema）。
    • 重要概念说明
      • 事实表：
        • 发生在某个时间点上的一个事件，即具体的实体内容。比如以电商订单为例：下单是一个事实、付款是一个事实、退款是一个事实，所有事实的累计形成的表，均为事实表
      • 维度表
        • 维度表是从事实表中抽离出来的分析粒度。
        • 维度表可以看作是用户来分析数据的窗口(视角)，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息.
        • • • 星型建模法
              • 定义:维度表全部直接关联到事实表中，其形状类似星星，故称之

        • 

        • • • • 举例说明（销售类数据仓库构建）
                • 如在地域维度表中，存在国家A省B的城市C，及国家A省B的城市D两条记录，那么国家A和省B的信息分别存储了两次，即存在冗余。

        • 

           

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

        • 

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