Hive數(shù)據(jù)倉(cāng)庫(kù)簡(jiǎn)介

Hive起源于Facebook，F(xiàn)acebook公司有著大量的日志數(shù)據(jù)，而Hadoop是實(shí)現(xiàn)了MapReduce模式開(kāi)源的分布式并行計(jì)算的框架，可輕松處理大規(guī)模數(shù)據(jù)。然而MapReduce程序?qū)κ煜ava語(yǔ)言的工程師來(lái)說(shuō)容易開(kāi)發(fā)，但對(duì)于其他語(yǔ)言使用者則難度較大。因此Facebook開(kāi)發(fā)團(tuán)隊(duì)想設(shè)計(jì)一種使用SQL語(yǔ)言對(duì)日志數(shù)據(jù)查詢分析的工具，而Hive就誕生于此，只要懂SQL語(yǔ)言，就能夠勝任大數(shù)據(jù)分析方面的工作，還節(jié)省了開(kāi)發(fā)人員的學(xué)習(xí)成本。

一、數(shù)據(jù)倉(cāng)庫(kù)簡(jiǎn)介

1. 什么是數(shù)據(jù)倉(cāng)庫(kù)

數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)面向主題的、集成的、隨時(shí)間變化的，但信息本身相對(duì)穩(wěn)定的數(shù)據(jù)集合，它用于支持企業(yè)或組織的決策分析處理，這里對(duì)數(shù)據(jù)倉(cāng)庫(kù)的定義，指出了數(shù)據(jù)倉(cāng)庫(kù)的三個(gè)特點(diǎn)。

（1）數(shù)據(jù)倉(cāng)庫(kù)是面向主題的。

操作型數(shù)據(jù)庫(kù)的數(shù)據(jù)組織是面向事務(wù)處理任務(wù)，而數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)是按照一定的主題域進(jìn)行組織，這里說(shuō)的“主題”是一個(gè)抽象的概念，它指的是用戶使用數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行決策時(shí)關(guān)心的重點(diǎn)方面，一個(gè)主題通常與多個(gè)操作型信息系統(tǒng)相關(guān)。例如，商品的推薦系統(tǒng)就是基于數(shù)據(jù)倉(cāng)庫(kù)設(shè)計(jì)的，商品的信息就是數(shù)據(jù)倉(cāng)庫(kù)所面向的主題。

（2）數(shù)據(jù)倉(cāng)庫(kù)是隨時(shí)間變化的。

數(shù)據(jù)倉(cāng)庫(kù)是不同時(shí)間的數(shù)據(jù)集合，它所擁有的信息并不只是反映企業(yè)當(dāng)前的運(yùn)營(yíng)狀態(tài)，而是記錄了從過(guò)去某一時(shí)間點(diǎn)到當(dāng)前各個(gè)階段的信息。可以這么說(shuō)，數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)保存時(shí)限要能滿足進(jìn)行決策分析的需要(如過(guò)去的5~10年），而且數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)都要標(biāo)明該數(shù)據(jù)的歷史時(shí)期。

（3）數(shù)據(jù)倉(cāng)庫(kù)相對(duì)穩(wěn)定。

數(shù)據(jù)倉(cāng)庫(kù)是不可更新的。因?yàn)閿?shù)據(jù)倉(cāng)庫(kù)主要目的是為決策分析提供數(shù)據(jù)，所涉及的操作主要是數(shù)據(jù)的查詢，一旦某個(gè)數(shù)據(jù)存入數(shù)據(jù)倉(cāng)庫(kù)以后，一般情況下將被長(zhǎng)期保留，也就是數(shù)據(jù)倉(cāng)庫(kù)中一般有大量的查詢操作，修改和刪除操作很少，通常只需要定期的加載、刷新來(lái)更新數(shù)據(jù)。

多學(xué)一招：OLTP和OLAP

