Parquet, Iceberg और डेटा लेकहाउस को समझना

 (davidgomes.com)
6 पॉइंट द्वारा GN⁺ 2023-12-31 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • डेटा स्टोरेज तकनीक कोई एक ही चीज़ नहीं है; यह फाइल फॉर्मैट, मेमोरी फॉर्मैट, टेबल मेटाडेटा लेयर और लेकहाउस आर्किटेक्चर जैसी अलग-अलग परतों में बंटी होती है
  • Avro·Parquet·ORC·Arrow ऐसे फॉर्मैट हैं जो डेटा का बाइनरी लेआउट तय करते हैं; Parquet कॉलम-आधारित compression और analytics processing में मजबूत है, जबकि Avro row-level processing के लिए ज्यादा उपयुक्त है
  • Iceberg और Delta Lake फाइल फॉर्मैट नहीं हैं, बल्कि Parquet जैसी files के ऊपर बड़े पैमाने पर table management संभव बनाने वाली ऊपरी metadata layer हैं
  • डेटा लेकहाउस, S3 जैसे storage में रखी raw files के ऊपर SQL queries, batch jobs और governance जैसी warehouse capabilities जोड़ने का तरीका है
  • Snowflake और BigQuery जैसे warehouses भी Iceberg जैसे open formats को support कर रहे हैं, जिससे data warehouse और lakehouse के बीच की सीमाएं धीरे-धीरे धुंधली हो रही हैं

फाइल फॉर्मैट और मेमोरी फॉर्मैट का फर्क

  • डेटा storage और access को efficient बनाने वाले open source formats की storage approach और उपयोग की जगह अलग-अलग होती है
    • Apache Avro: binary, rowstore, file
    • Apache Parquet: binary, columnstore, file
    • Apache ORC: binary, columnstore, file
    • Apache Arrow: binary, columnstore, memory
    • Protocol Buffers: language-neutral data structure definition language है, और implementation के हिसाब से rowstore या columnstore अलग हो सकता है
    • CSV: text-based है और इसकी structure बहुत सरल है
  • Apache Arrow dataframe को disk file के रूप में save करते समय आम तौर पर Feather इस्तेमाल होता है, और इसे Parquet जैसे दूसरे formats में भी convert किया जा सकता है
  • Snowflake, Redshift, Athena, Hive जैसे systems open formats और closed storage formats को पढ़ना-लिखना support करते हैं, लेकिन open format support का दायरा product के हिसाब से अलग हो सकता है

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

  • फाइल फॉर्मैट एक specification है जो तय करता है कि डेटा असल binary placement में कैसे arranged होगा
  • Parquet compression में मजबूत है, और Avro rowstore approach के कारण किसी खास row block को पढ़ने के लिए ज्यादा उपयुक्त है
  • Parquet और Avro दोनों schema evolution support करते हैं, जिससे पुराने डेटा को पूरा rewrite किए बिना नए डेटा की schema बदली जा सकती है
  • दोनों formats file splitting support करते हैं, जो parallel data processing के लिए अहम है
  • Apache Parquet repository में actual file format specification और Java reference implementation शामिल हैं
  • Parquet को कई languages और tools में read/write किया जा सकता है, और Pandas में भी DataFrame को to_parquet से local Parquet file में save किया जा सकता है
  • Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena, Apache Drill ऐसे engines के उदाहरण हैं जो Parquet files संभाल सकते हैं

बड़े पैमाने के data management के लिए सिर्फ file format पर्याप्त नहीं

  • अलग-अलग फाइल फॉर्मैट केवल एक file layout define करते हैं, इसलिए लगातार बदलते बड़े datasets को manage करने के लिए वे पर्याप्त नहीं हैं
  • बहुत सारी tables store करने, individual table schema evolution, point-in-time queries, efficient partitioning, external tools द्वारा schema पढ़ने, और cost-based query optimization के लिए statistics store करने में ऊपर की layer चाहिए
  • इस layer में table format और schema registry या metastore शामिल होते हैं
  • Confluent Schema Registry Avro और Protobuf support करती है, और rowstore tendency वाले streaming data के लिए ज्यादा उपयुक्त है

