大家好，我是明哥！本篇总结一下order/sort/cluster/distributeby和BUCKET桶表1HIVE中的ORDERBYORDERBY会对SQL最终输出的数据进行全局排序；ORDERBY底层只会有一个Reducer任务（多个Reducer不能保证全局顺序）；当然，当只有一个Reducer任务时，如果输入数据规模很大，会消耗很长的计算时间；ORDERBY的默认排序顺序是升序(ASC)。示例语句：selectdistinctcust_id,id_no,part_datefromads_api_cda_basic_info_parquet_ptorderbycust_id；2SORTBYSORTBY并不是对SQL最终输出的数据进行排序，而是对MAP的输出数据进行排序。指定字段已排序；SORTBY不会影响REDUCER的个数；SORTBY只会保证每个reducer内部数据的顺序，不会保证SQL最终输出的全局顺序；示例语句：selectdistinctcust_id,id_no,part_datefromads_api_cda_basic_info_parquet_ptSORTbycust_id;图3DISTRIBUTEBYDISTRIBUTEBY指定了MAP端输出记录交给reducer做进一步处理的分配规则；DISTRIBUTEBY不会影响REDUCER的个数；具有相同的DistributeBy字段，MAP端的输出数据会分布到同一个reducer中进行处理（默认使用hash取模算法）；DistributeBy不保证每个REDUCER中所有记录的顺序；示例语句：selectdistinctcust_id,id_no,part_datefromads_api_cda_basic_info_parquet_ptdist按cust_id致敬；图片DISTRIBUTEBY和SORTBY一起使用，保证每个REDUCER内部所有记录的顺序（此时DistributeBy分区字段和SORTBY排序字段可以是不同的字段）；示例语句：selectdistinctcust_id,id_no,part_datefromads_api_cda_basic_info_parquet_ptdistributebycust_idsortbyid_no;DISTRIBUTEBY和SORTBY一起使用，选择合适的DISTRIBUTEBY字段，可以解决以下问题：Map输出的文件大小不均匀；Reduce输出的文件大小不均匀；小文件太多；文件太大；4CLUSTERBYCLUSTERBY相当于DISTRIBUTEBY和SORTBY一起使用；底层的DistributeBy分区字段和CLUSTERBY的SORTBY排序字段是同一个字段；CLUSTERBY不会影响REDUCER数量；示例语句：selectdistinctcust_id,id_no,part_datefromads_api_cda_basic_info_parquet_ptclusterbycust_id;CLUSTERBYinsparkwebui5BUCKET桶表HIVE有一个BUCKET桶表，该桶表具有以下优点：桶表可以支持高效采样；桶表更好地支持高效的mapsidejoin；声明bucket表时需要指定bucket字段和bucket个数(CLUSTEREDBY(user_id)INTO31BUCKETS)；桶表的写操作在底层执行，会自动添加CLUSTERBY子语句，按照桶表声明时指定的bucketing字段分发数据；（如果是HIVE版本0.x或者1.x，需要配置参数sethive.enforce.bucketing=真；HIVE2.X之后去掉了这个参数，相当于一直为TRUE；）底层执行bucket表的写操作时，会有一个reducer，reducer的个数会自动使用语句桶表中指定的桶数；（如果是HIVE版本0.x或者1.x，需要配置参数sethive.enforce.bucketing=true；HIVE2.X之后，这个参数去掉，相当于yualwaystrue；）通过选择合适的bucketing字段和bucket个数，bucket表可以有效控制表底小文件的个数，从而缓解数据倾斜和小文件的问题；使用buckettable缓解数据倾斜问题在处理小文件问题时，所有的改动都在DDL层面，不需要改动DML语句和增加CLUSTER/DISTRIBUTEBY子语句。同时，由于DDL是系统上线或后续运维优化调整时的一次性操作，增加了系统的灵活性和运维优化的便利性；可以使用下面的DDL语句来声明BUCKET桶表，类似于下面的DML语句来操作桶表：##DMLINSERTOVERWRITEbucket_tableAselect*fromxx；插入覆盖bucket_tableASPARKWEBUI