數(shù)據(jù)處理大致可以分為兩類，分別是聯(lián)機(jī)事務(wù)處理（OLTP）和聯(lián)機(jī)分析處理（OLAP)，其中：

(1)OLTP是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的主要應(yīng)用，主要針對(duì)的是基本的日常事務(wù)處理，例如，銀行轉(zhuǎn)賬。

(2）OLAP是數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果，例如，商品的推薦系統(tǒng)。

接下來(lái)，通過(guò)一張表來(lái)比較OLTP和OLAP，具體如表所示。

對(duì)比項(xiàng)目	OLTP	OLAP
用戶	操作人員、底層管理人員	決策人員、高級(jí)管理人員
功能	日常操作處理	分析決策
DB設(shè)計(jì)	基于ER模型，面向應(yīng)用	星型/雪花型模型，面向主題
DB規(guī)模	GB至TB	≥TB
數(shù)據(jù)	最新的、細(xì)節(jié)的、二維的、分立的	歷史的、聚集的、多維的、集成的
存儲(chǔ)規(guī)模	讀/寫數(shù)條（甚至數(shù)百條）記錄	讀上百萬(wàn)條（甚至上億條）記錄
操作頻度	非常頻繁（以秒計(jì)）	比較稀松（以小時(shí)甚至以周計(jì)）
工作單元	嚴(yán)格的事務(wù)	復(fù)雜的查詢
用戶數(shù)	數(shù)百個(gè)至數(shù)千萬(wàn)個(gè)	數(shù)個(gè)至數(shù)百個(gè)
度量	事務(wù)吞吐量	查詢吞吐量、響應(yīng)時(shí)間

2. 數(shù)據(jù)倉(cāng)庫(kù)的結(jié)構(gòu)

數(shù)據(jù)倉(cāng)庫(kù)的結(jié)構(gòu)是由數(shù)據(jù)源、數(shù)據(jù)存儲(chǔ)及管理、OLAP服務(wù)器和前端工具四個(gè)部分組成。

2.1 數(shù)據(jù)源

數(shù)據(jù)源是數(shù)據(jù)倉(cāng)庫(kù)的基礎(chǔ)，即系統(tǒng)的數(shù)據(jù)來(lái)源，通常包含企業(yè)的各種內(nèi)部信息和外部信息。

內(nèi)部信息，例如存在數(shù)據(jù)操作數(shù)據(jù)庫(kù)中的各種業(yè)務(wù)數(shù)據(jù)和自動(dòng)化系統(tǒng)中包含的各類文檔數(shù)據(jù)；外部信息，例如各類法律法規(guī)，市場(chǎng)信息、競(jìng)爭(zhēng)對(duì)手的信息以及外部統(tǒng)計(jì)數(shù)據(jù)和其他相關(guān)文檔等。

2.2 數(shù)據(jù)存儲(chǔ)與管理

數(shù)據(jù)存儲(chǔ)及管理是整個(gè)數(shù)據(jù)倉(cāng)庫(kù)的核心。數(shù)據(jù)倉(cāng)庫(kù)的組織管理方式?jīng)Q定了它有別于傳統(tǒng)數(shù)據(jù)庫(kù)，同時(shí)也決定了對(duì)外部數(shù)據(jù)的表現(xiàn)形式。針對(duì)系統(tǒng)現(xiàn)有的數(shù)據(jù)，進(jìn)行抽取、清理并有效集成，按照主題進(jìn)行組織。數(shù)據(jù)倉(cāng)庫(kù)按照數(shù)據(jù)的覆蓋范圍可以劃分為企業(yè)級(jí)數(shù)據(jù)倉(cāng)庫(kù)和部門級(jí)數(shù)據(jù)倉(cāng)庫(kù)，也就是所謂的數(shù)據(jù)集市。數(shù)據(jù)集市可以理解為是一個(gè)小型的部門或者工作組級(jí)別的數(shù)據(jù)倉(cāng)庫(kù)。

2.3 OLAP服務(wù)器

