hive表如果设计成一个分区表，则每个分区在hdfs上是一个存储目录，当对这个分区进行读或者写操作时只会影响该目录下的文件。

这样不用每次计算都读写全量的数据表，对于数仓开发来说可以化全量为增量，降低了计算成本。

另一方面，一个表有多个分区，可以有多个任务同时写入不同的分区，开发上可以逻辑解耦，计算上可以加速执行。

最后，以时间为分区字段的表，可以方便的进行生命周期的管理

然而分区字段设计的不合理，也会引起一些危害，常见的危害有分区太多引起的小文件类问题和分区不合理引起的计算开销大的问题。

2.1 小文件过多对NameNode产生压力

小文件产生的一大原因就是分区表，假如一个表有a，b，c三个分区字段，每个字段有x，y，z个枚举值，则这张表可能会生成x*y*z个文件，如果xyz都是100，则会产生100w个文件。NameNode针对每个文件会存储位置路径、大小、分块等元数据信息，文件越多NameNode的压力越大，能够管理的节点规模也就越少，压力达到一定程度可能引起NN的响应变慢，甚至OOM挂掉。

NN响应变慢的一个危害是任务读写数据时耗时增加，如下图因为需要提交大量的文件，导致在计算完成后还需要额外的1个多小时提交文件。同理下游在读取一个包含大量文件的数据表时，也会额外花费大量的时间

2.2 分区过多，运维起来吃力

由于分区数过多，进而导致文件数多，删除数据需要频繁的元数据访问消耗大量的时间

2.3 小文件过多会造成资源浪费

2.4 小表设计了分区导致无法广播

BroadcastJoin可以解决数据倾斜，减少shuffle开销的作用，是提升性能的一个很好的方法。但是当前美团集群中的设置导致无法谓词下推到某一具体分区的分区表很难走广播，进而可能引起数据生产变慢甚至产生数据倾斜

2.5 分区字段设计不合理导致下游任务开销大

hive表的分区字段可以近似等价于一个稀疏索引，如果下游在查询时能够使用到分区字段则可以减少扫描的数据量，加速计算。但如果分区字段设计的不合理，也可以造成下游总是需要超量扫描甚至全表扫描。比如分区字段设计为week，但下游总是按照date或month去查，或者分区字段是下单日期但下游总是按照支付日期去生产。

2.6 分区字段可能造成数据倾斜

这种情况一般发生在海量数据下，一个表的分区字段可能无法把数据均匀的散列，这样会导致有的分区下数据量大，有的分区下数据量小。此时在shuffle阶段设置partition的数量就有困难，如果是按照shuffle的数据量设置比较大的partition则可能出现小分区下产生大量小文件（如2.1情形）。如果设置比较少的partition，则大分区下的单个文件可能多大，引起数据倾斜。

2.7 分区字段设计不合理造成每天回刷周期长

这种情况一般是新手可能会发生，在创建数据表的分区字段时，选择了一个可变的字段，每天这个字段的值发生变化则需要重新计算这条数据并归属新的分区。比如用modify_time做分区字段，一条数据可能今天属于20220101，明天属于20220102，后天属于20220103

知晓了分区字段设计不合理带来的危害，我们在实际开发工作中应该尽量避免。我总结了分区字段设计应该尽量遵循的原则，可以帮助大家做出正确的设计。注意：由于业务场景复杂多变，有时可能无法做到一定遵守原则，需要结合实际情况综合考虑。