- 主题:hive分区如何选择
请教大家:
hive表,有按天、按ID查询的需求, 所以按天,按ID建立了分区。
每个分区存储的数据只有2M。这样的话,感觉会有小文件问题。
但确实有按天、按ID的查询需求,所以不知道怎么去建立分区,读取效率会更高?
--
FROM 223.104.41.*
2M大小的数据。不是200万数据
目前就是按天,按ID,
但一年365天
ID有3000多个
那一年就 365*3000=110万个分区, 感觉有点多
但如果只按天,或者只按ID分区
又怕检索起来,既有按天的检索又有按ID的检索,怕会慢
不知道分区太多对检索速度影响大,还是分区没有按天按ID,对检索影响大
如果差不多,就不折腾了。
【 在 eventvwr 的大作中提到: 】
: 2M是200w数据还是数据文件只有2M大小?
: 这点数据随便整吧。就按天吧,更符合使用习惯些
--
修改:qianfeng018 FROM 223.104.41.*
FROM 223.104.41.*
收到。 明白了
确实写入速度很慢,不过写入的性能要求比较低,不影响 使用感受。
【 在 eventvwr 的大作中提到: 】
: hive的分区其实就是个目录。查询速度只取决要扫描的数据块个数和大小。和分区数多少没有绝对的关系,你当前的分区方式,查询肯定更快啊,但是快的有限,因为你的数据量太小了。但是写入速度肯定会慢很多
--
FROM 223.104.41.*
遗留架构。更改太费劲
【 在 RickyDu 的大作中提到: 】
: 这点数据搞个clickhouse或者doris不是嗖嗖的,用啥hive
--
FROM 223.104.41.*
多谢指点
学习学习去
【 在 zeus2615 的大作中提到: 】
: 你增加一列,把ID映射一下,譬如叫idhash,用天和idhash分区,让单个分区的大小至少进入G级别,查询时多带一个idhash的条件,读速度影响不大,毕竟你这数据太小了。写速度能上两个数量级。
: 或者就像其他人说的,换个适合你这小体量的OLAP数据库。
: 推荐你去看Oreilly《数据密集型应用系统设计》,其中关于索引的章节,它循序渐进的介绍了主流OLAP系统索引常见设计,为什么要这么做,不同设计的差异。最重要的是,能帮助理解在使用OLAP的时候该注意哪些技巧,譬如你正在面对的分区问题。中文版如果遇到看不懂的地方去读英文版,中文版比机翻好点但是不多。
: ...................
--
FROM 223.104.41.*
确实是, 有不同的查询需求:
1 按ID,取某一天到某一天的全部数据,
2 按天,取某些ID的数据
所以之前的分区,才会选择既按天、又按ID分区
本来预期会存秒级数据,所以数据量也不会太小
结果现在只存聚合后的数据,就只剩下每天每个ID 2M大小的数据了
减少每个分区文件大小设置,比如从128M减到2M,应该对加快查询效率没啥意义吧?
【 在 jimmycmh 的大作中提到: 】
: 按ID分区就有用啊
:
--
FROM 223.104.41.*
收到,多谢
【 在 jimmycmh 的大作中提到: 】
: 我前面说过了,你所有的查询里都有天,在每天数据量不多的情况下,按天分区就足够了,分区内遍历找id并不慢
: 如果按天分区,分区内数据量过多,可以天+id联合分区
: 也可以考虑按月+id联合分区,需要计算一下分区大小
: ...................
--
FROM 223.104.41.*