数据仓库
大数据要解决的三个问题:
海量数据的传输
海量数据的存储
海量数据的计算
数据容量单位:b—>B—>KB—>MB—>GB—>TB—>PB—>EB—>ZB—>YB
Hive:由Facebook开源专为处理海量结构化日志数据而设计
Hive:基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张表,并提供类SQL查询功能。
Hive本身不直接存储数据,它允许用户以类SQL(HiveQL)的形式进行数据查询。
Hive本质:将HQL转化成Map Reduce程序
好处:减少开发人员的学习成本,方便任务的运行,降低开发成本
Hive架构图

这张图片是Hive架构的一个简化示意图。它从上至下展示了用户通过Hive进行数据查询和操作的过程,以及Hive是如何与Hadoop生态系统交互的。以下是对图片内容的详细解释:
客户端(Client):
CLI: 命令行界面,用户可以通过它输入HiveQL命令。
JDBC: Java数据库连接,允许应用程序通过Java代码执行HiveQL命令。
驱动器(Driver):
SQL解析器(SQL Parser): 解析用户输入的HiveQL命令,检查语法等。
物理计划(Physical Plan): 将解析后的HiveQL命令转换为执行计划。
查询优化器(Query Optimizer): 对物理计划进行优化,以提高查询效率。
执行器(Execution): 负责实际执行优化后的计划,将优化后的物理计划转换为MapReduce任务。
元存储(Meta Store):
这里存储了有关Hive表和分区的元数据信息。例如表名、数据库、列/分区信息、列的数据类型、表/分区的存储位置等。
元存储可以存储在关系型数据库中,默认使用的是Derby数据库。
HDFS(Hadoop Distributed File System):
Hive表的数据实际存储在HDFS中。HDFS是一个高度可靠、可扩展的分布式文件系统,设计用于运行在低成本的普通硬件上。
MapReduce:
Hive的执行器会将物理计划转换成MapReduce任务执行。
MapReduce是Hadoop的编程模型和处理机制,用于大数据集的并行操作。
整个流程概述如下:用户通过客户端提交HiveQL查询,查询被解析、计划、优化,并最终转换为MapReduce任务在HDFS上执行。查询结果会返回给用户,而查询过程中涉及的元数据信息存储在元存储中。通过这种方式,Hive提供了高级的数据分析能力,同时利用Hadoop生态系统处理海量数据。
Hive运行机制:

Hive的特点:
1)Hive处理的数据存储在HDFS(Hive相当于Hadoop的客户端)
2)Hive分析数据底层的默认实现是Map Reduce(可以修改)
3)执行程序运行在Yarn上(资源调度)
Hive优点:
Hive的执行延迟比较高,因此Hive常用于数据分析,对实时性要求不高的场合使用
Hive支持用户自定义函数,用户可以根据自己的需求来实现自己的函数
Hive缺点:
Hive的HQL表达能力有限
(1)迭代式算法无法表达
(2)数据挖掘方面不擅长
Hive的效率比较低
(1)Hive的自动生成的Map Reduce(吞吐量大,但是速度比较慢)作业,通常情况下不够智能化
(2)Hive调优比窘困难,力度较粗
1. 数据仓库概念
概念:数据仓库(英语:Data Warehouse,简称数仓、DW),是一个用于存储、分析、报告的数据系统。
目的:构建面向分析的集成化数据环境,为企业提供决策支持。
数据仓库本身并不“生产”任何数据,其数据来源于不同外部系统;同时数据仓库自身也不需要“消费”任何的数据,其结果开放给各个外部应用使用,这也是为什么叫“仓库”,而不叫“工厂”的原因。