OLAP服務(wù)器對(duì)需要分析的數(shù)據(jù)按照多維數(shù)據(jù)模型進(jìn)行重組，以支持用戶隨時(shí)進(jìn)行多角度、多層次的分析，并發(fā)現(xiàn)數(shù)據(jù)規(guī)律和趨勢(shì)。

2.4 前端工具

前端工具主要包含各種數(shù)據(jù)分析工具、報(bào)表工具、查詢工具、數(shù)據(jù)挖掘工具以及各種基于數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)集市開(kāi)發(fā)的應(yīng)用。

3. 數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)模型

在數(shù)據(jù)倉(cāng)庫(kù)建設(shè)中，一般會(huì)圍繞著星狀模型和雪花模型來(lái)設(shè)計(jì)數(shù)據(jù)模型。下面先來(lái)介紹這兩種模型的概念。

3.1 星狀模型

在數(shù)據(jù)倉(cāng)庫(kù)建模中，星狀模型是維度建模中的一種選擇方式。星狀模型是由一個(gè)事實(shí)表和一組維度表組合而成，并且以事實(shí)表為中心，所有的維度表直接與事實(shí)表相連。

在上圖中，所有的維度表都直接連接到事實(shí)表上，維度表的主鍵放置在事實(shí)表中，作為事實(shí)表與維度表連接的外鍵，因此，維度表和事實(shí)表是有關(guān)聯(lián)的，然而，維度表與維度表并沒(méi)有直接相連，因此，維度表之間是并沒(méi)有關(guān)聯(lián)的。

3.2 雪花模型

雪花模型也是維度建模中的另一種選擇，它是對(duì)星型模型的擴(kuò)展。

雪花模型是當(dāng)有一個(gè)或多個(gè)維表沒(méi)有直接連到事實(shí)表上，而是通過(guò)其他維表連到事實(shí)表上，其圖解像多個(gè)雪花連在一起，故稱雪花模型。雪花模型是對(duì)星型模型的擴(kuò)展，原有的各維表可被擴(kuò)展為小的事實(shí)表，形成一些局部的 "層次 " 區(qū)域，被分解的表都連主維度表而不是事實(shí)表。

多學(xué)一招：什么是事實(shí)表和維度表

1.事實(shí)表

每個(gè)數(shù)據(jù)倉(cāng)庫(kù)都包含一個(gè)或者多個(gè)事實(shí)數(shù)據(jù)表，事實(shí)表是對(duì)分析主題的度量，它包含了與各維度表相關(guān)聯(lián)的外鍵，并通過(guò)連接(Join)方式與維度表關(guān)聯(lián)。

事實(shí)表的度量通常是數(shù)值類型，且記錄數(shù)會(huì)不斷增加，表規(guī)模迅速增長(zhǎng)。例如，現(xiàn)存在一張訂單事實(shí)表，其字段Prod_id(商品id)可以關(guān)聯(lián)商品維度表、TimeKey(訂單時(shí)間）可以關(guān)聯(lián)時(shí)間維度表等。

2.維度表

維度表可以看作用戶分析數(shù)據(jù)的窗口，維度表中包含事實(shí)數(shù)據(jù)表中事實(shí)記錄的特性，有些特性提供描述性信息，有些特性指定如何匯總事實(shí)數(shù)據(jù)表數(shù)據(jù)，以便為分析者提供有用的信息。

維度表包含幫助匯總數(shù)據(jù)的特性的層次結(jié)構(gòu)，維度是對(duì)數(shù)據(jù)進(jìn)行分析時(shí)特有的一個(gè)角度，站在不同角度看待問(wèn)題,會(huì)有不同的結(jié)果。例如，當(dāng)分析產(chǎn)品銷售情況時(shí)，可以選擇按照商品類別、商品區(qū)域進(jìn)行分析，此時(shí)就構(gòu)成一個(gè)類別、區(qū)域的維度。維度表信息較為固定，且數(shù)據(jù)量小，維度表中的列字段可以將信息分為不同層次的結(jié)構(gòu)級(jí)。

二、Hive簡(jiǎn)介

1. 什么是Hive

Hive是建立在Hadoop文件系統(tǒng)上的數(shù)據(jù)倉(cāng)庫(kù)，它提供了一系列工具，能夠?qū)Υ鎯?chǔ)在HDFS中的數(shù)據(jù)進(jìn)行數(shù)據(jù)提取、轉(zhuǎn)換和加載（ETL），這是一種可以存儲(chǔ)、查詢和分析存儲(chǔ)在Hadoop中的大規(guī)模數(shù)據(jù)的工具。Hive定義簡(jiǎn)單的類SQL查詢語(yǔ)言（即HQL），可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)表，允許熟悉SQL的用戶查詢數(shù)據(jù)，允許熟悉MapReduce的開(kāi)發(fā)者開(kāi)發(fā)mapper和reducer來(lái)處理復(fù)雜的分析工作，與MapReduce相比較，Hive更具有優(yōu)勢(shì)。

