एक Spark task घंटे भर चलता है जबकि बाकी सेकंडों में खत्म हो जाते हैं। क्या हो रहा है और आप इसे कैसे ठीक करेंगे?

यह data skew है: एक key के पास rows का बेतुका बड़ा हिस्सा है, इसलिए shuffle के बाद ज्यादातर काम एक ही partition करता है। इसकी पुष्टि join या group key के distribution को देखकर करें। ठीक करने के लिए adaptive query execution का skew join handling चालू करें, छोटी साइड फिट हो तो उसे broadcast करें, hot key को कई partitions में salt करें, या outlier keys को अलग करके अलग से process करें।

एक ही task पर लंबी पूंछ का लगभग हमेशा मतलब skew होता है: shuffle के बाद एक key एक partition में उतरी और ज्यादातर rows उसी partition में हैं। पहले मैं मान लेने के बजाय पुष्टि करता हूं, यानी join key पर count के साथ एक group by, और Spark UI में उस stage पर नजर जहां max task duration और shuffle read size median से कहीं बड़े हैं। इस पर executors फेंकने से कुछ नहीं होता, क्योंकि काम बंटा ही नहीं है। इलाज शक्ल पर निर्भर है। अगर join की दूसरी साइड छोटी है, तो उसे broadcast कर दें और shuffle पूरी तरह छोड़ दें। अगर दोनों साइड सचमुच बड़ी हैं, तो adaptive query execution skewed partitions को अपने आप बांट सकता है, और उससे आगे मैं salt करता हूं: hot key पर एक random suffix लगाता हूं, छोटी साइड को उन salts में replicate करता हूं, join करता हूं, फिर aggregate करता हूं। जिस चीज पर लोग फंसते हैं वह nulls है। हमारी एक join key करीब 40% rows में null थी, वे सब एक ही partition में hash हो रही थीं, और join से पहले nulls filter करने भर से मामला ठीक हो गया।