2. 场景案例:数据仓库为何而来?
简单来说:数据仓库是为了更好地分析数据和支持企业决策而建立的
下面以中国人寿保险公司(chinalife)发展为例,阐述数据仓库为何而来?
2.1 操作型记录的保存
中国人寿保险(集团)公司下辖多条业务线,包括:人寿险、财险、车险,养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。
联机事务处理系统(OLTP)正好可以满足上述业务需求开展, 其主要任务是执行联机事务和查询处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理,并在很短的时间内给出处理结果。关系型数据库是OLTP典型应用,比如:Oracle、Mysql、SQL Server等。
2.2 分析型决策的制定
随着集团业务的持续运营,业务数据将会越来越多。由此也产生出许多运营相关的困惑:
能够确定哪些险种正在恶化或已成为不良险种【高赔付,不赚钱】?
能够用有效的方式制定新增和续保的政策吗?
理赔过程有欺诈的可能吗?
为了能够正确认识这些问题,制定相关的解决措施,最稳妥办法就是:基于业务数据开展数据分析,基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定。
然后,面临下一个问题:在哪里进行数据分析?数据库可以吗?
2.3 OLTP环境开展分析可行吗?
结论:可以,但是没必要。 OLTP的核心是面向业务,支持业务,支持事务。所有的业务操作可以分为读、写两种操作,一般来说读的压力明显大于写的压力。如果在OLTP环境直接开展各种分析,有以下问题需要考虑:
数据分析也是对数据进行读取操作,会让读取压力倍增;
OLTP仅存储数周或数月的数据;
数据分散在不同系统不同表中,字段类型属性不统一;
当分析所涉及数据规模较小的时候,在业务低峰期时可以在OLTP系统上开展直接分析。但是为了更好的进行各种规模的数据分析,同时也不影响OLTP系统运行,此时需要构建一个集成统一的数据分析平台。
该平台的目的很简单:面向分析,支持分析。并且和OLTP系统解耦合。
基于这种需求,数据仓库的雏形开始在企业中出现了。
数据仓库的特点:
集成来自不同来源的数据。
专注于数据分析,与OLTP系统分离。
存储大量历史数据,支持复杂的分析任务。
OLTP和OLAP
(1)OLTP(On-Line Transaction Processing)即联机事务处理,通常指的数据库如Mysql,用于日常业务操作,处理实时数据,重点在于快速响应和数据的准确性。是传统关系型数据库的主要应用。 (2)OLAP(On-Line Analytical Processing)即联机分析处理,通常指的数据仓库如Hive,用于分析和决策支持,处理历史数据,重点在于提供全面、综合的数据视图。是数据仓库系统的主要应用。
下面从多个不同角度来对比OLTP和OLAP
| OLTP | OLAP | |
|---|---|---|
| 数据源 | 仅包含当前运行日常业务数据 | 整合来自多个来源的数据,包括OLTP和外部来源 |
| 目的 | 面向应用,面向业务,支撑事务 | 面向主题,面向分析,支撑分析决策 |
| 焦点 | 当下 | 主要面向过去、面向历史 实时数仓 |
| 任务 | 读写操作 | 大量读而很少写操作 |
| 响应时间 | 毫秒 | 秒、分钟、小时或者天取决于数据量和查询复杂性 |
| 数据量 | 小数据,MB,GB | 大数据,TP,PB |
2.4 数据仓库的构建
如数仓定义所说,数仓是一个用于存储、分析、报告的数据系统,目的是构建面向分析的集成化数据环境。我们把这种面向分析、支持分析的系统称之为OLAP(联机分析处理)系统。数据仓库是OLAP一种。
中国人寿保险公司就可以基于分析决策需求,构建数仓平台。

3. 数据仓库主要特征
数据仓库是面向主题性(Subject-Oriented )、集成性(Integrated)、非易失性(Non-Volatile)和时变性(Time-Variant )数据集合,用以支持管理决策 。
3.1 面向主题性
数据按主题组织(如销售、财务),不是按业务流程。
数据库中,最大的特点是面向应用进行数据的组织,各个业务系统可能是相互分离的。而数据仓库则是面向主题的。
操作型处理(传统数据)对数据的划分并不适用于决策分析。而基于主题组织的数据则不同,它们被划分为各自独立的领域,每个领域有各自的逻辑内涵但互不交叉,在抽象层次上对数据进行完整、一致和准确的描述。

