Hadoop中的分区管理

x33g5p2x  于2020-12-11 发布在 Hadoop  
字(5.0k)|赞(0)|评价(0)|浏览(1048)

在这篇文章中,我将谈谈Hive表有很多小分区和文件的问题,并详细介绍我的解决方案。

背景

在我的项目中,我们将很多数据保存在HDFS中。其中大部分是原始数据,但也有相当一部分是许多数据加工后的最终产物。为了方便管理所有的数据流水线,所有Hive表的默认分区方式是小时DateTime分区(例如:dt='2019041316')。

对于在HDFS中保存这么多分区文件,这是一种不好的做法。假设这些表必须存储在HDFS中--我们需要面对一些关于存储管理的课题,也就是我们所说的"分区管理"。

多小文件问题

我在之前的几篇文章中写过,Hadoop的一个主要问题就是 "多小文件"问题。当我们有一个数据进程,每隔一个小时就会给某个表增加一个新的分区,并且它已经运行了2年以上,我们需要开始处理这个表。2年时间里有243652(17520)个小时,所以我们会有一个近2万个分区的表。而我要说明的是,我们在这里讨论的体积是每小时1MB左右。现在想象一下,有500张这样的表。

我不知道你们有没有人试过为了读取20GB的数据而扫描20000个分区(即文件),开销是巨大的。不管是什么技术。Spark,Hive,MapReduce,Impala,Presto--当有太多的小分区时,它们的性能都非常糟糕。现在想象一下,每天有上千次查询,每张表扫描上千个分区。

HDFS的问题,在于它只是一个分布式文件系统。这就是为什么我个人建议你把你的最终产品表存储在一个像Apache Kudu这样的存储中,或者像MySQL或PostgreSQL这样的RDBMS中。但如果出于某些原因,你把数据保存在HDFS中,你就需要编写自己的存储管理层。

分区管理

那么,这个存储管理层到底应该做什么--要看你的具体问题。例如,在我们的案例中,有3个目标。

1. 合并选定表上的分区
我想让 "分区管理器 "定期将小时分区合并为月分区。我之所以选择月维度作为合并标准,是因为它能生成最佳大小的分区(100mb-1gb)。例如,我不希望一张表按月分区,另一张表按年分区,因为我想让我们的用户(包括分析师和数据开发人员)感到简单。合并过程将在后面详细介绍。

2. 对冷数据进行归档
有时我们想把某些表的数据保存多年,尽管旧数据可能会少用很多。我希望我的存储管理层能够对2年或3年以上的分区进行 "归档"(当然这取决于你的使用情况)。这是通过将数据移动到另一个版本的表中,并使用更积极的压缩算法,如GZIP(与 "热 "表中的SNAPPY相比)。

3. 删除分区
当然,我们可能希望为我们要从HDFS中删除其旧数据的表选择一定的阈值(很可能是时间阈值)。这是我们希望存储管理层提供的一个非常基本(但必要)的功能。

这3个功能都很重要,但我认为第一个功能是最棘手的,也是我开始写这篇文章的实际原因,是为了解释我认为应该怎么做。

分区合并

首先,我不得不说,这个任务的复杂程度真的取决于你的情况。在我们的情况下,定期合并分区的任务并不简单,因为有以下要求。

生产表对停机时间的容忍度为零 尤其是超过几秒钟的时候就不行了。
不丢失时间解析--我们发现有些表是按DT分区的,但没有其他匹配的时间列。这意味着如果我们要把 "2018041312 "合并到 "201804",用户就会失去这些分区上的每日和每小时的维度数据。
尽可能的无缝--我们的目标是让分区合并对用户来说是无缝的。我们发现,在某些情况下,用当前的分区方法根本不可能,但在不同的分区方法中,这是很可能的。后面会详细介绍。
所以,现在我们意识到这可能不是一个简单的问题,我们来看看我们是如何解决的。
如何合并Hive表中的分区?
这个过程非常简单。这里描述的所有查询都是Impala查询,但在其他技术中,如Hive、SparkSQL、Presto等,其语法相当相似(有时甚至相同)。另一个需要记住的是,在 "合并查询 "之前,你可能需要执行的设置,以使它们生成最佳大小的文件。例如在Impala中,你可能要执行。

set num_nodes=1;

执行合并查询--下面的例子演示了将2019年4月的所有小分区合并到一个月度分区。

INSERT OVERWRITE tbl PARTITION(dt) AS SELECT t.col1, t.col2, ..., SUBSTR(t.dt, 1, 6) AS dt FROM tbl t WHERE t.dt LIKE '201904%';

从元存储中删除旧的分区(如果是外部表,只有分区元数据会被删除),例如:

ALTER TABLE tbl DROP PARTITION(dt='2019040101')。

从HDFS中删除每个旧分区的目录。

curl -i -X DELETE "http://:/webhdfs/v1/?op=DELETE&recursive=true"

如果你使用的是Impala,你应该使表的元数据缓存无效。

INVALIDATE METADATA tbl;

很简单,不是吗,好吧,这样我们就解决了第一个问题--没有停机时间,但权衡的结果是,有一个时间窗口,用户会看到一个重复的数据(直到所有的DROP PARTITIONS完成)。我们决定这样做很好。

那么好吧,现在我们没有统一的小时DT分区,而是统一的月DT分区。这完全不是无缝的,我们可能会在某些表中失去时间分辨率。在处理分辨率损失之前,我们先解决第一个问题。