2. Hive的發(fā)展歷程

• 2007 年：Facebook 開(kāi)始研究 Hadoop 平臺(tái)，為了使更多人能夠使用 Hadoop 分布式文件系統(tǒng)和 MapReduce 編程模型來(lái)處理大數(shù)據(jù)，他們創(chuàng)建了一個(gè) SQL 類似的接口，用于 Hadoop 平臺(tái)的數(shù)據(jù)處理。這個(gè)接口就是 Hive。
• 2008 年：Hive 成為了 Apache Hadoop 的子項(xiàng)目，并成為 Hadoop 生態(tài)系統(tǒng)中廣泛使用的數(shù)據(jù)倉(cāng)庫(kù)工具之一。
• 2009 年：Hive 宣布支持 Amazon Elastic MapReduce 服務(wù)，并開(kāi)發(fā)了對(duì) HCatalog 的支持。Hive 0.4 版本也在這一年發(fā)布，它引入了分區(qū)表和分桶表的概念，并支持 Avro 序列化格式。
• 2010 年：Hive 0.5 版本發(fā)布，引入了 Hive Server2，支持多客戶端并發(fā)查詢，提高了 Hive 的性能和可擴(kuò)展性。Hive 還開(kāi)始支持更多的文件格式和編解碼器，如 LZO。
• 2011 年：Hive 0.7 版本發(fā)布，引入了 Hive-on-Tez，將 Hive 與 Apache Tez（一種更快的數(shù)據(jù)處理引擎）集成，提高了 Hive 的性能和可擴(kuò)展性。Hive 0.7 還引入了 Hive Metastore，使得元數(shù)據(jù)的管理更加方便和可擴(kuò)展。
• 2012 年：Hive 0.8 版本發(fā)布，引入了 Vectorized Query Execution，一種新的查詢執(zhí)行引擎，提高了 Hive 的查詢性能。Hive 0.8 還支持自定義聚合函數(shù)和 MapReduce 支持組合鍵。
• 2013 年：Hive 0.11 版本發(fā)布，引入了 Hiveserver2 的新特性，包括增強(qiáng)的安全機(jī)制、支持 Kerberos 和 LDAP 等多項(xiàng)功能。Hive 0.11 還支持語(yǔ)義完整的 ACID 事務(wù)處理，提供了一種更加可靠和可用性更高的數(shù)據(jù)倉(cāng)庫(kù)解決方案。
• 2015 年：Hive 1.2 版本發(fā)布，引入了 Hive on Spark，將 Hive 與 Apache Spark 集成，提供了更快的數(shù)據(jù)處理和更好的可擴(kuò)展性。

從 2007 年至今，Hive 的開(kāi)發(fā)和進(jìn)化歷程跟隨著 Hadoop 生態(tài)系統(tǒng)的演變，始終致力于提供高效、可擴(kuò)展、易用的數(shù)據(jù)倉(cāng)庫(kù)解決方案。