3.2 集成性
将来自不同来源的数据统一起来。
确定主题之后,就需要获取和主题相关的数据。当下企业中主题相关的数据通常会分布在多个操作型系统中,彼此分散、独立、异构。因此在数据进入数据仓库之前,必然要经过统一与综合,对数据进行抽取、清理、转换和汇总,这一步是数据仓库建设中最关键、最复杂的一步,所要完成的工作有:
(1)要统一源数据中所有矛盾之处,如字段的同名异义、异名同义、单位不统一、字长不一致,等等。
(2)进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成,但许多是在数据仓库内部生成的,即进入数据仓库以后进行综合生成的。
下图说明了保险公司综合数据的简单处理过程,其中数据仓库中与“承保”主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同,数据格式也可能不同。把不同来源的数据存储到数据仓库之前,需要去除这些不一致。
3.3 非易失性
数据一旦进入,就不会频繁改变。
数据仓库是分析数据的平台,数据进入数据仓库后,它便稳定且不会改变。
操作型数据库主要服务于日常的业务操作,使得数据库需要不断地对数据实时更新,以便迅速获得当前最新数据,不至于影响正常的业务运作。在数据仓库中只要保存过去的业务数据,不需要每一笔业务都实时更新数据仓库,而是根据商业需要每隔一段时间把一批较新的数据导入数据仓库。
数据仓库的数据反映的是一段相当长的时间内历史数据的内容,是不同时点的数据库快照的集合,以及基于这些快照进行统计、综合和重组的导出数据。
数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘,一旦数据进入数据仓库以后,一般情况下被较长时间保留。数据仓库中一般有大量的查询操作,但修改和删除操作很少。
3.4 时变性
存储历史数据,可以分析数据随时间的变化。
数据仓库包含各种粒度的历史数据,数据可能与某个特定日期、星期、月份、季度或者年份有关。
虽然数据仓库的用户不能修改数据,但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况,当业务变化后,挖掘出的模式会失去时效性。因此数据仓库的数据需要随着时间更新,以适应决策的需要。从这个角度讲,数据仓库建设是一个项目,更是一个过程 。
数据仓库的数据随时间的变化表现在以下几个方面。
(1)数据仓库的数据时限一般要远远长于操作型数据的数据时限。
(2)操作型系统存储的是当前数据,而数据仓库中的数据是历史数据。
(3)数据仓库中的数据是按照时间顺序追加的,它们都带有时间属性。
4. 数据仓库、数据库、数据集市
4.1 OLTP、OLAP
操作型处理,叫联机事务处理OLTP(On-Line Transaction Processing),主要目标是做数据处理,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的关系型数据库系统作为数据管理的主要手段,主要用于操作型处理。
分析型处理,叫联机分析处理OLAP(On-Line Analytical Processing),主要目标是做数据分析。一般针对某些主题的历史数据进行复杂的多维分析,支持管理决策。数据仓库是OLAP系统的一个典型示例,主要用于数据分析。
下面从多个不同角度来对比OLTP和OLAP
| OLTP | OLAP | |
|---|---|---|
| 数据源 | 仅包含当前运行日常业务数据 | 整合来自多个来源的数据,包括OLTP和外部来源 |
| 目的 | 面向应用,面向业务,支撑事务 | 面向主题,面向分析,支撑分析决策 |
| 焦点 | 当下 | 主要面向过去、面向历史 实时数仓 |
| 任务 | 读写操作 | 大量读而很少写操作 |
| 响应时间 | 毫秒 | 秒、分钟、小时或者天取决于数据量和查询复杂性 |
| 数据量 | 小数据,MB,GB | 大数据,TP,PB |
4.2 数据仓库、数据库
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。
OLTP系统的典型应用就是RDBMS,也就是我们俗称的数据库,当然这里要特别强调此数据库表示的是关系型数据库,Nosql数据库并不在讨论范围内。
OLAP系统的典型应用就是DW,也就是我们俗称的数据仓库。
因此数据仓库和数据库的区别就很好掌握了。但是有几点需要着重强调:
数据处理方式:数据库主要用于事务处理,通常是实时的插入、更新和删除操作;而数据仓库主要用于数据分析,大多是批量的读取和分析操作。
数据存储:数据库通常存储的是操作型数据,以支持日常的业务运营;数据仓库则存储的是经过清理、转换和集成的历史数据,用于决策支持和分析。
应用场景:数据库主要用于支持在线交易、业务流程等;数据仓库则主要用于数据分析、报表生成、数据挖掘等。
4.2 数据仓库、数据集市
数据仓库是面向整个集团组织的数据,数据集市是面向单个部门使用的。可以认为数据集市是数据仓库的子集,也有人把数据集市叫做小型数据仓库。数据集市通常只涉及一个主题领域,例如市场营销或销售。因为它们较小且更具体,所以它们通常更易于管理和维护,并具有更灵活的结构。
比如上图所示:
各种操作型系统数据和包括文件在内的等其他数据作为数据源,经过ETL(抽取转换加载)填充到数据仓库中;
数据仓库中有不同主题数据,数据集市则根据部门特点面向指定主题,比如Purchasing(采购)、Sales(销售)、Inventory(库存);
用户可以基于主题数据开展各种应用:数据分析、数据报表、数据挖掘。
5. 数据仓库分层架构
5.1 数仓分层思想和标准
数据仓库的特点是本身不生产数据,也不最终消费数据。按照数据流入流出数仓的过程进行分层就显得水到渠成。
数据分层每个企业根据自己的业务需求可以分成不同的层次,但是最基础的分层思想,理论上数据分为三个层:
操作型数据层(ODS)、数据仓库层(DW)和数据应用层(DA)