Hive, Iceberg और Delta Lake की जगह

  • Facebook ने 2009 में अपने table metadata format के साथ Hive को open किया था, और बाद में Hive ने कई formats support करना शुरू किया
  • Netflix ने Hive की performance और scalability limitations से आगे जाने के लिए Iceberg develop किया
  • Databricks ने Iceberg के alternative Delta Lake को develop किया और बाद में open source के रूप में release किया
  • Iceberg और Delta Lake दोनों individual file format के तौर पर Parquet का उपयोग करते हैं
  • Hive, Delta Lake, Iceberg सभी schema registry या metastore के equivalent concepts support करते हैं
    • Hive का HMS(Hive MetaStore) असल में लगभग कोई भी RDBMS इस्तेमाल कर सकता है
    • Iceberg में Iceberg Catalogs हैं
    • Databricks में Unity Catalog है
  • ऐसे catalogs और metastores यह manage करने वाली data governance में भी उपयोग हो सकते हैं कि कौन-सी team या user किन tables को access कर सकता है

Iceberg और Delta Lake की भूमिकाएं

  • Delta Lake और Iceberg query engine या storage engine खुद नहीं हैं, बल्कि वे open specifications हैं जो query engines को काम करने में सक्षम बनाते हैं
  • दोनों वही problems अलग-अलग तरीकों से solve करते हैं, और Delta Lake में Iceberg की तुलना में contributors की diversity कम होने के कारण openness को लेकर debate है
  • Redshift, BigQuery, Snowflake, Athena, Dremio आदि कई data warehouses और lakehouses में Iceberg support तेजी से बढ़ रहा है
  • Iceberg और Delta Lake बड़े पैमाने पर table operations के लिए जरूरी capabilities देते हैं
    • partitioning
    • schema evolution
    • data compression
    • schema changes के लिए ACID transactions
    • column pruning, predicate pushdown और statistics collection के जरिए efficient query optimization
    • point-in-time queries के लिए time travel
  • Iceberg partition evolution support करता है, जिससे पुराने डेटा को पूरा rewrite किए बिना table की partitioning method या shard key बदली जा सकती है
  • Netflix में partitioning changes एक बड़ी परेशानी थे, और Iceberg बनाने की वजहों में से एक यही था

Closed formats और Iceberg support का दबाव

  • Iceberg specification कई systems द्वारा support किए जाने वाले format के रूप में तेजी से लोकप्रिय हो रहा है
  • closed formats इस्तेमाल करने वाले products पर अपने formats में जितनी हो सके उतनी high performance देने के साथ-साथ Iceberg या Delta Lake को किसी न किसी रूप में support करने का दबाव है
  • Iceberg एक ऐसा checkbox feature बन सकता है जिसे हर database system को कभी न कभी support करना होगा
  • performance reasons की वजह से Iceberg शायद closed data formats को पूरी तरह replace न कर पाए
  • अगर data format केवल एक query engine के लिए develop किया जाए, तो database developers maximum efficiency निकाल सकते हैं और ज्यादा तेजी से innovate कर सकते हैं

डेटा लेक और डेटा लेकहाउस

  • डेटा लेक वह जगह है जहां company भारी मात्रा में data को Parquet, CSV जैसी raw files के रूप में store करती है
  • डेटा warehouse data को schema वाली SQL tables और database schemas जैसे ज्यादा structured तरीके से store करता है
  • डेटा lakehouse डेटा lake में SQL queries चलाने, batch jobs, और data governance configuration जैसी capabilities जोड़ने वाला रूप है
  • Iceberg, query engine और दूसरे additional components को साथ इस्तेमाल करके data lake के ऊपर data lakehouse बनाया जा सकता है
  • पहले इन capabilities के लिए data warehouse या ज्यादा traditional DBMS अपनाना पड़ता था
  • डेटा lakehouse HDFS या S3 जैसे cloud Blob Store को सारे data की storage location के रूप में इस्तेमाल करता है, और query engines को उस storage पर तेजी से काम करने के लिए optimize करता है
  • Databricks और Dremio data lakehouse products के उदाहरण हैं
  • Snowflake और BigQuery जैसे warehouses जब Iceberg जैसे open data formats जोड़ रहे हैं, तो data warehouse और data lakehouse का distinction और ज्यादा अस्पष्ट हो रहा है

