带你读《2022技术人的百宝黑皮书》——ODPS SQL优化总结(6) https://developer.aliyun.com/article/1247144?groupCode=taobaotech
解决步骤
skewjoin
看到JOIN节点运行缓慢，第一反应是数据倾斜，通过对淘宝天猫订单表按照商品维度汇总统计也可以印证存在热销商品的情况。于是毫不犹豫使用了ODPS的skewjoin hint。然而经过几次测试，JOIN节点运行缓慢的问题有所缓解，但是运行时长还是2个多小时，明显没有达到优化的预期。
传统的热点数据分离
skewjoin时效有所提升，但是还不是很理想，想尝试下传统的热点数据拆分：淘宝天猫订单表中热卖TOP50W商品写入临时表，TOP50W商品订单明细与对应的商品属性表、SKU属性表MAPJOIN，非TOP50W商品订单明细与对应的商品属性表、SKU属性表普通JOIN。但是运行时效还是不太理想，也要2个多小时。
执行计划详细分析
隐式转换
实在是不知道哪里出现了问题，尝试通过执行计划，看下具体的执行细节，在这里猛然发现了一个很大的问题：关联的时候，item_id和SKU_ID都先转换成了DOUBLE再进行关联。
通过一个简单SQL测试也印证了这个问题，bm_dw.dim_itm_prop_dtl_di表中item_id存储的是string，查询时item_id输入为bigint，但是执行结果明显错误，原因就是默认把int的数据转换成了double再去匹配。
但是也尝试用比较常规长度的item_id查询，貌似数据又是正确的，猜想大概是超过15-16位后精度就不准确导致。
带你读《2022技术人的百宝黑皮书》——ODPS SQL优化总结(8) https://developer.aliyun.com/article/1247141?groupCode=taobaotech