企业在实际运用中可以基于这个基础分层之上添加新的层次,来满足不同的业务需求。
5.2 阿里巴巴数仓3层架构
5.3 数据仓库的主要组成层次
数据仓库系统通常分为几个主要层次,每个层次都有其特定的功能和作用。这些层次包括:
操作型数据层(ODS,Operation Data Store):
这是数据仓库中的第一层,负责存储原始数据。
这些数据直接来自企业的日常运营系统,例如销售记录或交易数据。
在这一层,数据的结构与源系统保持一致,这些数据还没有经过加工或整合。
数据仓库层(DW,Data Warehouse):
维度表(DIM):维度表(DIM):维度表用于存储描述性信息,如商品、地区等,以创建统一的维度标准,为数据分析提供上下文。
在电商数据仓库中,可以创建维度表来存储商品信息。例如,一个商品维度表可以如下所示:
商品ID 商品名称 商品类别 品牌 供应商ID 101 手机 电子产品 Apple 201 102 电视 家电 Samsung 202 103 洗衣机 家电 LG 203 104 运动鞋 服装 Nike 204 汇总事实表(DWS/DWB):根据业务需求对数据进行汇总,创建用于分析的汇总数据表。
汇总事实表用于汇总业务数据,例如销售数据。一个示例销售汇总事实表如下:
日期ID 商品ID 地区ID 销售数量 销售金额 202201 101 1 100 50000 202201 102 1 80 60000 202201 101 2 120 60000 202201 103 2 50 25000 在这个示例中,销售汇总事实表包含了每个商品在每个地区的销售数量和销售金额,以便于分析不同商品和地区的销售趋势。
明细事实表(DWD):存储具体的业务事实数据,可能包含某些维度数据的冗余,以便更快地访问。
明细事实表用于存储每个销售交易的详细信息。一个示例销售明细事实表如下:
交易ID 日期ID 商品ID 地区ID 顾客ID 销售数量 销售金额 1 202201 101 1 1001 10 5000 2 202201 102 1 1002 8 6000 3 202201 101 2 1003 12 6000 4 202201 103 2 1004 5 2500 这是数据仓库的核心层,它从ODS层接收数据,对这些数据进行加工和整合。
主要包括以下几个部分:
数据应用层(DA或ADS):
这是面向最终用户的层次,提供各种数据应用和分析工具。
包括报表(销售报表、库存报表)、图表、关键性能指标(KPI)、仪表盘、在线分析处理(OLAP)专题和数据挖掘等。
这一层的目的是使数据分析更加直观和容易理解,以支持业务决策。
简而言之,数据仓库系统是一个分层结构,从原始数据的存储(操作型数据层),到数据的加工整合(数据仓库层),最后到为用户提供数据分析和应用的接口(数据应用层)。这种结构使得数据可以有效地被存储、管理、加工,并最终用于辅助业务决策。
5.4 ETL 和 ELT
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL的过程。
ETL:Extract抽取,Transform转换,Load加载
首先从数据源池中提取数据,这些数据源通常是事务性数据库。数据保存在临时暂存数据库中。然后执行转换操作,将数据结构化并转换为适合目标数据仓库系统的形式。然后将结构化数据加载到仓库中,以备分析。
5.4 为什么要分层
分层的目的是为了更有效地管理和理解数据,具体原因包括:
清晰度:分层帮助明确每类数据的功能和位置,便于使用和理解。
追踪性:便于追溯数据源,当数据出现问题时,可以快速定位和评估影响范围。
效率:标准化中间层减少了重复处理,提高了开发效率。
简化处理:分步处理复杂问题,简化操作,便于维护和错误修复。
稳定性:隔离原始数据的问题,减少业务变更对数据层的直接影响。
6.数据仓库的数据模型
6.1 什么是事实表、维度表和中间表?
事实表:它就像是数据仓库的核心,里面存着各种和维度表有关系的关键信息。
维度表:可以当作是观察数据的角度,通过它能得到很多有用的数据。
中间表:用来存放一些中间计算结果,方便进行更复杂的计算。
销售数据仓库:
事实表:可能是一个名为“销售订单”的表格,其中包含每笔销售的详细信息,如订单号、销售日期、产品 ID、客户 ID、销售数量和销售金额等。
维度表
“产品”维度表,包含产品的信息,如产品名称、产品类别和产品价格等。
“客户”维度表,包含客户的信息,如客户姓名、客户地址和客户年龄等。
中间表:比如“月销售额”中间表,用于计算每个月的总销售额。
6.2 数据仓库的数据模型主要有哪些?
星状模型: 以一个事实表和一组维度表组合而成。