संबंधित पढ़ाई

2 टिप्पणियां

 
happing94 2024-01-03

मैं Iceberg और Delta Lake की तुलना देख रहा था, और इसे इस तरह काफ़ी साफ़-सुथरे तरीके से व्यवस्थित किया गया है।
मेरी जो राय और नज़रिया था, उससे यह लगभग पूरी तरह मेल खाता है।
ऑनलाइन किया गया benchmark Spark का उपयोग करके था, और Tabular के Head DevRel ने लिखा है कि benchmark देखने लायक तो है, लेकिन उसका बहुत बड़ा मतलब नहीं है।
open source के रूप में चुनना हो तो iceberg ही एकमात्र विकल्प लगता है।
सारांश अच्छा है, लेकिन जिन लिंक का संदर्भ लिया गया है वे भी होते तो अच्छा रहता
 
GN⁺ 2023-12-31
Hacker News की राय

  • Apache Iceberg और Delta Lake, दोनों को अक्सर खुले table format (Open Table Format) के रूप में एक साथ रखा जाता है, लेकिन असल में ये काफ़ी अलग दिखते हैं
    Iceberg का spec https://iceberg.apache.org/spec/ पर है, और जिसे database systems की समझ हो, वह इसे देखकर बिना बहुत कठिनाई के Iceberg tables बनाने और query करने वाला implementation कर सकता है
    दूसरी ओर Delta Lake की तरफ़ https://github.com/delta-io/delta/blob/master/PROTOCOL.md है, लेकिन मौजूदा spec को पूरी तरह implement करने के लिए कितने काम की ज़रूरत होगी, इसका भी अंदाज़ा लगाना मुश्किल है, और लगातार बदलते इस विशाल spec के साथ बने रहना तो और भी कठिन लगता है
    सच कहूँ तो Delta Lake spec ऐसा दस्तावेज़ लगता है मानो Databricks ने Hadoop से परेशान Fortune 1000 कंपनियों के लिए lakehouse जल्दी खड़ा करते समय जो implementation-level समझौते किए, उन्हीं का reverse-engineering किया गया हो
    अभी तक मैं आश्वस्त नहीं हूँ कि Delta Lake अपनाना वाकई open ecosystem में प्रवेश करना है, और इस बारे में भरोसा दिलाने वाला कोई ठोस आधार मिले तो अच्छा होगा
    ऊपर से GitHub history भी भरोसा नहीं जगाती: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
    ऐसा लगता है जैसे मनमाने features और fixes Databricks engineers के PR के रूप में आते हैं, और Databricks के senior engineers उन्हें तुरंत approve कर देते हैं

    • पूरी तरह सहमत। Databricks का Bloom filter जैसी features को open source Delta से जानबूझकर बाहर रखना उनका अधिकार है
      लेकिन फिर इसे community-led open format कहना ठीक नहीं है। हाँ, अगर Animal Farm वाले अंदाज़ में कहा जाए कि “कुछ लोग ज़्यादा बराबर हैं”, तो बात अलग है
    • मैंने Microsoft Fabric के एक component में शुरू से Delta support implement करके देखा है, और अतिरिक्त Spark implementations के साथ प्रयोग किए बिना सिर्फ़ “spec” के आधार पर काम करना काफ़ी अधूरा लगा
      computed columns या check constraints जैसी features इस्तेमाल करनी हों, तो Spark SQL expressions का support भी चाहिए, और उस हिस्से की documentation तो और भी कमज़ोर है
    • मुझे भी यही एहसास हुआ। Databricks जो कुछ भी देता है, उसके प्रति मैं बहुत ज़्यादा सावधान रहता हूँ
      वह नाम भर का open source लगता है, और उस पर भरोसा नहीं करना चाहिए
      मैंने Delta Lake इस्तेमाल किया है, और वास्तविक उपयोग में इसकी सीमाएँ और परेशान करने वाले sharp edges बहुत थे। आख़िरकार हमने वह project पूरी तरह छोड़ दिया, और उस समय Iceberg भी देखा था
      Iceberg और Hudi में features का ढाँचा ज़्यादा सुसंगत तरीके से डिज़ाइन किया हुआ लगा, लेकिन उन्हें support कम मिल रहा था; उम्मीद है आगे यह स्थिति बेहतर होगी
    • मैं 1-2 साल से इस क्षेत्र को देख रहा था और सोचता था कि open source में Iceberg ज़्यादा लोकप्रिय क्यों है; यह व्याख्या मददगार है
      पिछले 6 महीनों में मुझे लगा कि Iceberg, JVM ecosystem के बाहर के users के लिए tools देने में संघर्ष कर रहा है, जबकि Delta आगे निकलता दिखा। उस मायने में Delta काफ़ी ज़्यादा approachable है
    • Delta changes के लिए JSON का इस्तेमाल करना सच में मूर्खता है
      तुलना करें तो SQL Server में यह कहीं बेहतर तरीके से implement किया गया है। columnar storage tables (columnstore indexes, जो engine के अंदर Parquet/ORC के समकक्ष हैं) immutable होते हैं, और delta को compressibility, accessibility और speed के लिए B-Tree में रखा जाता है
      किसी बिंदु पर column store को आंशिक या पूर्ण रूप से defragment, merge या rebuild किया जाता है, और B-Tree को delete कर दिया जाता है, फिर नए changes जमा होने लगते हैं और चक्र दोबारा शुरू होता है
      यह सब JSON में करना, नरम शब्दों में कहें तो, बुरे समय का संकेत है
      Delta Lake से तो कुछ भी बेहतर लगेगा, और खासकर Iceberg ज़्यादा बेहतर दिखता है

  • बढ़िया लेख है। मैं S3 पर Parquet files के साथ कई सालों से काम कर रहा हूँ, लेकिन Iceberg वास्तव में क्या है, यह ठीक से नहीं जानता था; लेख ने इसे अच्छी तरह समझाया
    Iceberg एक database metadata format है, जो underlying dataset के schema और partitioning वगैरह का वर्णन करता है
    ज़्यादातर लोग /key3=000/key2=002/ जैसी Hive partitioning convention इस्तेमाल करते हैं, लेकिन Iceberg इस मायने में बेहतर है कि यह query engine के सामने ज़्यादा structure उजागर करता है
    Postgres जैसे पारंपरिक DBMS में schema, query engine और storage format एक ही package में मिलते हैं
    लेकिन big data में database के components को शुरू से जोड़ना पड़ता है, और उन्हें आपस में मिलाकर इस्तेमाल किया जा सकता है। आप Iceberg को metadata format, DuckDB को query engine, Parquet को storage format और S3 को storage medium के रूप में इस्तेमाल कर सकते हैं

  • डेटाबेस की दुनिया में यह एक बड़ा बदलाव है। Delta, Iceberg और Hudi की वजह से डेटा आम तौर पर S3 पर open source formats में स्टोर होने लगा है
    अगर storage और processing का बड़ा हिस्सा standardize हो जाए, तो databases के बीच data move करना आसान हो जाता है, और लगभग हर tool आखिरकार एक ही files के set को transactionally safe तरीके से handle कर सकता है
    उदाहरण के लिए, जब Snowflake files में लिख रहा हो, तब data scientist Jupyter notebook में real time में query कर सकता है, और ClickHouse उसी data पर consistency guarantees बनाए रखते हुए user-facing analytics दे सकता है
    बाद में अगर कोई company Snowflake से Databricks पर जाने का फैसला करे, तो वह भी इतना बड़ा काम नहीं रह जाएगा
    अभी S3 पर इन formats को query करने की speed native ingest जितनी तेज़ नहीं है, लेकिन market pressure की वजह से हर database vendor को performance optimize करनी पड़ेगी, और अंततः यह native ingested data performance के काफ़ी करीब पहुँच जाएगा
    openness, open source, और इस बात के लिहाज़ से कि companies अपना data open और portable formats में रख सकें, यह एक बड़ी जीत है
    lakehouse का मतलब भी यही है। बहुत-सी companies के पास data lake और data warehouse दोनों होते हैं, और फिर वे दोनों के बीच data copy करती रहती हैं
    अगर query और management के लिए एक ही system रखा जाए जो उसी dataset को संभाले, तो उसका असर भी काफ़ी बड़ा होता है
    data engineering में होने के नाते यह बहुत दिलचस्प समय है

    • Apache Arrow और Substrait इसी वास्तविकता को बनाने के लिए काम कर रहे हैं
      आगे एक ऐसा भविष्य दिखता है जहाँ query execution के समय execution plans को cloud भर के कई engines के साथ-साथ local machine पर भी भेजा जा सकेगा
    • यह मान लेना कि सभी database vendors अपने internal storage formats छोड़ देंगे और सिर्फ compute layer पर compete करेंगे, उनके दशकों से बने engineering infrastructure और business model को नज़रअंदाज़ करना है
      Snowflake के लिए तो शायद business बंद करके investors को अरबों डॉलर लौटाना ही बेहतर हो। data को अपने ecosystem से बाँधकर रखना ही उनका पूरा business model है
      जानना चाहूँगा कि क्या कोई अच्छा उदाहरण है जहाँ open standards ने companies को proprietary technology छोड़ने पर मजबूर किया हो

  • “Apache Arrow dataframes को disk files के रूप में स्टोर करने का सबसे अच्छा तरीका Feather है, और उन्हें Apache Parquet वगैरह में convert भी किया जा सकता है” — इस बात से मैं बिल्कुल सहमत नहीं हूँ
    अगर JVM के बिना सीधे lakehouse बनाना हो, तो Iceberg को metadata, Parquet को data, DuckDB को query engine, और Arrow tables के रूप में query करने वाला setup सबसे बेहतर है
    Parquet को सीधे Arrow में पढ़ने की लागत बहुत कम है, और उसके बाद Arrow → Pandas या Polars में भेजा जा सकता है। सीधे भेजें या Arrow Flight आधारित service के ज़रिए भेजें, दोनों चलेंगे
    इसमें Feather जोड़ने पर मौजूदा Python lakehouse stack ठीक से काम नहीं करता

    • एक समय मुझे लगता था कि Feather में long-term format guarantee नहीं है
      अब शायद यह बदल गया हो, लेकिन फिर भी Parquet मुझे सबसे future-proof विकल्प लगता है

  • data lake के बारे में सुना है, लेकिन “data lakehouse” सुनने में ऐसा लगता है जैसे अमीर data लोग गर्मियों में data boat लेकर data fishing करने जाते हों

    • नाम का मज़ाक उड़ाना आसान है, लेकिन असली समस्या सही है
      बहुत-सी companies अपना data data lake में स्टोर करती हैं, और Tableau या PowerBI जैसे tools में BI देने के लिए warehouse इस्तेमाल करती हैं। फिर वे दोनों के बीच data copy करने लगती हैं
      data lakehouse, जो सीधे lake को query करते हुए transactions और governance को एक ही dataset पर लागू करता है, stack को काफ़ी सरल बना सकता है और cost भी घटा सकता है
    • सच कहूँ तो “data lake” का मतलब “विभिन्न तरह की बड़ी data files का संग्रह” के अलावा और क्या है, यह मैंने कभी ठीक से समझा ही नहीं
    • naming करना मुश्किल है, और उम्मीद है कि industry कभी इससे बेहतर नाम ले आए
      हर बार सुनने या पढ़ने पर यह दिमाग़ में काफ़ी अटपटा लगता है

  • Iceberg को लेकर मैं खास तौर पर उत्साहित हूँ, क्योंकि यह open source है
    लेकिन जब मैंने आख़िरी बार देखा था, तब implementation सिर्फ Spark library तक सीमित था, और Trino (पहले Presto, SQL engine) का Iceberg connector Hive पर काफ़ी निर्भर था
    ऐसा लगता था कि पूरी industry को MapReduce, Hive, और कहूँ तो Spark की legacy से अलग होना मुश्किल पड़ रहा है
    उसके बाद मैंने Iceberg को फिर नहीं देखा, लेकिन जल्द ही देखने का इरादा है, और सच में उम्मीद है कि यह क्षेत्र आगे बढ़े
    अब हमारे पास legacy tech के बिना भी data संभालने के tools और compute power है, और हर data big data भी नहीं होता
    इसलिए अच्छी बात यह है कि data engineering धीरे-धीरे सामान्य backend development जैसी होती जा रही है, और आम development practices भी जगह बना रही हैं
    उम्मीद है कि बहुत निकट भविष्य में एक शुद्ध Python Iceberg library आएगी

    • Trino अब किसी भी data lake connector में Hadoop/Hive पर निर्भर नहीं है
      उस dependency को हटाने में बहुत बड़ी मेहनत लगी है
    • मेरा अनुभव भी कुछ ऐसा ही था। पुराने stack के साथ सिर्फ data insert करने लायक setup बनाने की कोशिश में मैंने अपने फुर्सत के करीब एक महीने खर्च कर दिए, लेकिन नतीजा संतोषजनक नहीं रहा
      Databend को मैंने एक घंटे में चला लिया, और मुझे लगा कि अगर Rust implementation आ जाए, तो Java/Hive की तुलना में portability बेहतर होगी, जिससे आगे इसे ठीक से इस्तेमाल करना आसान हो जाएगा

  • समझ नहीं आता कि वे यह सब और ठोस तरीके से क्यों नहीं समझाते
    वे यह बता सकते हैं कि data को कैसे store किया जाता है, कैसे connect करके query किया जाता है, और query कितनी तेज़ चलती है। जैसे transaction speed और analytical query speed के बीच का अंतर

  • अभी हम GCP पर लगभग 100TB डेटा संभाल रहे हैं, BigQuery को query engine के रूप में इस्तेमाल कर रहे हैं, और /key3=000/key2=002/ जैसी सरल Hive partitioning उपयोग कर रहे हैं
    हम अपनी सभी इच्छित queries चला पा रहे हैं और लागत भी बेहद कम है, इसलिए हम संतुष्ट हैं
    लेकिन latency काफ़ी बढ़ रही है, हालांकि यह हमारे लिए बहुत महत्वपूर्ण नहीं है। फिर भी जानना चाहता हूँ कि क्या Iceberg अपनाने से इस हिस्से में सुधार होगा
    जानना चाहता हूँ कि किसी और को ऐसा अनुभव हुआ है या नहीं, और कुल मिलाकर इस तरह की architecture वास्तव में शानदार है

    • इस विषय पर एक अच्छा summary है: https://aws.amazon.com/blogs/big-data/choosing-an-open-table... का “Optimizing read performance” भाग
      ऐसी technologies का मुख्य उद्देश्य बड़े पैमाने पर डेटा प्रबंधन है, लेकिन ये Parquet जैसे raw storage formats द्वारा दी जाने वाली capabilities को भी बढ़ाती हैं। इसलिए मदद मिल सकती है, लेकिन वास्तव में इसकी ज़रूरत है या नहीं, यह परखना होगा
      मैंने BigQuery इस्तेमाल नहीं किया है, लेकिन similar features हो सकती हैं
      पहले यह परिभाषित करना होगा कि यहाँ “latency” से क्या मतलब है, और “काफ़ी ज़्यादा” किस स्तर को कहा जा रहा है
      analytics data stores को efficient batch processing के लिए डिज़ाइन किया गया है, और किसी single record को ढूँढना इस architecture का मुख्य लक्ष्य नहीं है। तेज़ lookups के लिए caching या indexing चाहिए
      कुछ मामलों में single-record lookup में सिर्फ limit 1 जोड़ने भर से भी समाधान हो सकता है
      यह सुनिश्चित करना चाहिए कि आप Parquet जैसे efficient data storage format का उपयोग कर रहे हैं, और file sizes की जाँच करनी चाहिए कि कहीं "small file problem" तो नहीं है
      उसके बाद यह भी देखना चाहिए कि क्या आप संबंधित BigQuery features का उपयोग कर रहे हैं। इन जाँचों से पहले और बाद में query पर explain चलाकर देखना चाहिए, और यदि आप partition key या index columns का उपयोग नहीं कर रहे, तो किसी भी big data system में search result तुरंत नहीं आएगा
    • हमारा scale आपके लगभग 1/10 के बराबर है, लेकिन data visualization में ग्राहक स्वाभाविक रूप से अधीर होते हैं, इसलिए query speed हमारे लिए बहुत महत्वपूर्ण है
      यदि आप BigQuery tables को high-throughput computation के input के रूप में इस्तेमाल नहीं कर रहे हैं, तो मैं BI tools को optimize करने या end-user latency से बचने के लिए analytics tables बनाने पर ध्यान दूँगा
      उदाहरण के लिए, हाल ही में हमने fact/dimension table joins और COALESCE operations को materialize करके analytics के लिए एक बड़ी dedicated table बनाई
      conceptually यह सामान्य data warehouse configuration के “बाहर” है, लेकिन चूँकि यह dbt के भीतर मौजूद है, इसलिए हम data quality और lineage बनाए रख सके
      इससे Tableau fixed calculations हटाने में मदद मिली और end users के load/grouping time में लगभग 95% की कमी आई
    • यदि आप BigQuery native storage का उपयोग कर रहे हैं, तो Iceberg queries को तेज़ नहीं करेगा
      GCS/S3 पर federated queries के मामले में यह तेज़ हो सकता है
    • अगर AWS पर जाना आपके लिए ठीक है, तो यह काफ़ी अच्छा लगता है: https://www.boilingdata.com/

  • “यह लेख 100% comprehensive भी नहीं है, और ज़्यादातर लोगों के लिए सबसे अच्छा starting point भी नहीं होगा। क्योंकि यह लेख मैं अपने लिए लिख रहा हूँ। मुझे लगता है कि कुछ नया सीखने का सबसे अच्छा तरीका है खुद को उसे किसी और को दोबारा समझाने के लिए मजबूर करना” — यह रवैया मुझे सच में बहुत पसंद आया
    मैंने भी कागज़ और अपनी वेबसाइट के notes में यह तरीका अपनाना शुरू किया है

  • अधिक managed Parquet storage के Iceberg युग में गहराई से जाने को लेकर मेरी काफ़ी उम्मीदें थीं
    लेकिन अभी भी fast GPU I/O (GPUDirect/cuFile) support कई साल पीछे है
    इसलिए जब भी मैं इसे AI workloads के लिए ग्राहकों के पास ले जाना चाहता हूँ, हर बार उसी दीवार से टकराता हूँ
    अंततः यह संभव होता दिखता है, और सवाल “क्या यह संभव है” से ज़्यादा “कब” का है। जब दोनों चीज़ें साथ मिल जाएँगी, तो वह सच में शानदार होगा

    • जानना चाहता हूँ कि उपयोग का मामला क्या है। क्या यह image data storage है?
      text storage के लिए आज Parquet काफ़ी है
      PyTorch Data Loader और TF Data parallel में prefetch करते हैं, memory buffers भरते हैं, और GPU के साथ data exchange करने वाले multi-threaded clients देते हैं
      मैं सहमत हूँ कि S3 यहाँ bottleneck बन सकता है। इसलिए हमने S3 के ऊपर global distributed consistent NVMe cache के रूप में HopsFS रखा है
      Anyscale ने भी S3 के लिए local NVMe cache के साथ कुछ ऐसा ही किया है
      एक और दिलचस्प file format Lance है, जो Parquet जैसा है लेकिन image data के लिए है। इसमें file के अंदर images खोजने के लिए अतिरिक्त fast random I/O index होता है