3. Hive的本質(zhì)

Hive通過(guò)HQL語(yǔ)?進(jìn)?數(shù)據(jù)查詢，本質(zhì)上是將HQL語(yǔ)句轉(zhuǎn)化為MapReduce任務(wù)。下圖展示HQL的查詢過(guò)程。

• Hive中的數(shù)據(jù)存儲(chǔ)在HDFS上
• Hive分析數(shù)據(jù)是通過(guò)MapReduce實(shí)現(xiàn)的
• Hive是運(yùn)?在Yarn上的

所以Hive是運(yùn)?在Hadoop之上的?種數(shù)據(jù)倉(cāng)庫(kù)?具。

4. Hive的優(yōu)缺點(diǎn)

4.1 優(yōu)點(diǎn)

• Hive的查詢采?類 SQL 的HQL語(yǔ)?，提供快速開(kāi)發(fā)的能?（簡(jiǎn)單、容易上?）。
• HQL可以?動(dòng)轉(zhuǎn)化成多個(gè)MapReduce任務(wù)，通過(guò)執(zhí)?MapReduce任務(wù)達(dá)到數(shù)據(jù)操作的?的。避免了開(kāi)發(fā)?員去寫 MapReduce的過(guò)程，學(xué)習(xí)成本低。
• Hive 的執(zhí)?延遲?較?，因此 Hive 常?于數(shù)據(jù)分析，對(duì)實(shí)時(shí)性要求不?的場(chǎng)合。
• Hive?分適合對(duì)數(shù)據(jù)倉(cāng)庫(kù)進(jìn)?統(tǒng)計(jì)分析。
• Hive 優(yōu)勢(shì)在于處理?數(shù)據(jù)，對(duì)于處理?數(shù)據(jù)沒(méi)有優(yōu)勢(shì)，因?yàn)?Hive 的執(zhí)?延遲?較?。
• Hive ?持?戶?定義函數(shù)，?戶可以根據(jù)??的需求來(lái)實(shí)現(xiàn)??的函數(shù)。
• Hive具有良好的可申縮性、可擴(kuò)展性、容錯(cuò)性、輸?格式的松散耦合。

4.2 缺點(diǎn)

• Hive不適合?于聯(lián)機(jī)事務(wù)處理（OLTP），也不提供實(shí)時(shí)查詢功能。對(duì)實(shí)時(shí)性要求較?的OLAP也不適?。
• Hive 的 HQL 語(yǔ)?表達(dá)能?不?
  • ?法表達(dá)迭代式算法
  • 不擅?數(shù)據(jù)挖掘?作，由于 MapReduce 數(shù)據(jù)處理流程的限制，效率更?的算法?法實(shí)現(xiàn)。
• ? Hive 的效率?較低
  • Hive ?動(dòng)?成的 MapReduce 作業(yè)不夠智能化，存在任務(wù)冗余及任務(wù)調(diào)度不合理情況。
  • Hive 調(diào)優(yōu)?較困難，粒度較粗。

5. Hive系統(tǒng)架構(gòu)

Hive是底層封裝了Hadoop的數(shù)據(jù)倉(cāng)庫(kù)處理工具，運(yùn)行在Hadoop基礎(chǔ)上，其系統(tǒng)架構(gòu)組成主要包含4部分，分別是用戶接口、跨語(yǔ)言服務(wù)、底層驅(qū)動(dòng)引擎及元數(shù)據(jù)存儲(chǔ)系統(tǒng)。

下面針對(duì)Hive系統(tǒng)架構(gòu)的組成部分進(jìn)行講解。

（1）用戶接口：主要分為3個(gè)，分別是CLI、JDBC/ODBC和Web UI。其中，CLI即Shell終端命令行，它是最常用的方式。JDBC/ODBC是Hive的Java實(shí)現(xiàn)，與使用傳統(tǒng)數(shù)據(jù)庫(kù)JDBC的方式類似，Web UI指的是通過(guò)瀏覽器訪問(wèn) Hive 。

