用hive來做數倉類操作,或者大資料的運算,是沒有疑問的,至少在你沒有更多選擇之前。
當我們要hive來做類似於大批量資料的select時,也許問題就會發生了變化。
1. 通用解決方案之分頁
首先,我們要基於一個事實,就是沒有哪個資料庫可以無限制的提供我們select任意資料量的資料。比如常用的 mysql, oracle, 一般你select 10w左右的資料量時已經非常厲害了。而我們的解決方法也比較簡單,那就是分頁獲取,比如我一頁取1w條,直到取完為止。同樣,因為hive基於都支援sql92協議,所以你也可以同樣的方案去解決大資料量的問題。
分頁的解決方案會有什麼問題?首先,我們要明白分頁是如何完成的,首先資料庫server會根據條件運算出所有或部分符合條件的資料(取決是否有額外的排序),然後再根據分頁偏移資訊,獲取相應的資料。所以,一次次的分頁,則必定涉及到一次次的資料運算。這在小資料量的情況下是可以接受的,因為計算機的高速運轉能力。但是當資料量大到一定程式時,就不行了。比如我們停滯了許多年的大資料領域解決方案就是很好的證明。
本文基於hive處理資料,也就是說資料量自然也是大到了一定的級別,那麼用分頁也許就不好解決問題了。比如,單次地運算也許就是3-5分鐘(基於分散式平行計算系統能力),當你要select 100w資料時,如果用一頁1w的運算,那麼就是100次來回,1次3-5分鐘,100次就是5-8小時的時間,這就完全jj了。誰能等這麼長時間?這樣處理的最終結果就是,業務被砍掉,等著財務結賬了。
所以,我們得改變點什麼!
2. 使用hive-jdbc
jdbc本身不算啥,只是一個連線協議。但它的好處在於,可以維持長連線。這個連線有個好處,就是server可以隨時輸出資料,而client端則可以隨時處理資料。這就給了我們一個機會,即比如100w的資料運算好之後,server只需源源不斷的輸出結果,而client端則源源不斷地接收處理資料。
所以,我們解決方案是,基於hive-jdbc, 不使用分頁,而全量獲取資料即可。這給我們帶來莫大的好處,即一次運算即可。比如1次運算3-5分鐘,那麼總共的運算也就是3-5分鐘。
看起來不錯,解決了重複運算的問題。好似萬事大吉了。
具體實現就是引入幾個hive-jdbc的依賴,然後提交查詢,依次獲取結果即可。樣例如下:
<!-- pom 依賴 --> <!-- https://mvnrepository.com/artifact/org.apache.hive/hive-jdbc --> <dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-jdbc</artifactId> <version>2.3.4</version> </dependency>
--
// 測試hive-jdbc import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.sql.DriverManager; public class HiveJdbcTest { private static Connection conn = getConnnection(); private static PreparedStatement ps; private static ResultSet rs; // 獲取所有資料 public static void getAll(String tablename) { String sql="select * from " + tablename; System.out.println(sql); try { ps = prepare(conn, sql); rs = ps.executeQuery(); int columns = rs.getMetaData().getColumnCount(); while(rs.next()) { for(int i=1;i<=columns;i++) { System.out.print(rs.getString(i)); System.out.print("\t\t"); } System.out.println(); } } catch (SQLException e) { e.printStackTrace(); } } // 測試 public static void main(String[] args) { String tablename="t1"; HiveJdbcTest.getAll(tablename); } private static String driverName = "org.apache.hive.jdbc.HiveDriver"; private static String url = "jdbc:hive2://127.0.0.1:10000/"; private static Connection conn; // 連線hive庫 public static Connection getConnnection() { try { Class.forName(driverName); conn = DriverManager.getConnection(url, "hive", "123"); } catch(ClassNotFoundException e) { e.printStackTrace(); } catch (SQLException e) { e.printStackTrace(); } return conn; } public static PreparedStatement prepare(Connection conn, String sql) { PreparedStatement ps = null; try { ps = conn.prepareStatement(sql); } catch (SQLException e) { e.printStackTrace(); } return ps; } }
樣例程式碼,無需糾結。簡單的jdbc操作樣板。總體來說就是,不帶分頁的接收全量資料。
但是,這個會有什麼問題?同樣,小資料量時無任何疑問,但當資料量足夠大時,每一次的資料接收,都需要一次網路通訊請示,且都是單執行緒的。我們假設接受一條資料花費1ms, 那麼接收1000條數就是1s, 6k條資料就是1min。36w條資料就是1h, 額,後面就無需再算了。同樣是不可估量的時間消耗。(實際情況也許會好點,因為會有buffer緩衝的存在)
為什麼會這樣呢?運算量已經減小了,但是這網路通訊量,我們又能如何?實際上,問題不在於網路通訊問題,而在於我們使用這種方式,使我們從平行計算轉到了序列計算的過程了。因為只有單點的資料接收,所以只能將資料彙集處理。從而就是一個序列化的東西了。
所以,我們更多應該從並行這一層面去解決問題。
3. 基於臨時表實現
要解決並行變序列的問題,最根本的辦法就是避免一條條讀取資料。而要避免這個問題,一個很好想到的辦法就是使用臨時表,繞開自己程式碼的限制。讓大資料叢集自行處理平行計算問題,這是個不錯的想法。
但具體如何做呢?我們面臨至少這麼幾個問題:
1. 如何將資料寫入臨時表?
2. 寫入臨時表的資料如何取回?是否存在瓶頸問題?
3. 臨時表後續如何處理?
我們一個個問題來,第1個,如何寫臨時表問題:我們可以選擇先建立一個臨時表,然後再使用insert into select ... from ... 的方式寫入,但這種方式非常費力,首先你得固化下臨時表的資料結構,其次你要處理多次寫入問題。看起來不是最好的辦法。幸好,hive中或者相關資料庫產品都提供了另一種更方便的建臨時表的方法: create table xxx as select ... from ... 你只需要使用一個語句就可以將結果寫入到臨時表了。但需要注意的是,我們建立時,需要指定好我們需要的格式,否則最終結果也許不是我們想要的,比如我們需要使用','分隔資料而非tab, 我們需要使用 text 形式的資料,而非壓縮的二進位制格式。
以下是個使用樣例:
-- 外部使用 create table 包裹 CREATE TABLE tmp_2020110145409001 ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE as -- 具體的業務select sql select t1.*, t2.* from test t1 left join test2 t2 on t1.id = t2.t_id ;
如此,我們就得到所需的結果了。以上結果,在hive中表現為一個臨時表。而其背後則是一個個切分的檔案,以','號分隔的文字檔案,且會按照hive的預設儲存目錄存放。(更多具體語法請查詢官網資料)
接下來,我們要解決第2個問題:如何將資料取回?這個問題也不難,首先,現在結果已經有了,我們可以一行行地讀取返回,就像前面一樣。但這時已經沒有了資料運算,應該會好很多。但明顯還是不夠好,我們仍然需要反覆的網路通訊。我們知道,hive儲存的背後,是一個個切分的檔案,如果我們能夠將該檔案直接下載下來,那將會是非常棒的事。不錯,最好的辦法就是,直接下載hive的資料檔案,hive會儲存目錄下,以類似於 part_0000, part_0001... 之類的檔案存放。
那麼,我們如何才能下載到這些檔案呢?hive是基於hadoop的,所以,很明顯我們要回到這個問題,基於hadoop去獲取這些檔案。即 hdfs 獲取,命令如下:
// 檢視所有分片資料檔案列表 hdfs dfs -ls hdfs://xx/hive/mydb.db/* // 下載所有資料檔案到 /tmp/local_hdfs 目錄 hdfs dfs -get hdfs://xx/hive/mydb.db/* /tmp/local_hdfs
我們可以通過以上命令,將資料檔案下載到本地,也可以hdfs的jar包,使用 hdfs-client 進行下載。優缺點是:使用cli的方式簡單穩定但依賴於伺服器環境,而使用jar包的方式則部署方便但需要自己寫更多程式碼保證穩定性。各自選擇即可。
最後,我們還剩下1個問題:如何處理臨時表的問題?hive目前尚不支援設定表的生命週期(阿里雲的maxcompute則只是一個 lifecycle 選項的問題),所以,需要自行清理檔案。這個問題的實現方式很多,比如你可以自行記錄這些臨時表的建立時間、位置、過期時間,然後再每天執行指令碼清理表即可。再簡單點就是你可以直接通過表名進行清理,比如你以年月日作為命令開頭,那麼你可以根據這日期刪除臨時表即可。如:
-- 列舉表名 show tables like 'dbname.tmp_20201101*'; -- 刪除具體表名 drop table dbname.tmp_2020110100001 ;
至此,我們的所有問題已解決。總結下:首先使用臨時表並行地將結果寫入;其次通過hdfs將檔案快速下載到本地即可;最後需要定時清理臨時表;這樣,你就可以高效,無限制的為使用者拉取大批量資料了。
不過需要注意的是,我們的步驟從1個步驟變成了3個步驟,增加了複雜度。(實際上你可能還會處理更多的問題,比如後設資料資訊的對應問題)複雜度增加的最大問題就在於,它會帶來更多的問題,所以我們一定要善於處理好這些問題,否則將會帶來一副作用。