用户视图中的合并分区
我们的用户分为。"普通 "用户、分析师、数据科学家和数据工程师。数据科学家和数据工程师是一个小规模的技术群体,所以他们很容易适应这种变化。问题是分析师和普通用户,我们有很多人。

反正这么简单的变化,为什么很难适应呢?很简单,就是201801而不是2018010101。好吧,原因是--如果用户会用下面的方式查询一张表。

SELECT * FROM tbl WHERE dt > '2018011220' AND < '2018022015';

它将只扫描'201802'的分区。不仅如此,它还会得到所有的月份,而不仅仅是他想要的日期。为了得到正确的结果,他们将不得不改变DT过滤,并添加另一个时间列(在下面的例子中 "insertion_time")过滤。

SELECT * FROM tbl WHERE (dt BETWEEN '201801' AND '201802') AND (from_timestamp(insertion_time, 'yyyMMddHH') BETWEEN '2018011220' AND '2018022015');

```
但是我们并没有处理所有表的合并分区,只是处理有问题的表(那些由许多小文件组成,并且经常被查询的表)。所以我不能告诉我的用户,从现在开始所有的表都是这样管理的(过去2个月--每小时,超过2个月的--每月)。因为只有部分表是这样处理的,所以要求他们在查询之前先检查一下。这是无缝的反面。

对于普通用户,我们花了一点力气就解决了这个问题:我们改变了他们使用的BI系统中的查询模板,以适应新的分区。普通用户是通过某个BI工具来查询我们的datalake。这样一来,查询本身对用户是透明的。我可以很容易的把模板从:

```
... WHERE (dt BETWEEN from_timestamp({from}, 'yyyyMMddHH') AND from_timestamp({to}, 'yyyyMMddHH')) AND (insertion_time BETWEEN {from} and {to});

```
到:

```
... WHERE (dt BETWEEN from_timestamp({from}, 'yyyyMM') AND from_timestamp({to}, 'yyyyMMddHH')) AND (insertion_time BETWEEN {from} and {to});

```
注意,我将{to}的格式保持为小时(yyyyMMddHH)。因为,例如,如果一个用户想查询最近6个月的数据--我不想让他错过最后一个月,就像下面的查询。

```
SELECT * FROM tbl WHERE dt BETWEEN '201810' AND '201904';

```
这个查询会错过2019年4月的所有分区, 因为它们仍然是以小时为单位的格式, 相反,我希望这个查询看起来像这样:

```
SELECT * FROM tbl WHERE dt BETWEEN '201810' AND '2019041519';

```
好处是,即使用户只想查询旧的月份,比如说2018年10月到12月,也能正常工作,得到所有相关的月度分区。

嗯,这对我们来说其实已经很好了,因为我们绝大多数用户都是用BI工具,自己不写SQL。至于那些确实会写SQL的分析师,我们决定他们必须检查分区管理器中是否管理了一张表,并相应地调整他们的查询--当然我们必须支持并帮助他们适应这种方法。

我们是如何处理解析损失的
这只需要改变表本身:增加一个 "original_dt "列,并确保填充该表的数据过程 "知道 "它的存在。当然,我们需要应用同样的过程,改变BI系统中的相关查询模板,并让分析师知道这个变化。
嵌套的日期时间分区
最简单的方法是当你有嵌套DT分区而不是平面DT时,就可以进行无缝分区合并。

year=2019/month=04/day=16/hour=19

这样的话,在合并小分区的同时,将省略的分辨率作为列添加到表格中,对用户来说将是完全透明的。例如,如果我想将小时分区合并为月分区,我将按照以下步骤操作。

在原表的基础上创建一个合并版本,像这样:

```
CREATE EXTERNAL TABLE tbl_merged_nested (
  col1 STRING,
  col2 STRING,
  ...,
  day STRING,
  hour STRING
) PARTITIONED BY (
  year STRING,
  month STRING
)
STORED AS PARQUET;

```
执行合并查询。

```
INSERT OVERWRITE TABLE tbl_merged_nested PARTITION(year, month)
SELECT col1, col2, ..., day, hour, year, month FROM tbl_original_nested WHERE year='2019' AND month='04';

```
从metastore中删除原表的旧分区(当然之后也要从HDFS中删除这个目录)。

```
ALTER TABLE tbl_original_nested DROP PARTITION(year='2019', month='04', day='17', hour='20')

```
然后,如果我想要一个 "热 "的表和一个 "合并 "的表,我可以创建一个视图来联合这两个表,这对用户来说将是完全无缝的,他们不会关心年、月、日或小时列是否是分区。

```
CREATE VIEW union_view AS SELECT * FROM tbl_original_nested UNION ALL SELECT * FROM tbl_merged_nested

```
因此,要想真正无缝合并DT分区,最重要的条件就是要让它们嵌套而不是扁平化。

### 总结
不要在HDFS中存储小型的、经常查询的表,尤其是当它们由数千个文件组成时更不要。将它们存储在另一个地方,比如RDBMS(MySQL、PostgreSQL等)或Apache Kudu中,如果你想留在Hadoop生态系统中。当然,你必须提供一个解决方案来执行这些表和Hive表之间的连接查询,我推荐Presto(如果你使用Kudu,Impala也可以)。
如果你必须将它们存储在HDFS中,一定要有一个存储管理层("分区管理器")来处理分区合并,防止出现表有很多小文件的情况。
如果你想让分区合并对用户透明化,那么分区合并是很困难的。但与扁平的DT分区相比,嵌套的分区让无缝合并变得更加容易。
希望这篇文章能对一些人有所帮助,也请大家发表评论,分享你对Hadoop中分区管理的看法。

相关文章

热门文章

更多