雪花状模型: 也是维度建模中的另一种选择,它是对星状模型的扩展。

二、Apache Hive入门
1.Apache Hive概述
1.1 什么是Hive
Apache Hive是一款建立在Hadoop之上的开源数据仓库系统,可以将存储在Hadoop文件中的结构化数据映射为一张数据库表,提供了类似SQL的查询模型,称为Hive查询语言(HQL),用于访问和分析存储在Hadoop文件中的大型数据集。
Hive核心是将HQL转换为MapReduce程序,然后将程序提交到Hadoop群集执行。
1.2 Hive处理数据的优势
提供类SQL语法操作接口,易学易用,加速开发。
无需直接编写MapReduce代码,降低学习和开发成本。
支持自定义函数,便于扩展功能。
依托Hadoop,高效处理和分析大数据。
1.3 Hive与Hadoop的关系
数据仓库软件Hive,Hive借助Hadoop也具备上述两种能力:
存储数据的能力
分析数据的能力
Hive利用HDFS存储数据,利用MapReduce查询分析数据。
这样突然发现Hive没啥用,不过是套壳Hadoop罢了。其实不然,Hive的最大的魅力在于用户专注于编写HQL,Hive帮您转换成为MapReduce程序完成对数据的分析。
2.场景设计:如何模拟实现Hive的功能
2.1 场景需求
在HDFS文件系统上有一个文件,路径为/data/china_user.txt,其内容如下:
1,zhangsan,18,beijing2,lisi,25,shanghai3,allen,30,shanghai4,wangwu,15,nanjing5,james,45,hangzhou6,tony,26,beijing
需求:统计来自于上海年龄大于25岁的用户有多少个?
1,zhangsan,18,beijing
2,lisi,25,shanghai
3,allen,30,shanghai
4,wangwu,15,nanjing
5,james,45,hangzhou
6,tony,26,beijing
如果让您设计Hive这款软件,要求能够实现用户编写sql语句,Hive自动将sql转换MapReduce程序,处理位于HDFS上的结构化数据。如何实现?
2.2 场景目的
重点理解下面两点:
Hive能将数据文件映射成为一张表,这个映射是指什么?
Hive软件本身到底承担了什么功能职责?
2.3 功能实现关键
映射信息记录
映射在数学上称之为一种对应关系,比如y=x+1,对于每一个x的值都有与之对应的y的值。在hive中能够写sql处理的前提是针对表,而不是针对文件,因此需要将文件和表之间的对应关系描述记录清楚。映射信息专业的叫法称之为元数据信息(元数据是指用来描述数据的数据 metadata)。
具体来看,要记录的元数据信息包括:
表对应着哪个文件(位置信息)
表的列对应着文件哪一个字段(顺序信息)
文件字段之间的分隔符是什么
Sql语法解析、编译
用户写完sql之后,hive需要针对sql进行语法校验,并且根据记录的元数据信息解读sql背后的含义,制定执行计划。并且把执行计划转换成MapReduce程序来执行,把执行的结果封装返回给用户。
2.4 最终效果
基于上述分析,最终要想模拟实现的Hive的功能,大致需要下图所示组件参与其中,从中可以感受一下Hive承担了什么职责。
当然,也可以把这个理解为hive的架构图。
3. Hive架构、组件
3.1 Hive架构图
3.2 Hive组件
用户接口:包括 CLI、JDBC/ODBC、WebGUI。其中,CLI(command line interface)为shell命令行;Hive中的Thrift服务器允许外部客户端通过网络与Hive进行交互,类似于JDBC或ODBC协议。WebGUI是通过浏览器访问Hive。
元数据存储:通常是存储在关系数据库如 mysql/derby中。Hive 中的元数据包括表的名字,表的列和分区及其属性,表的属性(是否为外部表等),表的数据所在目录等。
Driver驱动程序,包括语法解析器、计划编译器、优化器、执行器:完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中,并在随后有执行引擎调用执行。
执行引擎:Hive本身并不直接处理数据文件。而是通过执行引擎处理。当下Hive支持MapReduce、Tez、Spark3种执行引擎。
4. Hive数据模型(Data Model)
数据模型:用来描述数据、组织数据和对数据进行操作,是对现实世界数据特征的描述。
Hive的数据模型类似于RDBMS库表结构
Hive中的数据可以在粒度级别上分为三类:
Table 表
Partition分区
Bucket 分桶
4.1 Databases
Hive是一个数据仓库,它采用类似传统数据库的结构,分为多个数据库,每个数据库包含多个表。默认数据库名为"default"。
Hive的数据存储在HDFS上,有一个默认的根目录,可以在hive-site.xml中的参数hive.metastore.warehouse.dir中指定,默认为/user/hive/warehouse。
因此,在Hive中,数据库在HDFS上的存储路径为:
${hive.metastore.warehouse.dir}/数据库名.db例如,如果数据库名为"itcast",则它在HDFS上的存储路径为:
/user/hive/warehouse/itcast.db
4.2 Tables
Hive的表与传统关系数据库中的表类似,但有一些不同之处。Hive中的表数据存储在Hadoop文件系统(通常是HDFS)中,而表的元数据则存储在关系型数据库中。
通常情况下,Hive表的数据存储在HDFS中,尽管也可以存储在其他Hadoop文件系统中,比如本地文件系统或S3。Hive有两种类型的表:
Managed Table(内部表、托管表):这是默认创建的表类型。关于内部表和外部表的区别,我们会在后续知识点中详细探讨。
Hive中表的数据在HDFS上的存储路径为:
${hive.metastore.warehouse.dir}/数据库名.db/表名
例如,如果数据库名为"itcast",表名为"t_user",那么该表的数据存储路径为:
/user/hive/warehouse/itcast.db/t_user
4.3 Partitions
Hive中的分区是一种优化手段,通过将表按照分区列的不同值划分为不同的分区,以加快对特定分区数据的查询速度。
在存储层面上,分区表现为表目录下的子文件夹,每个子文件夹表示一个分区,
子文件夹的命名遵循格式:分区列=分区值。
此外,Hive还支持多级分区,也就是在一个分区下继续创建分区,这被称为多重分区。有关分区表的使用和详细介绍,将在后续模块中进行单独详细讲解。
4.4 Buckets
Bucket分桶表是hive的一种优化手段表。分桶是指根据表中字段(例如“编号ID”)的值,经过hash计算规则将数据文件划分成指定的若干个小文件。
分桶规则:hashfunc(ID) % 桶个数,余数相同的分到同一个文件。
分桶的好处是可以优化join查询和方便抽样查询。Bucket分桶表在hdfs中表现为同一个表目录下数据根据hash散列之后变成多个文件。关于桶表以及分桶操作,后面模块会单独展开详细讲解。
5. Hive是要取代Mysql吗?
Hive虽然具有RDBMS数据库的外表,包括数据模型、SQL语法都十分相似,但应用场景却完全不同。Hive只适合用来做海量数据的离线分析。Hive的定位是数据仓库,面向分析的OLAP系统。
因此时刻告诉自己,Hive不是大型数据库,也不是要取代Mysql承担业务数据处理。
更直观的对比请看下面这幅图: