用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個步驟，增加了複雜度。（實際上你可能還會處理更多的問題，比如元資料資訊的對應問題）複雜度增加的最大問題就在於，它會帶來更多的問題，所以我們一定要善於處理好這些問題，否則將會帶來一副作用。