（2）Driver

jdbc驅(qū)動(dòng)程序

（3）SQL Parser解析器

將 SQL 字符串轉(zhuǎn)換成抽象語(yǔ)法樹(shù) AST，這?步?般都?第三??具庫(kù)完成，?如antlr；對(duì) AST 進(jìn)?語(yǔ)法分析，?如表是否存在、字段是否存在、SQL 語(yǔ)義是否有誤。

（4）底層的驅(qū)動(dòng)引擎：主要包含編譯器（Compiler），優(yōu)化器（Optimizer）和執(zhí)行器（Executor），他們用于完成 HQL 查詢語(yǔ)句從詞法分析、語(yǔ)法分析、編譯、優(yōu)化以及查詢計(jì)劃的生成，生成的查詢計(jì)劃儲(chǔ)存在 HDFS 中，并在隨后由MapReduce調(diào)用執(zhí)行。

（5）元數(shù)據(jù)存儲(chǔ)系統(tǒng)（Metastore）：Hive的元數(shù)據(jù)通常包含表名、列、分區(qū)及其相關(guān)屬性，表數(shù)據(jù)所在目錄的位置信息，Metastore默認(rèn)存儲(chǔ)在自帶的Derby數(shù)據(jù)庫(kù)中。由于Derby數(shù)據(jù)庫(kù)不適合多用戶操作，并且數(shù)據(jù)存儲(chǔ)目錄不固定，不方便管理，因此，通常都將元數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)。

6. Hive工作原理

Hive建立在Hadoop系統(tǒng)之上，因此Hive底層工作依賴于Hadoop服務(wù)，Hive底層工作原理如下所示。

接下來(lái)，針對(duì)圖中的 Hive 和 Hadoop之間的工作進(jìn)程進(jìn)行簡(jiǎn)單說(shuō)明。

（1）UI 將執(zhí)行的查詢操作發(fā)送給Driver執(zhí)行。

（2）Driver 借助查詢編譯器解析查詢，檢查語(yǔ)法和查詢計(jì)劃或查詢需求。

（3）編譯器將元數(shù)據(jù)請(qǐng)求發(fā)送到 Metastore。

（4）編譯器將元數(shù)據(jù)作為對(duì)編譯器的響應(yīng)發(fā)送出去。

（5）編譯器檢查需求并將計(jì)劃重新發(fā)送給Driver。至此，查詢的解析和編譯已經(jīng)完成。

（6）Driver將執(zhí)行計(jì)劃發(fā)送給引擎執(zhí)行 Job任務(wù)。

（7）執(zhí)行引擎從DataNode上獲取結(jié)果集，并將結(jié)果發(fā)送給 UI 和 Driver。

7. Hive數(shù)據(jù)模型

Hive中所有的數(shù)據(jù)都存儲(chǔ)在HDFS中，它包含數(shù)據(jù)庫(kù)（Database）、表（Table）、分區(qū)表（Partition）和桶表（Bucket）四種數(shù)據(jù)類型。

下面針對(duì)Hive數(shù)據(jù)模型中的數(shù)據(jù)類型進(jìn)行介紹。

7.1 數(shù)據(jù)庫(kù)

相當(dāng)于關(guān)系數(shù)據(jù)庫(kù)中的命名空間(namespace)，它的作用是將用戶和數(shù)據(jù)庫(kù)的應(yīng)用，隔離到不同的數(shù)據(jù)庫(kù)或者模式中。

7.2 表

