干货分享|袋鼠云数栈离线开发平台在小文件治理上的探索实践之路

日常生产中 HDFS 上小文件产生是一个很正常的事情,同时小文件也是 Hadoop 集群运维中的常见挑战,尤其对于大规模运行的集群来说可谓至关重要。

file

数据地图离线开发产品的基本使用单位,包含全部表和项目的相关信息,可以对表做相关的权限管理和脱敏管理操作,以及可以展示对应项目占用情况和其表的占用情况。数据地图可以帮助用户更好地查找、理解和使用数据。

本文将结合两者,和大家聊聊数据地图中的小文件治理应该怎么做。

小文件的危害

小文件通常指文件大小要比 HDFS 块大小还要小很多的文件,大量的小文件会给 Hadoop 集群的扩展性和性能带来严重的影响。

NameNode 在内存中维护整个文件系统的元数据镜像、用户 HDFS 的管理,其中每个 HDFS 文件元信息(位置、大小、分块等)对象约占150字节,如果小文件过多,会占用大量内存,直接影响 NameNode 的性能。相对地,HDFS 读写小文件也会更加耗时,因为每次都需要从 NameNode 获取元信息,并与对应的 DataNode 建立连接。如果 NameNode 在宕机中恢复,也需要更多的时间从元数据文件中加载。

同时,小文件会给 Spark SQL 等查询引擎造成查询性能的损耗,大量的数据分片信息以及对应产生的 Task 元信息也会给 Spark Driver 的内存造成压力,带来单点问题。此外,入库操作最后的 commit job 操作,在 Spark Driver 端单点做,很容易出现单点的性能问题。

数据地图中小文件治理的做法

存储在 HDFS 中的文件被分成块,然后将这些块复制到多个计算机中(DataNode),块的大小默认为128MB,当文件大小为128时,Hadoop 集群的计算效率最高。因此对非分区表按表进行数据文件合并,使表/分区数据文件的大小接近128M,以此进行小文件的优化。

具体到数据地图中是怎么做的呢?

离线开发平台中创建出来的表或者底层表都可以通过数据地图功能维护,我们每天会定时更新这些表的基本信息进行统一维护管理。

在数据地图中可以根据文件数量和占用存储创建相应的治理规则,按照每天每周或每月治理。

file

参数说明

· 规则名称:新建规则的名称

· 选择项目:小文件合并规则生效的项目

· 选择表:这里配置的是圈定需要合并的表范围,判断条件是 and,例如表的文件数量大于1000并且占用总存储小于10M时,才会对该表中的文件进行合并操作

· 治理时间:该规则的调度周期,例如每天的凌晨00:00~01:00进行小文件合并,注意如果小文件合并时间到了结束的时间,还没有合并完成,则会结束当前的合并,等待下次处理

file

根据治理规则查询出所有符合信息的表,判断该表是否为分区表。如果为非分区表则对该表进行文件治理,如果为分区表则按照分区进行治理,最后创建治理记录。

file

每天定时任务触发,根据告警记录查询记录中满足条件的表的基本信息状态。

file

● 小文件合并的具体步骤

1)备份文件

先创建临时路径,把文件复制到临时路径中去,再创建要合并的临时文件

file

2)小文件合并

执行 HDFS 的 fileMerge 请求合并文件

file

真正调用 hive-exec 方法处理,判断是否达到阈值合并文件

file file

3)将合并的文件覆盖到原文件中去

判断如果合并完成,删除原路径下的数据,把临时路径修改为原来的真实路径

file

全部处理完成后,查询 rdos_file_merge_partition 表是否为异常信息打印,若不存在异常信息,更新治理记录表完成治理,并更新数据地图中的表信息

file

治理记录表把握整体的治理成功失败状态,分区信息治理信表维护了整个治理记录哪些表治理失败的记录,最后全量返回对应的是失败或成功状态。

· 分区信息治理信表:rdos_file_merge_partition

· 治理记录表:rdos_file_merge_record

最后把表结构放在下面,有兴趣的小伙伴可以自行查看:

CREATE TABLE `rdos_file_merge_partition` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `project_id` int(11) DEFAULT NULL COMMENT '项目id',
  `tenant_id` int(11) DEFAULT NULL COMMENT '租户id',
  `record_id` int(11) DEFAULT NULL COMMENT '合并记录id',
  `status` tinyint(1) DEFAULT NULL COMMENT '合并状态',
  `start_time` datetime DEFAULT NULL COMMENT '开始时间',
  `end_time` datetime DEFAULT NULL COMMENT '结束时间',
  `error_msg` longtext COMMENT '错误信息',
  `partition_name` varchar(255) DEFAULT NULL COMMENT '分区名',
  `copy_location` varchar(1024) DEFAULT NULL COMMENT '备份路径',
  `storage_before` varchar(255) DEFAULT NULL COMMENT '合并前占用存储',
  `storage_after` varchar(255) DEFAULT NULL COMMENT '合并后占用存储',
  `file_count_before` int(11) DEFAULT NULL COMMENT '合并前文件数量',
  `file_count_after` int(11) DEFAULT NULL COMMENT '合并后文件数量',
  `gmt_create` datetime DEFAULT NULL COMMENT '创建时间',
  `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
  `is_deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除 0:未删除,1 :已删除',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='小文件合并分区信息表';

CREATE TABLE `rdos_file_merge_record` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `project_id` int(11) DEFAULT NULL COMMENT '项目id',
  `tenant_id` int(11) DEFAULT NULL COMMENT '租户id',
  `table_id` int(11) DEFAULT NULL COMMENT '合并hive表id',
  `table_name` varchar(255) DEFAULT NULL COMMENT '表名',
  `rule_id` int(11) DEFAULT NULL COMMENT '小文件合并规则id',
  `location` varchar(1024) DEFAULT NULL COMMENT '存储位置',
  `status` tinyint(1) DEFAULT NULL COMMENT '合并状态',
  `error_msg` longtext COMMENT '错误信息',
  `start_time` datetime DEFAULT NULL COMMENT '合并开始时间',
  `end_time` datetime DEFAULT NULL COMMENT '合并结束时间',
  `is_partition` tinyint(1) DEFAULT NULL COMMENT '是否是分区表',
  `count_before` int(11) DEFAULT NULL COMMENT '合并前文件数量',
  `count_after` int(11) DEFAULT NULL COMMENT '合并后文件数量',
  `create_user_id` int(11) DEFAULT NULL COMMENT '创建用户',
  `modify_user_id` int(11) DEFAULT NULL COMMENT '修改人id',
  `gmt_create` datetime DEFAULT NULL COMMENT '创建时间',
  `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
  `is_deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除 0:未删除, 1:已删除',
  `plan_time` datetime NOT NULL COMMENT '计划时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='小文件合并记录表';

《数据治理行业实践白皮书》下载地址:https://fs80.cn/380a4b

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:https://www.dtstack.com/?src=szcsdn

同时,欢迎对大数据开源项目有兴趣的同学加入我们,一起交流最新开源技术信息,号码:30537511,项目地址:https://github.com/DTStack

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

袋鼠云数栈

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值