Hive使用者都有的一個共識，即Update真不是Hive的菜（笑）
至于原因呢，就是Hive默認底層使用hadoop存儲，而HDFS不支持修改文件，這是無法繞過的一個天塹。

A Hive的行級Update

來源
參考

官方資料:
    Update資料  <=>      https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DML
    Join資料    <=>      https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Joins
網(wǎng)上參考資料:
    Update資料  <=>      http://www.aboutyun.com/thread-12155-1-1.html

為Hive配置Update功能

1.編輯hive-site.xml文件:

<property>
    <name>hive.optimize.sort.dynamic.partition</name>
    <value>false</value>
</property>
<property>
    <name>hive.support.concurrency</name>
    <value>true</value>
</property>
<property>
    <name>hive.enforce.bucketing</name>
    <value>true</value>
</property>
<property>
    <name>hive.exec.dynamic.partition.mode</name>
    <value>nonstrict</value>
</property>
<property>
    <name>hive.txn.manager</name>
    <value>org.apache.hadoop.hive.ql.lockmgr.DbTxnManager</value>
</property>
<property>
    <name>hive.compactor.initiator.on</name>
    <value>true</value>
</property>
<property>
    <name>hive.compactor.worker.threads</name>
    <value>1</value>
</property>
<property>
    <name>hive.in.test</name>
    <value>true</value>
</property>

二.Update語法

1.創(chuàng)表語句
Hive對使用Update功能的表有特定的語法要求, 語法要求如下:

要執(zhí)行Update的表中, 建表時必須帶有buckets(分桶)屬性
要執(zhí)行Update的表中, 需要指定格式,其余格式目前贊不支持, 如:parquet格式, 目前只支持ORCFileformat和AcidOutputFormat
要執(zhí)行Update的表中, 建表時必須指定參數(shù)('transactional' = true);
eg:

create table student (id bigint,name string) clustered by (name) into 2 buckets stored as orc TBLPROPERTIES('transactional'='true');

B 拉鏈表

來源

一.什么是拉鏈表

拉鏈表是針對數(shù)據(jù)倉庫設計中表存儲數(shù)據(jù)的方式而定義的，顧名思義，所謂拉鏈，就是記錄歷史。記錄一個事物從開始，一直到當前狀態(tài)的所有變化的信息。

我們先看一個示例，這就是一張拉鏈表，存儲的是用戶的最基本信息以及每條記錄的生命周期。我們可以使用這張表拿到最新的當天的最新數(shù)據(jù)以及之前的歷史數(shù)據(jù)。

示例.png

我們暫且不對這張表做細致的講解，后文會專門來闡述怎么來設計、實現(xiàn)和使用它。

1.1 拉鏈表的使用場景

在數(shù)據(jù)倉庫的數(shù)據(jù)模型設計過程中，經(jīng)常會遇到下面這種表的設計：

1. 有一些表的數(shù)據(jù)量很大，比如一張用戶表，大約10億條記錄，50個字段，這種表，即使使用ORC壓縮，單張表的存儲也會超過100G，在HDFS使用雙備份或者三備份的話就更大一些。

2. 表中的部分字段會被update更新操作，如用戶聯(lián)系方式，產(chǎn)品的描述信息，訂單的狀態(tài)等等。

3. 需要查看某一個時間點或者時間段的歷史快照信息，比如，查看某一個訂單在歷史某一個時間點的狀態(tài)。

4. 表中的記錄變化的比例和頻率不是很大，比如，總共有10億的用戶，每天新增和發(fā)生變化的有200萬左右，變化的比例占的很小。

那么對于這種表該如何設計呢?下面有幾種方案可選：

方案一：每天只留最新的一份，比如我們每天用Sqoop抽取最新的一份全量數(shù)據(jù)到Hive中。

方案二：每天保留一份全量的切片數(shù)據(jù)。

方案三：使用拉鏈表。

1.2 為什么使用拉鏈表

現(xiàn)在我們對前面提到的三種進行逐個的分析。

方案一

這種方案就不用多說了，實現(xiàn)起來很簡單，每天drop掉前一天的數(shù)據(jù)，重新抽一份最新的。

優(yōu)點很明顯，節(jié)省空間，一些普通的使用也很方便，不用在選擇表的時候加一個時間分區(qū)什么的。

缺點同樣明顯，沒有歷史數(shù)據(jù)，先翻翻舊賬只能通過其它方式，比如從流水表里面抽。

方案二

