[發(fā)明專利]一種hive文件合并的方法和裝置

有效

• 申請?zhí)枺?/td>: 202010725466.3
• 申請日: 2020-07-24
• 公開（公告）號: CN112035057B
• 公開（公告）日: 2022-06-21
• 發(fā)明（設計）人: 梅綱;高東升;馮源;胡書能;陳琦
• 申請（專利權）人: 武漢達夢數據庫股份有限公司
• 主分類號: G06F3/06
• 分類號: G06F3/06;G06F16/17
• 代理公司: 深圳市六加知識產權代理有限公司 44372
• 代理人: 向彬

本發(fā)明涉及數據倉庫領域，特別是涉及一種hive文件合并的方法和裝置。主要包括：獲取一個hive表的元數據定義的目錄下的所有文件作為需合并的文件；按照需合并的文件的總容量大小和預設的大文件最大容量估算合并文件時需要的桶的數量；根據估算所得的桶的數量建立相應數量的桶；將需合并的文件按照每個文件的容量從大到小依次放入空閑容量最大的桶中，直至所有文件都放入桶中；將放入每個桶內的文件分別合并為一個大文件。本發(fā)明可以合理分配待合并的小文件合并成一個大文件，過濾無意義的合并，同時減少額外產生的小文件數量，并且通過并行合并的方式提高合并效率。

【技術領域】

本發(fā)明涉及數據倉庫領域，特別是涉及一種hive文件合并的方法和裝置。

【背景技術】

Hive是基于Hadoop架構的一個數據倉庫工具，實際生產環(huán)境中，每個 hive表下存在很多文件，并且可能存在大量的小文件。在Hadoop中，文件按照固定塊大小進行存儲，小于一個默認塊大小的文件也占據一個塊的存儲空間，當小文件數量較多時，會占用較多額外的存儲空間。另一方面，Hadoop處理大量小文件速度遠遠小于處理同等大小的大文件的速度，小文件較多時會嚴重影響處理性能。因此，需要將大量小文件合并為少量大文件進行處理。

目前，Hadoop架構下一般使用CombineFileInputFormat進行小文件合并。但是這種合并方法可能會進行一些不必要的合并，并且合并后可能產生更小的文件。另一方面，這種合并方法一次僅能合并一個hive分區(qū)表的一個分區(qū)內的文件，必須啟動多個map reduce對分區(qū)表內各個分區(qū)的文件同時合并，導致合并效率較低。

鑒于此，如何克服該現有技術所存在的缺陷，解決現有hive小文件合并方法導致的可能產生不必要的合并，以及合并效率較低的問題，是本技術領域待解決的問題。

【發(fā)明內容】

針對現有技術的以上缺陷或改進需求，本發(fā)明解決了現有hive小文件合并時無法合理分配待合并的小文件，以及多個分區(qū)同時進行合并的效率問題。

本發(fā)明實施例采用如下技術方案:

第一方面，本發(fā)明提供了一種hive文件合并的方法，具體為：獲取一個hive表的元數據定義的目錄下的所有文件作為需合并的文件；按照需合并的文件的總容量大小和預設的大文件最大容量估算合并文件時需要的桶的數量；根據估算所得的桶的數量建立相應數量的桶；將需合并的文件按照每個文件的容量從大到小依次放入空閑容量最大的桶中，直至所有文件都放入桶中；將放入每個桶內的文件分別合并為一個大文件。

優(yōu)選的，將需合并的文件按照每個文件的容量從大到小依次放入空閑容量最大的桶中，具體包括：將需合并的文件按照每個文件的容量從大到小排序，放入文件列表中；將桶按照空閑容量的大小從大到小排序，放入桶列表中；取出桶列表中的第一個桶，取出文件列表中的第一個文件，將取出的文件放入取出的桶中；計算取出的桶的空閑容量，根據空閑容量把取出的桶插入桶列表中合適的排序位置，保持桶列表中的桶按照空閑容量的大小從大到小排序。

優(yōu)選的，根據空閑容量把取出的桶插入桶列表中合適的排序位置，具體包括：按照桶列表的順序，將取出的桶的空閑容量依次和桶列表中每個桶的空閑容量比較；查找桶列表中最后一個空閑容量大于取出的桶的空閑容量的桶，將取出的桶插入查找到的桶之后。

優(yōu)選的，估算合并文件時需要的桶的數量具體包括：獲取需合并的文件的總容量大小；根據需合并的文件的總容量大小和預設的大文件最大容量估算合并后的大文件的數量，合并文件時需要的桶的數量與合并后的大文件的數量相同。

優(yōu)選的，預設的大文件最大容量大于一個系統(tǒng)數據塊的容量。

優(yōu)選的，將放入每個桶內的文件分別合并為一個大文件，具體包括：以map reducejob方式提交桶列表中所有的桶到Hadoop下進行文件合并，每個reduce任務中進行至少一個桶內的文件的合并。