Iceberg table format, एक अच्छा विचार - गलत तरीके से परिभाषित spec - Part 2 of 2

Iceberg spec की समस्याएँ

• Iceberg spec की गंभीर समस्या: Iceberg spec बड़े data lake की metadata समस्या को हल करने का कोई गंभीर प्रयास नहीं है।
• ऐतिहासिक सबक: पहले भाग में अतीत के सबक सीखने के लिए इतिहास की ओर लौटते हुए, उस "space management problem" का परिचय दिया गया था जिसे database को हल करना होता है।
  • समस्या के तत्व:
    1. space fragmentation
    2. granular concurrency control
    3. कई objects पर atomicity
    4. rows और files के बीच impedance mismatch
    5. metadata पर low-latency और high-throughput access
• open format का महत्व: हर stack में open format के उपयोग का मैं 100% समर्थन करता हूँ, और खास तौर पर structured table data के लिए Parquet को common storage format के रूप में इस्तेमाल करने को लेकर उत्साहित हूँ।
• Parquet file और database table का अंतर: सिर्फ Parquet files का एक समूह होने से वह database table नहीं बन जाता। Database table सिर्फ rows का एक साधारण collection नहीं है।

metadata समस्या का सार

• space management problem: database को जिन कई समस्याओं को हल करना होता है, उन पर फिर से ज़ोर दिया गया है।
• metadata की ज़रूरत: कई Parquet files को database table जैसा दिखाने के लिए निम्न metadata चाहिए:
  1. table बनाने वाली सभी files की location list
  2. हर file के लिए rough metadata
  3. files को जोड़ने या हटाने के लिए transactional control mechanism
  4. table schema को evolve करने का तरीका
• file location ढूँढना: Parquet files के एक सेट को single table की तरह treat करने के लिए files को ढूँढने का mechanism चाहिए।
• metadata का महत्व: हर file को दिलचस्प rows को जल्दी ढूँढने के लिए अतिरिक्त metadata चाहिए।

Parquet file और database table

• Parquet file की परिभाषा: Parquet एक self-describing, tabular data format देता है।
• database table की परिभाषा: database table सिर्फ rows का समूह नहीं है; इसके लिए कई तरह के metadata और transactional control की ज़रूरत होती है।
• Parquet file को table की तरह इस्तेमाल करने की शर्तें:
  1. file location list
  2. हर file का metadata
  3. file add और remove करने के लिए transactional control mechanism
  4. table schema evolution का तरीका
• file और table का अंतर: सिर्फ इसलिए कि Parquet files का column layout एक जैसा है, वे database table जैसी नहीं दिखने लगतीं।

manifest file और list

• data add करने की प्रक्रिया: Iceberg client को table में data जोड़ने के लिए ये steps पूरे करने होते हैं:
  1. एक या अधिक Parquet files को किसी location (जैसे S3) पर लिखना।
  2. step 1 में लिखी गई files की ओर इशारा करने वाली manifest file लिखना।
  3. नई manifest list लिखना।
• manifest file का format: manifest files और lists AVRO format में होती हैं, जो compressed और self-describing है।
• manifest file की सामग्री: manifest file में Parquet files के pointers और हर column का metadata शामिल होता है।
• metadata size की समस्या: metadata को इस तरह store करने से वह ज़रूरत से ज़्यादा बड़ा हो जाता है, और files के बीच common string values को पहचानकर compress नहीं किया जा सकता।

client पर बढ़ता बोझ

• client की जिम्मेदारी: पूरे Iceberg spec में client को साधारण बदलावों के लिए भी भारी मात्रा में bookkeeping करनी पड़ती है।
• metadata की शुद्धता की समस्या: अगर client कुछ हिस्सा गलत लिख दे, तो नए snapshot का commit करते समय कड़ी जाँच करनी होगी और यह verify करना होगा कि manifest data सही लिखा गया है।
• security समस्या: क्योंकि client को सभी manifest files की ओर इशारा करने वाली manifest list लिखनी होती है, इसलिए सभी S3 files की locations उजागर हो जाती हैं।
• data security का महत्व: data की कीमत इतनी अधिक है कि यह पूछना चाहिए कि spec security को सर्वोच्च प्राथमिकता क्यों नहीं देता।

row security की खामियाँ

• row security की आवश्यकता: अमेरिका जैसे अपेक्षाकृत ढीले regulation वाले देशों में भी sensitive data की रक्षा के लिए row-level security ज़रूरी है।
• EU का GDPR: यूरोप में GDPR जैसे कानूनों के कारण data access को लेकर और भी अधिक संवेदनशील होना पड़ता है।
• client की data access समस्या: client table में data जोड़ सकता है, लेकिन पहले से मौजूद data तक पहुँच को सीमित नहीं कर सकता।
• security समस्या की गंभीरता: spec का security को प्राथमिकता न देना, data lake की जानकारी के मूल्य पर गंभीर सवाल खड़ा करता है।

metadata file की भूमिका

• metadata file लिखना: client Parquet files लिखने के बाद संबंधित manifest file बनाता है, फिर मौजूदा manifest list पढ़ता है, नई manifest list बनाता है, और उसके बाद data commit करता है।
• commit प्रक्रिया: commit, metadata file (<prefix>.metadata.json) लिखकर किया जाता है।
• JSON format का चयन: metadata file के JSON format में होने का कारण स्पष्ट नहीं है, और यह "committee द्वारा design" जैसा महसूस होता है।
• metadata की पुनरावृत्ति: metadata file सभी snapshots को सूचीबद्ध करती है, जिससे जानकारी दोहराई जाती है और space की बर्बादी होती है।