每天一份全量的切片是一種比較穩(wěn)妥的方案，而且歷史數(shù)據(jù)也在。

缺點就是存儲空間占用量太大太大了，如果對這邊表每天都保留一份全量，那么每次全量中會保存很多不變的信息，對存儲是極大的浪費。

當然我們也可以做一些取舍，比如只保留近一個月的數(shù)據(jù)。但是，需求是無恥的，數(shù)據(jù)的生命周期不是我們能完全左右的。

方案三

拉鏈表在使用上基本兼顧了我們的需求。

首先它在空間上做了一個取舍，雖說不像方案一那樣占用量那么小，但是它每日的增量可能只有方案二的千分之一甚至是萬分之一。

其實它能滿足方案二所能滿足的需求，既能獲取最新的數(shù)據(jù)，也能添加篩選條件也獲取歷史的數(shù)據(jù)。

所以我們還是很有必要來使用拉鏈表的。

二、拉鏈表的設計和實現(xiàn)

下面我們來舉個例子詳細看一下拉鏈表。

我們先看一下在Mysql關系型數(shù)據(jù)庫里的user表中信息變化。

在2017-01-01這一天表中的數(shù)據(jù)是：

2017-01-01數(shù)據(jù).png

在2017-01-02這一天表中的數(shù)據(jù)是， 用戶002和004資料進行了修改，005是新增用戶：

2017-01-02修改數(shù)據(jù).png

拉鏈表數(shù)據(jù).png

說明

• t_start_date表示該條記錄的生命周期開始時間，t_end_date表示該條記錄的生命周期結(jié)束時間。

• t_end_date = ‘9999-12-31’表示該條記錄目前處于有效狀態(tài)。

• 如果查詢當前所有有效的記錄，則select * from user where t_end_date = ‘9999-12-31’。

• 如果查詢2017-01-02的歷史快照，則select * from user where t_start_date <=
  ‘2017-01-02’ and t_end_date >= ‘2017-01-02’。(此處要好好理解，是拉鏈表比較重要的一塊。)

三、在Hive中實現(xiàn)拉鏈表

在現(xiàn)在的大數(shù)據(jù)場景下，大部分的公司都會選擇以Hdfs和Hive為主的數(shù)據(jù)倉庫架構。目前的Hdfs版本來講，其文件系統(tǒng)中的文件是不能做改變的，也就是說Hive的表只能進行刪除和添加操作，而不能進行update。基于這個前提，我們來實現(xiàn)拉鏈表。

還是以上面的用戶表為例，我們要實現(xiàn)用戶的拉鏈表。在實現(xiàn)它之前，我們需要先確定一下我們有哪些數(shù)據(jù)源可以用。

1. 我們需要一張用戶全量表。至少需要用它來初始化。

2. 每日的用戶更新表。

而且我們要確定拉鏈表的時間粒度，比如說拉鏈表每天只取一個狀態(tài)，也就是說如果一天有3個狀態(tài)變更，我們只取最后一個狀態(tài)，這種天粒度的表其實已經(jīng)能解決大部分的問題了。

另外，補充一下每日的用戶更新表該怎么獲取，有3種方式拿到或者間接拿到每日的用戶增量，因為它比較重要，所以詳細說明：

1. 我們可以監(jiān)聽Mysql數(shù)據(jù)的變化，比如說用Canal，最后合并每日的變化，獲取到最后的一個狀態(tài)。

2. 假設我們每天都會獲得一份切片數(shù)據(jù)，我們可以通過取兩天切片數(shù)據(jù)的不同來作為每日更新表，這種情況下我們可以對所有的字段先進行concat，再取md5，這樣就ok了。

3. 可以使用每日的變更流水表。

3.1 創(chuàng)建表結(jié)構

現(xiàn)在我們來看一下我們用戶資料切片表的結(jié)構：

CREATE EXTERNAL TABLE ods.user ( 
  user_num STRING COMMENT '用戶編號', 
  mobile STRING COMMENT '手機號碼', 
  reg_date STRING COMMENT '注冊日期' 
COMMENT '用戶資料表' 
PARTITIONED BY (dt string) 
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n' 
STORED AS ORC 
LOCATION '/ods/user'; 
) 

然后我們還需要一張用戶每日更新表，前面已經(jīng)分析過該如果得到這張表，現(xiàn)在我們假設它已經(jīng)存在。

