Amazon S3 पर partitioned Parquet लिखते समय Polars v1.33 में सुधार

Amazon S3 पर partitioned Parquet लिखते समय Polars में use_pyarrow के फर्क से लोकल स्टेजिंग व ACCESS_DENIED समस्याएँ, और v1.33 के फिक्स व सुझाए गए कदम जानें.

polars से Amazon S3 पर partitioned Parquet लिखते समय, चुने गए बैकएंड के आधार पर व्यवहार अप्रत्याशित हो सकता है। व्यवहार में दो लक्षण दिखते हैं: pyarrow इंजन बंद करने पर, अपलोड से पहले फाइलें स्थानीय रूप से स्टेज होती हैं और वे स्थानीय आर्टिफैक्ट अपने आप नहीं हटते; pyarrow इंजन चालू करने पर, अपलोड ACCESS_DENIED त्रुटि के साथ विफल हो सकता है, जिसमें anonymous multipart uploads का उल्लेख होता है। नीचे समस्या का संक्षिप्त विवरण और इसके समाधान की मौजूदा स्थिति दी गई है।

कोड में पुनरुत्पादन

नीचे दिया गया उदाहरण storage_options के माध्यम से दिए गए स्पष्ट AWS क्रेडेंशियल्स के साथ एक partitioned DataFrame को S3 पर लिखता है। बैकएंड बदलने से परिणाम बदल जाता है।

aws_sess = ...  # boto3 सत्र
creds = aws_sess.get_credentials()
io_opts = {
    "aws_access_key_id": creds.access_key,
    "aws_secret_access_key": creds.secret_key,
    "aws_session_token": creds.token,
    "aws_region": "eu-west-1",
}
s3_uri = f"s3://{bucket_name}/{prefix_path}"
# polars DataFrame इंस्टेंस
tbl.write_parquet(
    s3_uri,
    partition_by=part_cols,
    storage_options=io_opts,
    use_pyarrow=...  # True | False, अलग व्यवहार
)

असल में हो क्या रहा है

use_pyarrow=False होने पर, polars S3 पर अपलोड से पहले डेटा की लोकल कॉपी बनाता है और वे फाइलें स्वतः साफ नहीं होतीं। use_pyarrow=True होने पर, लिखना इस तरह की त्रुटि से विफल हो सकता है: “Uploading to <file> FAILED with error When initiating multiple part upload for key <directory> in bucket <bucket>: AWS Error ACCESS_DENIED during CreateMultipartUpload operation: Anonymous users cannot initiate multipart uploads. Please authenticate.” यह व्यवहार एक ज्ञात समस्या थी, जो pl.DataFrame.write_parquet और pl.LazyFrame.sink_parquet दोनों को प्रभावित कर रही थी। चर्चा सार्वजनिक रूप से sink_parquet के लिए polars#23114 और write_parquet के लिए polars#23221 के तहत ट्रैक की गई है।

समाधान और अपडेटेड व्यवहार

समाधान जारी हो चुका है। polars v1.33 से, बताई गई समस्याएँ अब नहीं होतीं और partitioned Parquet को S3 पर लिखते समय pl.LazyFrame.sink_parquet तथा pl.DataFrame.write_parquet दोनों अपेक्षित रूप से काम करते हैं।

यदि आप v1.33 से पहले के संस्करण पर हैं, तो ऊपर दिए स्निपेट से यह व्यवहार पुनः उत्पन्न हो सकता है। v1.33 और उससे ऊपर पर, वही कॉल पाथ इच्छित रूप से काम करता है। उदाहरण के लिए:

aws_sess = ...  # boto3 सत्र
creds = aws_sess.get_credentials()
io_opts = {
    "aws_access_key_id": creds.access_key,
    "aws_secret_access_key": creds.secret_key,
    "aws_session_token": creds.token,
    "aws_region": "eu-west-1",
}
s3_uri = f"s3://{bucket_name}/{prefix_path}"
# polars DataFrame इंस्टेंस
tbl.write_parquet(
    s3_uri,
    partition_by=part_cols,
    storage_options=io_opts,
    use_pyarrow=True  # v1.33+ पर अपेक्षित रूप से व्यवहार करता है
)

यह क्यों मायने रखता है

पार्टिशन किए गए डेटा लेक्स, लिखते समय शुद्धता और संगति की गारंटी के प्रति संवेदनशील होते हैं। लोकल स्टेजिंग के दौरान फाइलों का पीछे रह जाना डिस्क स्पेस बर्बाद करता है और संचालन को जटिल बनाता है। S3 पर असफल multipart अपलोड पाइपलाइनों को रोक देते हैं और मॉनिटरिंग में अस्पष्टता पैदा करते हैं। यह जानना कि यह व्यवहार polars के खास संस्करणों से जुड़ा था, लक्षणों की पहचान तेज़ी से करने और अनावश्यक वर्कअराउंड हटाने में मदद करता है।

व्यावहारिक निष्कर्ष

यदि S3 पर partitioned Parquet लिखते समय आपको स्थानीय स्टेजिंग की बची हुई फाइलें दिख रही हैं या ACCESS_DENIED वाली multipart त्रुटि मिल रही है, तो अपना polars संस्करण जाँचें। v1.33 या उससे नए संस्करण में अपग्रेड करने से यह समस्या eager write path और lazy sink path—दोनों के लिए सुलझ जाती है। पृष्ठभूमि और ऐतिहासिक संदर्भ के लिए polars#23114 और polars#23221 की सार्वजनिक थ्रेड्स देखें।

संक्षेप में, v1.33+ में ठीक किए गए व्यवहार पर भरोसा करें और अपने डेटा-लिखने वाले कोड को storage_options और पार्टिशनिंग के बारे में सरल और स्पष्ट रखें। इससे आपके S3 वर्कलोड पूर्वानुमेय रहते हैं और रखरखाव का बोझ घटता है।