Hive的表在邏輯上由存儲(chǔ)的數(shù)據(jù)和描述表格數(shù)據(jù)形式的相關(guān)元數(shù)據(jù)組成。表存儲(chǔ)的數(shù)據(jù)存放在分布式文件系統(tǒng)里，如HDFS。Hive中的表分為兩種類型，一種叫作內(nèi)部表，這種表的數(shù)據(jù)存儲(chǔ)在 Hive數(shù)據(jù)倉(cāng)庫(kù)中；一種叫作外部表，這種表的數(shù)據(jù)可以存放在Hive 數(shù)據(jù)倉(cāng)庫(kù)外的分布式文件系統(tǒng)中，也可以存儲(chǔ)在 Hive 數(shù)據(jù)倉(cāng)庫(kù)中。值得一提的是，Hive 數(shù)據(jù)倉(cāng)庫(kù)也就是HDFS中的一個(gè)目錄，這個(gè)目錄是Hive數(shù)據(jù)存儲(chǔ)的默認(rèn)路徑，它可以在Hive的配置文件中配置，最終也會(huì)存放到元數(shù)據(jù)庫(kù)中。

7.3 分區(qū)

分區(qū)的概念是根據(jù)“分區(qū)列”的值對(duì)表的數(shù)據(jù)進(jìn)行粗略劃分的機(jī)制，在Hive存儲(chǔ)上的體現(xiàn)就是在表的主目錄（Hive的表實(shí)際顯示就是一個(gè)文件夾）下的一個(gè)子目錄，這個(gè)子目錄的名字就是定義的分區(qū)列的名字。

分區(qū)是為了加快數(shù)據(jù)查詢速度設(shè)計(jì)的，例如，現(xiàn)在有個(gè)目志文件，文件中的每條記錄都帶有時(shí)間戳。如果根據(jù)時(shí)間來(lái)分區(qū)，那么同一天的數(shù)據(jù)將會(huì)被分到同一個(gè)分區(qū)中。這樣的話，如果查詢每一天或某幾天的數(shù)據(jù)就會(huì)變得很高效，因?yàn)橹恍枰獟呙鑼?duì)應(yīng)分區(qū)中的文件即可。

注意：分區(qū)列不是表里的某個(gè)字段，而是獨(dú)立的列，根據(jù)這個(gè)列查詢存儲(chǔ)表中的數(shù)據(jù)文件。

7.4 桶表

簡(jiǎn)單來(lái)說(shuō)，桶表就是把“大表”分成了“小表”。把表或者分區(qū)組織成桶表的目的主要是為了獲得更高的查詢效率，尤其是抽樣查詢更加便捷。桶表是 Hive數(shù)據(jù)模型的最小單元，數(shù)據(jù)加載到桶表時(shí)，會(huì)對(duì)字段的值進(jìn)行哈希取值，然后除以桶個(gè)數(shù)得到余數(shù)進(jìn)行分桶，保證每個(gè)桶中都有數(shù)據(jù)，在物理上，每個(gè)桶表就是表或分區(qū)的一個(gè)文件。

8. Hive與數(shù)據(jù)庫(kù)的?較

Hive雖然采?了類似SQL的查詢語(yǔ)?HQL（Hive Query Language）,但除了查詢語(yǔ)?相似之外，不要把Hive理解成是?種數(shù)據(jù)庫(kù)。

MySQL與Hive對(duì)比如下所示：

數(shù)據(jù)庫(kù)主要應(yīng)?于在線事務(wù)處理（OLTP）和在線分析處理（OLAP），強(qiáng)調(diào)的是事務(wù)的時(shí)效性與可靠性。?Ｈive是?種數(shù)據(jù)倉(cāng)庫(kù)技術(shù)，主要?應(yīng)于對(duì)時(shí)效性要求不?的批量數(shù)據(jù)統(tǒng)計(jì)分析，它強(qiáng)調(diào)的是數(shù)據(jù)處理的吞吐率。

下?介紹兩者之間的主要差別：

8.1 數(shù)據(jù)規(guī)模??