commit प्रक्रिया की जटिलता

• atomicity समस्या: नई metadata file को latest file बनाना और उसे पिछली metadata file से atomically replace करना ज़रूरी है।
• commit procedure की जटिलता: नया metadata version V+1 commit करने के लिए ये steps लेने होते हैं:
  1. मौजूदा metadata के आधार पर नई table metadata file बनाना।
  2. नई table metadata को एक unique file में लिखना।
  3. metastore से request करके table के metadata pointer को V से V+1 में बदलना।
• swap failure की स्थिति: अगर swap fail हो जाए, तो इसका मतलब है कि कोई दूसरा writer पहले ही V+1 बना चुका है, इसलिए client को फिर से step 1 पर लौटना पड़ता है।
• race condition की समस्या: जब clients में प्रतिस्पर्धा होती है, तो client को पहले वाले client द्वारा लिखी गई metadata file फिर से पढ़नी पड़ती है और manifest list व metadata file दोबारा बनानी पड़ती है।

optimistic concurrency control की समस्याएँ

• concurrency का तथ्य: अगर resource पर contention की उम्मीद नहीं है, तो कौन-सा concurrency model इस्तेमाल किया जाता है, इससे बहुत फर्क नहीं पड़ता।
• जब contention अपेक्षित हो: अगर दो clients एक ही value बदलना चाहते हैं, तो locking mechanism का इस्तेमाल करना चाहिए।
• optimistic concurrency control की सीमा: Iceberg में दो concurrent writes हमेशा टकराएँगी, और इसकी वजह spec का design है।
• सबसे खराब locking semantics: metadata पर सबसे खराब locking semantics लागू की गई है, जबकि अगर सिर्फ data add करना हो, तो clients के बीच coordination की ज़रूरत नहीं होनी चाहिए।

metadata swap की सीमाएँ

• metadata का केंद्रीकरण: table के metadata को एक single file में centralize करके हर write के लिए एक single contention point बना दिया गया है।
• retry के समय client पर बोझ: अगर client fail हो जाए, तो उसे पहले वाले client द्वारा लिखा गया data पढ़ना पड़ता है और manifest list व metadata file फिर से बनानी पड़ती है।
• metadata swap की गति: metadata swap करने वाली service को retries के साथ काम करना पड़ता है, जिससे performance गिरती है।
• सीमित commits: simple concurrency implementation की वजह से commits की संख्या सीमित हो जाती है, और यह metadata file के atomic replacement time से बंधी रहती है।

database की आवश्यकता

• metadata file की location ढूँढना: Iceberg table snapshot पूरी तरह metadata.json file से describe होता है।
• विचार का विरोधाभास: Iceberg सिर्फ files से metadata format तय करना चाहता है, लेकिन अंततः database की ज़रूरत पड़ती है।
• database के फायदे: modern databases लाखों नहीं तो कम-से-कम सैकड़ों हज़ार writes संभाल सकते हैं और distributed तरीके से scale कर सकते हैं।
• file system और database की तुलना: metadata को files में रखने की तुलना में database में रखना अधिक efficient है।

fragmentation और metadata bloating

• metadata.json file की वृद्धि: metadata.json file latest snapshot की ओर इशारा करती है, और हर metadata file में पिछले snapshots के लिए backward pointers होते हैं।
• metadata की लगातार वृद्धि: metadata लगातार बढ़ता रहता है, जिससे data lake की performance पर नकारात्मक असर पड़ता है।
• नियमित metadata cleanup की ज़रूरत: अगर data lake में लगातार data जोड़ा जा रहा है, तो metadata को साफ़ करना ज़रूरी है।
• HTTP request की लागत: metadata files delete करने की प्रक्रिया में HTTP requests लगते हैं, जिनकी लागत हो सकती है।

data पढ़ना और query planning

• manifest file की भूमिका: manifest files में Parquet files के बारे में metadata होता है।
• query planning की जटिलता: query चलाने के लिए manifest list और manifest files को क्रम से पढ़ना पड़ता है।
• cost की समस्या: S3 से read cost लगती है, जो query execution speed को प्रभावित करती है।
• metadata fragmentation की समस्या: metadata के fragment हो जाने पर query planning जटिल हो जाती है और data access मुश्किल हो जाता है।

caching और query planning की कठिनाइयाँ

• manifest caching: manifest को cache किया जा सकता है, लेकिन metadata का आकार बढ़ने के कारण यह अप्रभावी हो जाता है।
• cache validity बनाए रखना: यह सुनिश्चित करना पड़ता है कि cache up-to-date है, जिससे अतिरिक्त cost और complexity बढ़ती है।
• client पर बोझ: सभी clients को metadata cache करना पड़ता है, जिससे लाखों HTTP requests पैदा होती हैं।
• complexity में वृद्धि: data lake का उपयोग अधिक जटिल हो जाता है, और इसे हल करने के लिए अतिरिक्त solutions की ज़रूरत पड़ती है।

विचार का निष्कर्ष

• विचार की आलोचना: Iceberg spec, data lake metadata के लिए कोई गंभीर spec नहीं है और इसमें कई समस्याएँ हैं।
• समस्याओं का सार: Iceberg metadata जोड़ने के लिए O(n) operations का उपयोग करता है, cross-table commits को handle नहीं कर पाता, और metadata bloating की समस्या हल नहीं करता।
• scaling की सीमाएँ: Iceberg scaling के लिए उपयुक्त नहीं है और अत्यधिक complexity client पर डाल देता है।
• industry के लिए सवाल: यह सवाल उठाया गया है कि IT industry में ऐसी समस्याएँ पैदा ही क्यों होती हैं।