漫谈千亿级数据优化实践：一次数据优化实录

最新推荐文章于 2022-07-21 09:53:27 发布

A心无旁骛

最新推荐文章于 2022-07-21 09:53:27 发布

阅读量340

点赞数

分类专栏： php 文章标签：数据优化 hive

php 专栏收录该内容

40 篇文章 0 订阅

订阅专栏

0x00 前言

即使没有数据倾斜，千亿级的数据查询对于系统也是一种巨大负担，对于数据开发来说，如何来优化它，既是挑战，也是机遇！

在上一篇文章《漫谈千亿级数据优化实践：数据倾斜（纯干货）》中，我们分享了一些在千亿级数据优化实践中和数据倾斜相关的内容。本文将分享千亿级数据优化的另个一点：如何使用使用数据！

注意：

本文会限定一些业务场景和技术架构，因此解决方法会局限于此。很多问题可以通过换架构或者引入新的组件来解决，但是成本可能会很高，因此暂不考虑。
本文不是一篇Hive使用和优化文档，更侧重于梳理笔者的思路，让大家少走些坑。

文章主题

在流行的大数据领域中，Hive绝对占据了很大的一片天地，不管是数据仓库和数据分析，还是数据挖掘和机器学习，凡是需要和大数据量打交道的童鞋们，基本上都要接触hive。因此，本文将侧重于千亿级数据在Hive中的使用，并通过一个典型的数据使用难题来总结一些在大规模数据场景下的优化方式。

本文主要以一个具体的使用场景为切入点，为了解决该场景下的使用难题，笔者经理了一次次的尝试+失败，最终找到了一种相对比较合适的方式。

文章结构

本文可以看过是一种记录和思考，完全还原笔者在遇到问题时的解决方式。因此全文会以事情的发展为主线，每次尝试一种解决方法，失败后继续查找新的方法，中间会穿插一些技术细节。

文章主线如下：

明确使用场景和困难。
如何解决，这是一个不断推翻重来的过程。
回顾总结

0x01 问题来了！

本章作用主要有二：

明确业务背景和使用场景
明确困难所在

1. 业务背景和使用场景

按照惯例，我又来到了一家电商网站来工作，我们有一张十分重要的表：用户和购买过的商品表。

如下图，该表只有三个字段，分别是用户ID、商品ID。我们可以简单地理解这是一张事实表。对事实表没印象的可以参考这篇《漫谈数据仓库之维度建模》。

我们暂且不管当初为何这样设计的，现在的情况就是

列名	字段类型
user_id	string
product_id	string

这张表有哪些使用场景呢：

输入一批用户，找到和他们有相似购买行为的用户
统计用户购买商品的数据区间
……

总之这张表能用到的地方是极多的，相信数据分析和数据挖掘的童鞋们肯定能想到很多场景，这里就不展开讲了。

问题来了： 数据量太大，随便一个查询就是五六个小时，有没有办法优化？

2. 困难

先说明一下问题在哪。

数据量大

这张表里面保存了我站来自全球的50亿用户和他们购买过的商品，粗略估计一下，人均会购买60件商品，也就是说这张表有 3000亿 的数据。

3千亿条记录是什么概念呢，如果存成没有压缩的txt文件的话，大致有30T以上。如果做一个压缩，我们保守一点估计，要有接近10T的数据。

查询速度慢

这么大数据量，查询起来的确比较慢。可能随便跑一个数据，就要3到5个小时。

我们可以大致地分析一下慢的原因：

扫描数据量大
join的时候时间长
因为我们的reduce数量右限制，每个reduce需要处理的数据量太多
shuffle的时候效率太低。

0x02 解决过程

我们在解决这个难题的时候是围绕一些出发点的：

减少扫描的数据量
加快关联查询的速度

1. 分区

第一个思路就是分区，我们可以根据用户的账号分布来进行分区，然后在扫描的时候，只扫描部分分区就行。好，我们做一个设计。

我们美好的愿望是：假设有一个需求需要查询一定的用户的购买记录，我们不用扫描全量的数据，只扫描其中一部分即可。

下面我们基于几个设定来设计我们的分区规则：

假设我们的用户id都是数字类型的，如下图。
我们按照账号的id来设计分区函数，比如说前四位相同的放在一个分区中。
写入数据，和查询数据使用相同的分区函数

这样我们就有了1万个分区，每个分区中有30万用户的购买记录，也就是说每个分区中会有1800万的记录数，总计约1G的文件大小。

下面就是我们设计出来的分区。

我们的想法是好的，下面举几个场景：

比如现在需要查100个用户的数据，不分区的话，我们需要扫描全量的数据，现在我们可能只要扫描10个分区，最多100个分区，也就是我们的速度回提升100倍以上。
需要查1万个用户的数据，我们假设会命中1000个分区。
需要查10万个用户的数据，我们假设会命中5000个分区。

例子我都举不下去了，实际情况是，如果用户分布比较分散的话，超过20万个用户的话，基本上就命中了所有了分区了。 这个感兴趣的可以测一下。

增加分区数？

这个方案是可以的，比如我们变成10万个分区，这样当然可以，但是让需要查询的用户多的话，效果照样变弱，而且更多的分区意味着每个分区的数据会变少，这样小文件就会多很多。

结论

分区的方式不靠谱！

2. 索引

注意： Hive的索引也是个坑，怪不得没人用，但是我们还是要设计一下。

基于“减少扫描的数据量”这点来讲，索引是一种极妙的方式，有了索引，我们就不必全量扫描所有的数据，速度肯定就快了呀。但是， Hive的索引是个坑。

下面讲一下Hive索引的机制就明白了。

Hive索引机制

在指定列上建立索引，会产生一张索引表（Hive的一张物理表），里面的字段包括，索引列的值、该值对应的HDFS文件路径、该值在文件中的偏移量。

如下，是Hive的索引表。其中，索引表中key字段，就是原表中key字段的值，_bucketname 字段，代表数据文件对应的HDFS文件路径，_offsets 代表该key值在文件中的偏移量，有可能有多个偏移量，因此，该字段类型为数组。

列名	字段类型
user_id	string
_bucketname	string
_offset	array < bigint >

在执行索引字段查询时候，首先额外生成一个MR job，根据对索引列的过滤条件，从索引表中过滤出索引列的值对应的hdfs文件路径及偏移量，输出到hdfs上的一个文件中，然后根据这些文件中的hdfs路径和偏移量，筛选原始input文件，生成新的split，作为整个job的split，这样就达到不用全表扫描的目的。

注意： 按照上面的说明，我们的索引其实就是另一张Hive的表，而且数据量还是很大。下面从两个点说明Hive的索引方案不能用。