? Hive集群采?的是分布式計(jì)算技術(shù)，天然?持并?計(jì)算，具有很好的申縮性、可擴(kuò)展性、安全性。因此可以?持很?規(guī)模的數(shù)據(jù)。
? 數(shù)據(jù)庫(kù)集群?般采?的是分庫(kù)分表的技術(shù)，?持縱向擴(kuò)展，但難以進(jìn)?橫向擴(kuò)展，集群規(guī)模較?，所以數(shù)據(jù)庫(kù)可以?持的數(shù)據(jù)規(guī)模較?，申縮性、可擴(kuò)展性不好。

8.2 查詢語(yǔ)???

? SQL被?泛的應(yīng)?于數(shù)據(jù)庫(kù)技術(shù)中，有著?泛的?戶群體，為了降低初學(xué)者的學(xué)習(xí)成本。因此，把Hive的查詢語(yǔ)?HQL設(shè)計(jì)成了類 SQL 的查詢語(yǔ)?。熟悉 SQL 的開(kāi)發(fā)者可以很?便地使? Hive。

8.3 數(shù)據(jù)更新??

? Hive數(shù)據(jù)倉(cāng)庫(kù)具有讀多寫少的特點(diǎn)。因此，Hive不建議對(duì)數(shù)據(jù)進(jìn)?改寫，所有的數(shù)據(jù)都是在加載的時(shí)候確定好的。原因是Hive是建?在Hadoop基礎(chǔ)上的，?HDFS是只?持追加數(shù)據(jù)不?持修改數(shù)據(jù)。
? 數(shù)據(jù)庫(kù)中的數(shù)據(jù)要保證能夠隨時(shí)查詢、新增、修改和刪除。

8.4 執(zhí)?延時(shí)??

Hive執(zhí)?延時(shí)?主要有兩個(gè)原因：
（1）查詢?般不使?索引，需要掃描整個(gè)表
（2）采? MapReduce 框架。由于 MapReduce 本身具有較?的延遲，因此Hive也有較?的延遲。

數(shù)據(jù)庫(kù)的執(zhí)?延遲較低是有條件的，即數(shù)據(jù)規(guī)模較?，當(dāng)數(shù)據(jù)規(guī)模?到超過(guò)數(shù)據(jù)庫(kù)的處理能?的時(shí)候，Hive 的并?計(jì)算就能體現(xiàn)出優(yōu)勢(shì)。

8.5 應(yīng)?場(chǎng)景??

Hive主要應(yīng)?于時(shí)實(shí)性要求不?的?規(guī)模數(shù)據(jù)的統(tǒng)計(jì)分析；數(shù)據(jù)庫(kù)主要應(yīng)?于數(shù)據(jù)規(guī)模較?、實(shí)時(shí)性要求較?的在線事務(wù)處理（OLTP）和在線分析處理（OLAP）。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-605995.html

8.4 執(zhí)?延時(shí)??

Hive執(zhí)?延時(shí)?主要有兩個(gè)原因：
（1）查詢?般不使?索引，需要掃描整個(gè)表
（2）采? MapReduce 框架。由于 MapReduce 本身具有較?的延遲，因此Hive也有較?的延遲。

數(shù)據(jù)庫(kù)的執(zhí)?延遲較低是有條件的，即數(shù)據(jù)規(guī)模較?，當(dāng)數(shù)據(jù)規(guī)模?到超過(guò)數(shù)據(jù)庫(kù)的處理能?的時(shí)候，Hive 的并?計(jì)算就能體現(xiàn)出優(yōu)勢(shì)。

8.5 應(yīng)?場(chǎng)景??

Hive主要應(yīng)?于時(shí)實(shí)性要求不?的?規(guī)模數(shù)據(jù)的統(tǒng)計(jì)分析；數(shù)據(jù)庫(kù)主要應(yīng)?于數(shù)據(jù)規(guī)模較?、實(shí)時(shí)性要求較?的在線事務(wù)處理（OLTP）和在線分析處理（OLAP）。

到了這里，關(guān)于Hive數(shù)據(jù)倉(cāng)庫(kù)簡(jiǎn)介的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！