CREATE EXTERNAL TABLE ods.user_update ( 
  user_num STRING COMMENT '用戶編號', 
  mobile STRING COMMENT '手機號碼', 
  reg_date STRING COMMENT '注冊日期' 
COMMENT '每日用戶資料更新表' 
PARTITIONED BY (dt string) 
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n' 
STORED AS ORC 
LOCATION '/ods/user_update'; 
) 

現(xiàn)在我們創(chuàng)建一張拉鏈表，這張就是我們最后希望的表。

CREATE EXTERNAL TABLE dws.user_his ( 
  user_num STRING COMMENT '用戶編號', 
  mobile STRING COMMENT '手機號碼', 
  reg_date STRING COMMENT '用戶編號', 
  t_start_date , 
  t_end_date 
COMMENT '用戶資料拉鏈表' 
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n' 
STORED AS ORC 
LOCATION '/dws/user_his'; 
)

3.2 實現(xiàn)sql語句

首先全量更新，我們先到2017-01-01為止的數(shù)據(jù)。

初始化，先把2017-01-01的數(shù)據(jù)初始化進去。這個比較簡單，可以參看博客。

我們這里重點說下怎么樣更新拉鏈表。

現(xiàn)在我們假設我們已經(jīng)初始化了2017-01-01的日期，然后需要更新2017-01-02那一天的數(shù)據(jù)，我們有了下面的Sql。

然后把兩個日期設置為變量就可以了。

INSERT OVERWRITE TABLE dws.user_his 
SELECT * FROM 
( 
    SELECT A.user_num, 
           A.mobile, 
           A.reg_date, 
           A.t_start_time, 
           CASE 
                WHEN A.t_end_time = '9999-12-31' AND B.user_num IS NOT NULL THEN '2017-01-01' 
                ELSE A.t_end_time 
           END AS t_end_time 
    FROM dws.user_his AS A 
    LEFT JOIN ods.user_update AS B 
    ON A.user_num = B.user_num 
UNION 
    SELECT C.user_num, 
           C.mobile, 
           C.reg_date, 
           '2017-01-02' AS t_start_time, 
           '9999-12-31' AS t_end_time 
    FROM ods.user_update AS C 
) AS T 

我在這里解釋一下上述代碼的含義。結(jié)合圖1，圖2和圖4來理解：

• UNION下面代碼的含義就是新增數(shù)據(jù)的插入，即圖2的005.

• UNION上面代碼的含義有2點需要注意： 第一，是左連接，更新表B表里有用戶資料表A用戶編號的數(shù)據(jù)完全接入；是對A表進行更新的。 第二，CASE WHEN這里，如果用戶資料表A里的用戶在1月2號的更新表B里（即1月2號對該用戶進行了更新），該用戶為有效記錄且B表的用戶編號不為空，那么說明A表的該數(shù)據(jù)應該設為歷史數(shù)據(jù)，設定其t_end_time為1月1日；否則，說明沒有對該用戶進行更新，保持原來的t_end_time不變。

四、總結(jié)

我們分析了拉鏈表的原理、設計思路、并且在Hive環(huán)境下實現(xiàn)了一份拉鏈表，下面對拉鏈表做一些小的補充。

4.1 拉鏈表和流水表

流水表存放的是一個用戶的變更記錄，比如在一張流水表中，一天的數(shù)據(jù)中，會存放一個用戶的每條修改記錄，但是在拉鏈表中只有一條記錄。

這是拉鏈表設計時需要注意的一個粒度問題。我們當然也可以設置的粒度更小一些，一般按天就足夠。

4.2 查詢性能

拉鏈表當然也會遇到查詢性能的問題，比如說我們存放了5年的拉鏈數(shù)據(jù)，那么這張表勢必會比較大，當查詢的時候性能就比較低了，個人認為兩個思路來解決：

• 在一些查詢引擎中，我們對start_date和end_date做索引，這樣能提高不少性能。

• 保留部分歷史數(shù)據(jù)，比如說我們一張表里面存放全量的拉鏈表數(shù)據(jù)，然后再對外暴露一張只提供近3個月數(shù)據(jù)的拉鏈表。

4.3 心得

使用拉鏈表的時候可以不加t_end_date，即失效日期，但是加上之后，能優(yōu)化很多查詢。

可以加上當前行狀態(tài)標識，能快速定位到當前狀態(tài)。

在拉鏈表的設計中可以加一些內(nèi)容，因為我們每天保存一個狀態(tài)，如果我們在這個狀態(tài)里面加一個字段，比如如當天修改次數(shù)，那么拉鏈表的作用就會更大。

