विस्तृत विश्लेषण · लगभग 6 मिनट पढ़ना
Unity Catalog की पोर्टेबिलिटी: खुले फ़ाइल फ़ॉर्मेट के साथ कैटलॉग छोड़ने का रास्ता भी चाहिए
Databricks ने ग्राहक के स्टोरेज और Iceberg मेटाडेटा हस्तांतरण को समझाया। REGISTER और UNREGISTER अभी निजी प्रीव्यू हैं; शासन, अनुमति और लागत की सीमाएँ अलग से जाँचनी होंगी।
- यहाँ प्रकाशित
- स्रोत की तारीख
- स्रोत जाँचा गया
Elizabeth Bowman का Databricks तकनीकी लेख 19 अक्टूबर को प्रकाशित और 21 अक्टूबर को संशोधित हुआ। उसका तर्क है कि खुले टेबल फ़ॉर्मेट से ही लेकहाउस पोर्टेबल नहीं बनता। वह ग्राहक के स्टोरेज तथा मेटाडेटा के जरिये कैटलॉग बदलने की प्रक्रिया बताता है। व्यावहारिक शर्त महत्वपूर्ण है: REGISTER और UNREGISTER का उपयोग अभी Private Preview में है।
समाचार सुनें
यह लेख सुनें या समाचार लगातार चलाएँ।
पढ़ने की तैयारी हो रही है…
डिवाइस की आवाज़
वाक् प्रक्रिया आपके ब्राउज़र या डिवाइस में होती है। AISubHub पाठ किसी ऑडियो API को नहीं भेजता। आवाज़ों और लॉक स्क्रीन पर चलने की सुविधा डिवाइस पर निर्भर है।
जारी करने पर छोटा वाक्यांश दोहराया जा सकता है।
मुख्य बातें
- Databricks के अनुसार Unity Catalog की99% प्रबंधित टेबल ग्राहक के स्टोरेज में हैं। इसका आधार टेबल की संख्या है, स्वतंत्र रूप से ऑडिट किए गए ग्राहक या वर्कलोड का प्रतिशत नहीं।
- UNREGISTER नवीनतम टेबल मेटाडेटा का स्थान लौटाता है; REGISTER उसे नए कैटलॉग से जोड़ता है। बताई गई प्रक्रिया में मौजूदा डेटा फ़ाइलें अपनी जगह रहती हैं।
- लेख मौजूदा निजी प्रीव्यू को भावी SET MANAGED IN PLACE से अलग रखता है। दूसरे कैटलॉग के नियंत्रण वाली Iceberg टेबल Databricks में केवल पढ़ी जा सकती हैं।
1. खुला फ़ॉर्मेट टेबल के नियंत्रण का उत्तर नहीं देता
Databricks तीन कसौटियाँ देता है: स्टोरेज अकाउंट ग्राहक का हो, उन्नत टेबल सुविधाएँ उसी पर काम करें और डेटा कॉपी किए बिना टेबल कैटलॉग से बाहर जा सके। ये विक्रेता की कसौटियाँ हैं, कोई निष्पक्ष प्रमाणन नहीं। फिर भी वे “खुला” शब्द के पीछे छिपी परिचालन निर्भरताओं को जाँचने योग्य बनाती हैं।
यहाँ managed का अर्थ अनुकूलन, रखरखाव और अपग्रेड की जिम्मेदारी है; इसका मतलब Databricks के पास बकेट का स्वामित्व नहीं।99% का आधार Unity Catalog की प्रबंधित टेबल हैं। लेख नमूना विधि या स्वतंत्र ऑडिट नहीं देता, इसलिए इसे99% ग्राहकों द्वारा हर वर्कलोड तुरंत स्थानांतरित कर सकने का प्रमाण नहीं माना जा सकता।
2. हस्तांतरण मेटाडेटा और कमिट प्रबंधन का है
बताया गया तरीका Iceberg REST कैटलॉग की दो क्रियाएँ जोड़ता है। UNREGISTER टेबल को Unity Catalog से हटाकर नवीनतम मेटाडेटा का स्थान देता है। REGISTER नए कैटलॉग में टेबल नाम और उस मेटाडेटा को जोड़ने वाला रिकॉर्ड बनाता है। Databricks कहता है कि उसने UNREGISTER को विनिर्देश में योगदान दिया; “पहला समर्थित कैटलॉग” होना भी उसी का दावा है।
मान लें कि सहायता वार्तालापों की टेबल कंपनी के अपने बकेट में है। फ़ाइलें वहीं रखकर अगले कमिट का समन्वय करने वाला कैटलॉग बदला जा सकता है। सौंपा जाने वाला तत्व नया पॉइंटर है, सभी वार्तालापों का फिर से निर्यात नहीं। यह समझाने के लिए काल्पनिक उदाहरण है, हमारी की गई माइग्रेशन नहीं। इससे हर गंतव्य की अनुकूलता या पुरानी अनुमतियों का स्वतः हस्तांतरण सिद्ध नहीं होता।
3. अपने स्टोरेज पर भी रखरखाव और रिकवरी जरूरी हैं
लेख कहता है कि Predictive Optimization ग्राहक के स्टोरेज में प्रबंधित Delta और Iceberg टेबल पर चलता है और बिना संदर्भ वाली फ़ाइलें हटाता है। वह पुराने संस्करणों को क्वेरी करने या हटाई गई टेबल अधिकतम30 दिन तक बहाल करने का भी वर्णन करता है। “अधिकतम” विक्रेता के वर्णन की सीमा है, हर टेबल और कॉन्फ़िगरेशन के लिए30 दिन की गारंटी नहीं।
उद्धृत Zepto ग्राहक ने स्वचालित अनुकूलन से सालाना10 लाख डॉलर से ज्यादा स्टोरेज बचत बताई। यह नामित ग्राहक का अनुभव है, नई तैनाती में मापी गई बचत नहीं। हमने प्रतिस्पर्धी तुलना भी स्वतंत्र रूप से नहीं जाँची। हमारी सीमित व्याख्या है कि वास्तविक स्टोरेज पथ पर रखरखाव, रिकवरी और सफाई देखें; केवल Iceberg समर्थन से इनकी मौजूदगी न मानें। स्रोत में राशि $ के साथ दी गई है, लेकिन मुद्रा कोड नहीं बताया गया है।
4. प्रीव्यू, लिखने का नियंत्रण और योजना अलग रखें
शुरुआती निर्देश मौजूदा ग्राहकों को अपनी अकाउंट टीम से REGISTER और UNREGISTER की अनुमति लेने को कहते हैं और साफ तौर पर निजी प्रीव्यू बताते हैं। यह हर अकाउंट के लिए सामान्य उपलब्धता नहीं है। लेख में कीमत, पूरी पात्रता सूची या विस्तृत अनुमति प्रक्रिया प्रकाशित नहीं है।
रोडमैप में SET MANAGED IN PLACE के जरिये foreign या external टेबल को प्रबंधित टेबल बनाते हुए ग्राहक द्वारा निर्धारित पथ बरकरार रखने की योजना है। FAQ अलग से SET MANAGED कहता है; इससे IN PLACE के जारी हो जाने का प्रमाण नहीं मिलता। दूसरे कैटलॉग वाली Iceberg टेबल Databricks में केवल पढ़ने योग्य है क्योंकि कमिट दूसरे कैटलॉग के नियंत्रण में हैं, ताकि दो कैटलॉग एक ही टेबल न लिखें। बकेट का स्वामित्व यह समन्वय समाप्त नहीं करता।
5. निकास की जाँच में नीतियाँ और बिल भी शामिल हों
AISubHub एक प्रतिनिधि टेबल को ट्रेस करने की सलाह देता है: स्टोरेज मालिक, वर्तमान मेटाडेटा स्थान और कमिट नियंत्रण पहचानें, फिर अधिकृत पहुँच के साथ नए कैटलॉग की जिम्मेदारी लेने की क्षमता जाँचें। क्वेरी, अनुमतियाँ, डेटा वंश और रिकवरी अलग से सत्यापित हों। ये सुझाई गई जाँचें हैं; स्रोत आसपास के सभी शासन नियंत्रणों का स्वचालित हस्तांतरण नहीं दिखाता।
डेटा फ़ाइलों को कॉपी न करना कुल लागत शून्य या मुफ़्त उत्पाद होना नहीं है। कंप्यूट, स्टोरेज, नेटवर्क पहुँच और संचालन की तैनाती के अनुसार समीक्षा चाहिए। Unity Catalog को ओपन सोर्स कहना यह सिद्ध नहीं करता कि हर होस्टेड अनुकूलन, प्रीव्यू API और एकीकरण की ओपन-सोर्स कवरेज या लाइसेंस एक जैसा है। बिना शर्त “लॉक-इन नहीं” के बजाय ज्ञात शर्तों वाला परखा हुआ निकास रास्ता उपयोगी परिणाम होगा।
यह क्यों अहम है
AISubHub का विश्लेषण: इससे डेटा प्लेटफ़ॉर्म का चुनाव बाद में बदल सकने की क्षमता जाँची जा सकती है, जिसमें AI के लिए नियंत्रित डेटा भी शामिल है। निकास जाँच में फ़ॉर्मेट के साथ कमिट का नियंत्रण और पहुँच नीतियाँ भी आनी चाहिए। यह किसी मॉडल की नई क्षमता या बेहतर गुणवत्ता का प्रमाण नहीं है।
सीमाएँ और उपलब्धता
हमने कंपनी का पूरा लेख, दिखाई गई तालिका और FAQ पढ़े। API नहीं चलाई, ग्राहक की तैनाती नहीं जाँची, प्रतिस्पर्धियों की तुलना स्वतंत्र रूप से सत्यापित नहीं की और व्यावसायिक सुविधाओं की कीमत या लाइसेंस तय नहीं किए। कॉपी की जरूरत न होने का मतलब हर लागत और माइग्रेशन कार्य समाप्त होना नहीं है।
स्रोत और प्रमाण
स्रोत की तारीख: · स्रोत जाँचा गया:
AI की सहायता से लिखे लेखों को दिए गए प्राथमिक स्रोतों से जाँचा जाता है। प्रदाता के दावों का श्रेय स्पष्ट है; सूची में होना समर्थन नहीं है।