參考文獻

漫談數(shù)據(jù)倉庫之拉鏈表（原理、設計以及在Hive中的實現(xiàn)）

C SQL改寫

然而，今天一位前輩教會我，不能以貌識人，既然不讓本地修改，那么把數(shù)據(jù)讀出來，改完之后再寫到新表里頭，不也就另一種的實現(xiàn)Update了么（計劃通:）。

INSERT OVERWRITE TABLE t_court_info
SELECT
  REGIONID,
  DISTRICTID,
  B.court_id,
  COURT_TYPE,
  COURT_NAME,
  GRID_NAME,
  GRID_ID,
  LONGITUDE,
  LATITUDE,
  AVG_PRICE,
  B.BUILDING_COUNT,
  B.room_count,
  FAMILY_COUNT,
  PROPERTY_COMPANY,
  DEVELOPER,
  CONTACT,
  PROPERTY_FEE,
  PLOT_RATIO,
  GREEN_SPACE,
  PARK,
  STATUS,
  COMMENTS,
  GRID_TYPE,
  COURT_ADDRESS,
  EDITDATE,
  AREA_ID,
  AREA_NAME,
  OBU_ID,
  OBU_NAME,
  B.block_id,
  BLOCK_NAME,
  YX_GRID_ID,
  YX_GRID_NAME,
  IF_CLEAN,
  CONTACT_TEL,
  YD_WLAN_COUNT,
  LT_WLAN_COUNT,
  GD_WLAN_COUNT,
  QT_WLAN_COUNT,
  YD_ACCESS,
  LT_ACCESS,
  GD_ACCESS,
  QT_ACCESS,
  STATE,
  CREATE_PERSON,
  REGION_NAME,
  COMPTT_STTID,
  COMPTT_STT,
  BLOCK_TYPE_1NAME,
  BLOCK_TYPE_2NAME,
  BLOCK_TYPE_3NAME,
  IF_MATURE_COURT,
  STATUS_INFO,
  DX_WLAN_COUNT,
  DX_ACCESS
FROM
  t_court_info a
  JOIN
    (SELECT
      t1.block_id,
      t1.court_id,
      SUM(t1.user_cnt) room_count,
      COUNT(DISTINCT t1.building_id) building_count
    FROM
      tb_sand_building_info t1
    GROUP BY t1.block_id,
      t1.court_id) b
    ON a.block_id = b.block_id
    AND a.court_eid = b.court_id
UNION
ALL
SELECT
  REGIONID,
  DISTRICTID,
  COURT_EID,
  COURT_TYPE,
  COURT_NAME,
  GRID_NAME,
  GRID_ID,
  LONGITUDE,
  LATITUDE,
  AVG_PRICE,
  BUILDING_COUNT,
  ROOM_COUNT,
  FAMILY_COUNT,
  PROPERTY_COMPANY,
  DEVELOPER,
  CONTACT,
  PROPERTY_FEE,
  PLOT_RATIO,
  GREEN_SPACE,
  PARK,
  STATUS,
  COMMENTS,
  GRID_TYPE,
  COURT_ADDRESS,
  EDITDATE,
  AREA_ID,
  AREA_NAME,
  OBU_ID,
  OBU_NAME,
  BLOCK_ID,
  BLOCK_NAME,
  YX_GRID_ID,
  YX_GRID_NAME,
  IF_CLEAN,
  CONTACT_TEL,
  YD_WLAN_COUNT,
  LT_WLAN_COUNT,
  GD_WLAN_COUNT,
  QT_WLAN_COUNT,
  YD_ACCESS,
  LT_ACCESS,
  GD_ACCESS,
  QT_ACCESS,
  STATE,
  CREATE_PERSON,
  REGION_NAME,
  COMPTT_STTID,
  COMPTT_STT,
  BLOCK_TYPE_1NAME,
  BLOCK_TYPE_2NAME,
  BLOCK_TYPE_3NAME,
  IF_MATURE_COURT,
  STATUS_INFO,
  DX_WLAN_COUNT,
  DX_ACCESS
FROM
  t_court_info a
WHERE NOT EXISTS
  (SELECT
    1
  FROM
    (SELECT
      t1.block_id,
      t1.court_id
    FROM
      tb_sand_building_info t1
    GROUP BY t1.block_id,
      t1.court_id) b
  WHERE a.block_id = b.block_id
    AND a.court_eid = b.court_id)