डेवलपर्स के लिए डेटा टूल्स लैंडस्केप गाइड

• डेटा क्षेत्र में नए आए software developer के लिए पूरे landscape को व्यवस्थित किया गया है, ताकि वह सिर्फ tools के नाम याद न करे, बल्कि डेटा के collection/storage/processing/usage चरणों में हर tool की भूमिका और उनके आपसी connections समझ सके
• डेटा roles मोटे तौर पर analysis/science/engineering/machine learning प्रकारों में बंटते हैं, और SQL व BI से लेकर statistical models व notebooks, pipeline infrastructure, और production model deployment तक अलग-अलग समस्याओं और tools से जुड़े होते हैं
• storage को तेज analysis और सुविधा देने वाले data warehouse, सस्ते और flexible data lake, और table format के जरिए ACID व schema management जोड़ने वाले lakehouse में बांटा जाता है
• data processing dbt जैसे SQL transformations, pandas और DuckDB की local processing, Spark की distributed batch processing, Kafka और Flink की stream processing तक फैलती है; Airflow जैसे orchestrator independent jobs के execution order और failure recovery को manage करते हैं
• processed data का उपयोग सिर्फ dashboards में नहीं, बल्कि sales/support operations, ad-hoc analysis, machine learning, product के अंदर analytics features और data sales में भी होता है; scale बढ़ने पर catalog/semantic layer/lineage/governance डेटा के अर्थ और accountability बनाए रखने की मुख्य बुनियाद बन जाते हैं

---

डेवलपर्स को कितना दायरा जानना चाहिए

• यह एक developer-oriented overview है, जिसे एक software engineer ने तैयार किया जिसने data company join की थी लेकिन संबंधित background नहीं था, ताकि tools के उपयोग और notebooks के साथ उनके interaction को समझ सके
• इसमें dashboard बनाने के तरीके, statistics की basics, Spark cluster operate करने के तरीके, या उसी category के products की deep comparison शामिल नहीं है
• यह data कहां बनता है और कैसे process, store और display होता है, इसका flow follow करते हुए हर tool के lifecycle stage को अलग करता है

डेटा roles के चार प्रकार

• वास्तविक roles की boundaries, खासकर छोटी companies या teams में, धुंधली होती हैं, लेकिन पूरे landscape को समझने के लिए इन्हें चार types में बांटा जा सकता है
• analysis type SQL और spreadsheets से data interpret करता है और insights को visualize करता है
  • Data analyst और BI analyst इसके प्रमुख उदाहरण हैं, और Tableau, Excel आदि का उपयोग करते हैं
  • उदाहरण के तौर पर customer data query करके region-wise churn rate calculate करना और Tableau dashboard व retention campaign proposal बनाना
• science type statistics, models और experiments के जरिए सतही reporting से गहरे सवालों या predictions पर काम करता है
  • Data scientist इसका प्रमुख उदाहरण है, और मुख्य रूप से Python, pandas, scikit-learn, notebooks का उपयोग करता है
  • churn factors explore कर सकता है, customer-wise churn probability model बना सकता है, फिर retention campaign के A/B test को design और analyze कर सकता है
• engineering type source data को collect, clean और standardize करके warehouse या lake में load करता है, और data tools व databases operate करता है
  • Data engineer इसका प्रमुख उदाहरण है, और Python, Apache Spark, databases, warehouses और cloud का उपयोग करता है
  • analysis results को repeatable reverse ETL pipeline में scale करना, या कई sources के transaction data को integrate करके schema, queries और quality checks manage करना इसके उदाहरण हैं
• machine learning type classification models से लेकर LLM तक AI models बनाता और operate करता है
  • यह ML scientist और ML engineer को एक category में रखता है; इसका अलग tool ecosystem बड़ा है, इसलिए मुख्य पाठ में इसे विस्तार से नहीं कवर किया गया है
  • recommendation model के लिए training data assemble करना, model train और tune करके API के रूप में deploy करना, फिर predictions monitor करना और behavior changes के अनुसार retrain करना इसके उदाहरण हैं

ETL और ELT

• ETL(Extract-Transform-Load) एक सामान्य flow है जिसमें source data extract किया जाता है, clean किया जाता है या दूसरे data के साथ combine किया जाता है, और फिर result को destination में load किया जाता है
• steps का क्रम fixed नहीं होता; वे repeat हो सकते हैं या एक-दूसरे से overlap कर सकते हैं
• ELT में source data पहले warehouse में load किया जाता है, फिर उसी के अंदर transform करके results को अलग tables में store किया जाता है
  • extra storage और compute की वजह से cost बढ़ सकती है
  • raw data बचा रहता है, इसलिए बाद में उसे दूसरे तरीके से फिर process किया जा सकता है

file और memory formats

• CSV छोटे data को share करना आसान बनाता है और ज्यादातर office software में खुल जाता है, इसलिए non-technical users के लिए उपयुक्त है
• Apache Parquet column-oriented file format है, जिसका compression ratio ऊंचा है और जो बड़े data को efficiently store और transfer कर सकता है
  • ज्यादातर data tools इसे support करते हैं, इसलिए यह tools के बीच common format की भूमिका निभाता है
  • Apache ORC भी मिलती-जुलती समस्या हल करता है
• Apache Avro row-oriented binary format है, जिसका उपयोग records transfer करने में, खासकर stream processing में होता है
• Apache Arrow processing और zero-copy transfer के लिए optimized de facto standard in-memory format है
  • Parquet छोटे files और जरूरत की entries scan करने पर focus करता है, जबकि Arrow CPU/GPU instructions और cache का उपयोग करके actual computation पर focus करता है
  • Arrow ज्यादा memory use करता है, लेकिन pandas और Rust के DataFusion जैसे tools के बीच data efficiently pass करता है
  • इसे pandas के optional backend के रूप में इस्तेमाल किया जा सकता है, और Polars व DataFusion शुरू से Arrow-based बनाए गए हैं

data warehouse

• data warehouse PostgreSQL, MySQL जैसे databases से मिलता-जुलता है, लेकिन analytics workloads के लिए optimized होता है
• MySQL जैसे OLTP databases ID से किसी user की एक row खोजने के लिए उपयुक्त होते हैं, जबकि OLAP warehouse सालाना region-wise revenue total जैसे column-wise aggregations के लिए उपयुक्त होता है
• पारंपरिक रूप से यह cleaned structured data का final storage था, लेकिन ELT में raw data के initial loading point के रूप में भी इस्तेमाल होता है
• storage format और query engine बहुत tightly coupled होते हैं, जिससे तेज BI और reporting queries मिलती हैं, लेकिन तीन storage types में इसकी cost सबसे ज्यादा होती है
• products में Snowflake, BigQuery, Redshift शामिल हैं
• open-source और self-hosted options में ClickHouse, Apache Doris, StarRocks शामिल हैं
• छोटे projects के लिए traditional database भी पर्याप्त हो सकता है

data lake

• data lake एक बड़े cloud folder जैसा होता है, जिसमें CSV, Parquet, JSON, emails, images जैसे structured, semi-structured और unstructured data को न्यूनतम processing के साथ रखा जाता है
• Amazon S3, Google Cloud Storage, Azure Blob Storage पर naming/partition rules और access policies तय करके files store कर इसे बनाया जा सकता है
• अगर ठीक से manage न किया जाए, तो यह ऐसा data swamp बन सकता है जिसमें data ढूंढना या इस्तेमाल करना मुश्किल हो जाता है
• managed options में Azure Data Lake और Snowflake के data lake features शामिल हैं
• data को direct search, download और parse किए बिना query करने के लिए metadata catalog और query engine की जरूरत होती है
  • catalog table names, schema और file mappings record करता है
  • query engine उस metadata से relevant files पढ़ता है और SQL जैसी queries run करता है
• catalogs में Hive Metastore, AWS Glue Data Catalog, Unity Catalog शामिल हैं
• query engines में Apache Spark, Trino, Amazon Athena शामिल हैं

डेटा लेकहाउस

• डेटा लेकहाउस सस्ते और लचीले लेक के ऊपर वेयरहाउस जैसी क्षमताएँ जोड़ता है
• इसका मुख्य घटक टेबल फॉर्मेट क्वेरी इंजन और raw data के बीच स्टोरेज तरीके को मैनेज करता है
  • ACID के ज़रिए concurrent writes, लिखते समय होने वाली गड़बड़ियाँ और data corruption को संभालता है
  • semi-structured data के लिए भी schema परिभाषित करना पड़ता है, और पूरी तरह unstructured data को table format के लाभ नहीं मिलते
  • schema evolution और versioning को सपोर्ट करता है
  • indexes और partition optimization से queries को तेज़ बनाया जा सकता है
  • कुछ implementations किसी खास समय के snapshot को query करने वाली time travel सुविधा सपोर्ट करती हैं
• लेक-आधारित होने के कारण यह वेयरहाउस से सस्ता हो सकता है और किसी खास query engine से बंधा नहीं होता, लेकिन अलग compute cost भी जोड़नी पड़ती है, इसलिए सीधी price comparison मुश्किल है
• प्रमुख table formats Apache Iceberg, Delta Lake, Apache Hudi हैं
• managed services में Google का Lakehouse for Apache Iceberg, Databricks, IBM watsonx.data शामिल हैं

डेटा स्रोत और ingestion

• डेटा PostgreSQL·Mongo जैसे application databases, Stripe जैसी external APIs, browser analytics events, IoT devices आदि से आता है
• extraction के बाद इसे तुरंत process किया जा सकता है, और ELT में format, size और infrastructure के आधार पर raw data को पहले lake, lakehouse या warehouse में store किया जा सकता है
• dedicated scripts लचीली होती हैं, लेकिन authentication, pagination, error handling जैसे repetitive connector code को फिर से implement करना पड़ता है
• डेटा ingestion tools source और destination connectors सेट करके यह repetitive काम संभालते हैं
  • extracted data को पहले कहीं load करना पड़ता है, इसलिए flow अक्सर ELT की ओर झुकता है
  • प्रतिनिधि products Fivetran, Airbyte, dlt हैं
• Change Data Capture (CDC) tables को बार-बार query किए बिना database replication logs से inserts, updates और deletes को capture करता है
  • ingestion tools इसे database sources के लिए internally इस्तेमाल करते हैं
  • standalone open source component के रूप में Debezium व्यापक रूप से इस्तेमाल होता है

डेटा processing languages

• Python बड़े community और native library ecosystem के साथ data work की de facto standard language है
  • दूसरी languages में बने tools भी अक्सर Python bindings देते हैं; Rust-based Apache DataFusion इसका एक उदाहरण है
• numpy high-performance multidimensional arrays देता है और कई libraries की बुनियाद बनता है
• pandas 1D Series और 2D DataFrame देने वाला de facto standard है
  • seaborn·Plotly से visualization और streamlit से interactive apps बनाए जा सकते हैं
  • DuckDB से SQL queries चला सकते हैं या scikit-learn की machine learning techniques लागू कर सकते हैं
• R academia में, Java·Scala Spark जैसे big data frameworks में इस्तेमाल होते हैं, और Julia व Rust भी data work में इस्तेमाल होते हैं, लेकिन Python से कम प्रचलित हैं
• SQL warehouse queries और transformations में व्यापक रूप से इस्तेमाल होता है, लेकिन runtime environment के हिसाब से syntax थोड़ा-थोड़ा बदलता है

Batch और real-time processing

• Batch processing पिछले महीने की sales aggregation जैसे बड़े data batches को नियमित रूप से process करता है और उन कामों के लिए उपयुक्त है जिनके results के लिए कुछ घंटे या दिन इंतज़ार किया जा सकता है
• Real-time processing data आते ही process करने वाला stream तरीका या 20-second intervals जैसे microbatches इस्तेमाल करता है
• bot detection जैसी pipelines जहाँ result की speed अहम है, users को जितनी जल्दी हो सके identify और block करने के लिए real-time processing इस्तेमाल करती हैं

SQL-आधारित transformation

• dbt और SQLMesh SQL select statements से transformations define करते हैं और उन्हें actual query engine पर चलने के लिए compile करते हैं
• दोनों tools data को सीधे process नहीं करते, बल्कि transformation orchestration संभालते हैं
• custom Python scripts की तुलना में transformation method को standardize किया जा सकता है और complex jobs को dependencies वाले छोटे models में अलग किया जा सकता है
• dbt का ref hardcoded table names की जगह models को reference करता है और dependency graph के अनुसार सही क्रम में चलाता है
• results आमतौर पर source जैसे ही warehouse, lakehouse या lake में store होते हैं, लेकिन query engine settings के आधार पर उन्हें दूसरी destinations पर भी भेजा जा सकता है

Local DataFrame और DuckDB

• DataFrame tabular data को संभालने वाली 2D array abstraction है, और Python में pandas सबसे अधिक इस्तेमाल होता है
• अन्य implementations में Python·Rust का Polars, Rust का DataFusion, Julia का DataFrames.jl, R का data.frame, Java का tablesaw शामिल हैं
• pandas, data.frame, tablesaw call होते ही compute करने वाले eager execution mode में काम करते हैं
• DataFusion और Polars का LazyFrame operations को logical plan के रूप में जमा करता है और फिर .collect() पर execute करता है
  • execution से पहले plan optimize किया जा सकता है, जिससे तेज़ होने की संभावना रहती है
• local libraries memory और CPU से सीमित होती हैं
  • pandas सभी data को memory में process करता है, इसलिए RAM size से बंधा रहता है
  • Polars की streaming RAM से बड़े data को भी संभाल सकती है, लेकिन कुछ operations में working set को memory में रखना पड़ता है
• DuckDB एक in-process OLAP database है, जिसे “analytics के लिए SQLite” कहा जाता है
  • बिना अलग infrastructure के local CSV, Parquet, pandas DataFrame को SQL से query करता है

बड़े पैमाने की distributed processing

• single machine की सीमा पार होने पर data को कई हिस्सों में बाँटकर cluster में parallel process किया जाता है और workload के मुताबिक horizontally scale किया जाता है
• Apache Hadoop शुरुआती प्रमुख tool था, लेकिन अब इसे legacy माना जाता है और पुराने environments में दिख सकता है
• Apache Spark आज de facto standard है और data loading, transformation, parallelization और optimization संभालता है
  • PySpark DataFrame API और pandas-compatible layer देता है
  • SparkR हाल में deprecated हो चुका है, और Java·Scala bindings भी उपलब्ध हैं
  • यह तरह-तरह के storage पढ़ और लिख सकता है, इसलिए data lake query engine और large-scale transformation jobs दोनों में इस्तेमाल होता है
• Dask परिचित pandas·numpy APIs के करीब रहते हुए Python code को cluster तक scale करता है
• Ray general-purpose distributed compute framework है, जिसका इस्तेमाल खास तौर पर ML training में बहुत होता है
• Apache Flink batch भी process करता है, लेकिन इसका मुख्य फोकस stream processing है

इवेंट स्ट्रीमिंग और Kafka

• स्ट्रीम प्रोसेसिंग उन कामों के लिए उपयुक्त है जहां परिणाम तुरंत चाहिए, जैसे क्रेडिट कार्ड फ्रॉड डिटेक्शन, या वेब analytics events को आते ही validate करना, IP geo जानकारी से enrich करना और ClickHouse में डालना
• आते ही प्रोसेस करने पर अगले batch run तक raw payload को अलग से स्टोर करने की जरूरत नहीं पड़ सकती
• Apache Kafka एक distributed, fault-tolerant event streaming platform है, जो producers से events लेकर उन्हें store करता है और consumers को पढ़ने देता है
  • message queue के विपरीत, consumer के acknowledge करने पर भी event delete नहीं होता, और retention rules expire होने तक कई consumers उसे बार-बार पढ़ सकते हैं
  • Kafka खुद data process नहीं करता; अलग workers consumers के रूप में processing करते हैं
• Kafka Connect Kafka को databases जैसे external systems से जोड़ता है
• Kafka Streams Kafka के ऊपर stateful transformations, window aggregations और joins करने वाली Java·Scala library है
  • यह application में embedded होकर चलती है और सिर्फ Kafka पर काम करती है
• अन्य event streaming platforms में Apache Pulsar, Redpanda, AWS Kinesis Data Streams शामिल हैं

स्ट्रीम प्रोसेसिंग इंजन

• Apache Flink event sources और processing steps की definition लेकर cluster deployment, scaling और failure recovery संभालता है
• pipeline में filtering, field mapping, window aggregation, deduplication, और दूसरे Kafka topics या databases में output शामिल हो सकते हैं
• deployed job खत्म होने वाला batch नहीं होता, बल्कि नए events को लगातार process करता रहता है
• अन्य विकल्पों में Spark Structured Streaming, Google Cloud Dataflow, Azure Stream Analytics शामिल हैं

जॉब ऑर्केस्ट्रेशन

• dbt transformations, Spark jobs और custom scripts बढ़ने पर orchestrator अलग-अलग steps को एक pipeline में जोड़ता है
• हर job और dependency को code, आमतौर पर Python में define करने पर DAG यानी directed acyclic graph बनता है
• orchestrator खुद data process नहीं करता; वह Spark scripts चलाने, dbt transformations call करने, HTTP requests आदि को coordinate करता है
• schedules, Kafka events, UI से manual runs, HTTP requests, और plugins से बने triggers इस्तेमाल किए जा सकते हैं
• independent jobs को parallel में run किया जा सकता है, और failed step को ही retry करके उसी point से resume किया जा सकता है
• यह शुरू से अंत तक चलने वाली batch processing के लिए है, इसलिए लगातार live रहने वाली stream pipelines के लिए बहुत उपयुक्त नहीं है; ऐसे मामलों में Flink जैसे processing engine पर ही निर्भर किया जाता है
• प्रमुख products Apache Airflow, Dagster, Prefect, Luigi हैं
  • Luigi पुराना है और फिलहाल इसकी popularity कम है

ऑब्ज़र्वेबिलिटी और क्वालिटी मॉनिटरिंग

• data observability दो हिस्सों में बंटी होती है: pipeline status और data की quality
  • pipeline monitoring यह देखती है कि run हुआ या नहीं, failures और कितना समय लगा
  • data monitoring freshness, data volume anomalies, बिना सूचना schema changes आदि जांचती है
• pipelines के लिए Prometheus, Grafana, ELK जैसे सामान्य application observability tools और orchestrator की अपनी सुविधाएं इस्तेमाल की जा सकती हैं
• data quality checks को expected formats सीधे define करने वाले Great Expectations और dbt tests से लागू किया जा सकता है
• automated products normal data patterns सीखकर anomalies detect करते हैं; उदाहरण हैं Monte Carlo, Bigeye, Metaplane

pipelines में दोहराई जाने वाली loading

• ETL का अंतिम loading target warehouse, lake या lakehouse होता है, लेकिन data pipeline के अंत में सिर्फ एक बार store नहीं होता; उसे अलग-अलग रूपों में कई बार store किया जाता है
• medallion architecture एक ही storage में refinement levels को तीन layers में बांटता है
  • Bronze source से जस का तस आया raw data है
  • Silver type corrections, deduplication, source joins आदि से गुजरा cleaned और standardized data है
  • Gold dashboards या reports जैसे खास उद्देश्यों के लिए aggregated और modeled data है
• analysts आमतौर पर Gold tables query करते हैं, और engineers pipeline debugging के लिए Bronze तक नीचे जा सकते हैं

डाइमेंशनल मॉडलिंग

• अगर medallion structure data की refinement level दिखाता है, तो dimensional modeling warehouse tables का स्वरूप बनाता है
• Ralph Kimball की 《The Data Warehouse Toolkit》 से popular हुई इस approach में fact tables और dimension tables अलग किए जाते हैं
• fact table orders, payments, page views जैसे हर row में एक event या measurement store करती है
  • यह लंबी और संकरी होती है, इसमें numbers और dimension table foreign keys ज्यादा होते हैं, और यह लगातार बढ़ती रहती है
• dimension table customer, product, date जैसी वह context store करती है जिसमें event हुआ
  • यह ज्यादा चौड़ी होती है और अपेक्षाकृत धीरे बदलती है
• जब central fact table को dimension tables घेरती हैं, तो यह star schema बनता है
  • ज्यादा normalized snowflake schema भी होता है, जिसका Snowflake product से कोई संबंध नहीं है
• grain यह define करता है कि एक row क्या दर्शाती है: एक order, एक order item, या प्रति customer daily orders
• data mart warehouse का वह हिस्सा है जो marketing या finance जैसी किसी खास team या विषय के लिए बनाया जाता है, और आमतौर पर Gold layer में होता है
• सभी teams इसे सख्ती से follow नहीं करतीं; तेज modern warehouses और सस्ते storage का फायदा उठाकर purpose-specific रूप से wide denormalized one big table भी बनाई जाती है

applications के लिए real-time OLAP

• internal dashboards के लिए warehouse की Gold tables काफी होती हैं, लेकिन बहुत सारे users को millisecond-level पर serve करते समय query latency और per-query cost unsuitable हो सकती है
• user-facing analytics, real-time internal monitoring, leaderboards, trending items, usage metering जैसे high concurrency और fast response मांगने वाले data को real-time OLAP database में ले जाया जाता है
• इसमें Apache Druid, Apache Pinot, ClickHouse, Apache Doris आते हैं, और ClickHouse व्यापक रूप से इस्तेमाल होता है

रिवर्स ETL

• reverse ETL warehouse में processed data को CRM जैसे operational tools में वापस भेजता है
• Stripe data से customer lifetime value calculate करके HubSpot में डालने पर sales team high-value customers को तुरंत देख सकती है
• dedicated tools tables/columns को destination fields से map करते हैं और failures, retries, rate limits, alerts, incremental syncs संभालते हैं
• विकल्पों में Airbyte Data Activation, Fivetran Activations, Hightouch, RudderStack शामिल हैं
  • Fivetran Activations का acquisition से पहले नाम Census था

डेटा कैटलॉग और semantic layer

• लोगों के लिए बना डेटा कैटलॉग डेटा के स्रोत, owner, access policy और search information को रखता है, जिससे tables और columns को business context मिलता है
  • इसका उद्देश्य query engine के metastore से अलग होता है
  • Unity Catalog, DataHub, OpenMetadata इसके प्रमुख उदाहरण हैं
• semantic layer business entities, relationships और metrics की standard definitions को स्टोर करती है
  • यह एकरूप करती है कि customer model किस table और column से आता है, EMEA में कौन-से markets शामिल हैं, revenue से refunds हटाए जाते हैं या नहीं आदि
  • BI tools या AI agents में सही entity और metric चुनने पर यह उन्हें जरूरी query में बदलती है या query generation के लिए आवश्यक जानकारी देती है
• Looker का LookML, Cube, dbt Semantic Layer, Unity Catalog की semantic capabilities इसके उदाहरण हैं

डेटा lineage

• डेटा lineage(data lineage) pipelines से गुजरते हुए डेटा कैसे transform हुआ, इसे track करता है
• इसे orchestrator DAG, transformation SQL parsing, और processing jobs द्वारा emit किए गए events व metadata से automatic रूप से collect किया जा सकता है
• table level पर यह relationship record करता है कि gold.orders को silver.orders और silver.customers से बनाया गया है
• column level पर यह इतना भी track करता है कि customers.life_time_value को orders.total और subscription_payments.amount से calculate किया गया है
• इसका उपयोग column deletion के downstream impact assessment, गलत metrics के root cause analysis, और personally identifiable information के उपयोग पर compliance के लिए किया जाता है
• Unity Catalog, DataHub, OpenMetadata lineage visualization support करते हैं, लेकिन पूरी pipeline को connectors या manual events के जरिए tracking data देना होता है
• provider-specific formats के बजाय कई catalogs और processing tools द्वारा supported OpenLineage standard का उपयोग किया जा सकता है

BI dashboards और reports

• dashboards और reports data pipelines के सबसे आम consumers हैं, और छोटी कंपनियों में वे practically इकलौता use case भी हो सकते हैं
• BI tools warehouse, lakehouse और application databases से connect होकर बिना code लिखे charts और dashboards बनाने देते हैं
• मुख्य बात self-service है, जहां non-technical users हर बार analyst से request किए बिना UI में सीधे charts बना या explore कर सकते हैं
• scheduled reports email या Slack पर भेजी जा सकती हैं, या metrics threshold पार करने पर alert किया जा सकता है
• Tableau और Power BI बड़े enterprises में व्यापक रूप से उपयोग होते हैं और powerful, flexible visualization पर focus करते हैं
• Looker LookML semantic layer के इर्द-गिर्द बना है और technical organizations के लिए ज्यादा fit है
• Metabase self-hosting समेत जल्दी setup किया जा सकता है और non-technical users के लिए approachable है
• Looker Studio, LookML का उपयोग नहीं करता और Looker से कम features वाला अलग product है; हाल ही में इसका नाम फिर से Data Studio कर दिया गया

operational analytics

• operational analytics executive reports नहीं, बल्कि non-analyst roles द्वारा रोज इस्तेमाल की जाने वाली applications के अंदर data उपलब्ध कराता है
• उपयोग के उदाहरण ये हैं
  • usage aggregates को HubSpot में sync करना ताकि sales team सही customers को upsell कर सके
  • recent orders, support tickets और pricing plans को Zendesk में sync करना ताकि support team customer context देख सके
  • customer success team के लिए customer-wise product adoption दिखाने वाला internal app बनाना
• reverse ETL इसका प्रतिनिधि delivery method है, लेकिन warehouse को सीधे query करने वाला internal Customer 360 app भी operational analytics में आता है

ad-hoc और exploratory analysis व notebooks

• ad-hoc analysis signup में कमी के कारण या refunds कराने वाले cohorts जैसे one-off questions को existing data से investigate करता है
• exploratory analysis पहले से तय question के बिना data को देखकर insights खोजता है
• results के हिसाब से अगली operation बदलती है और यह simple filters/aggregations से ज्यादा complex होता है, इसलिए केवल सामान्य reporting tools पर्याप्त नहीं हो सकते
• Python और pandas/Polars, warehouse SQL UI, Spyder, RStudio आदि इस्तेमाल किए जा सकते हैं
• notebooks Markdown, code और SQL जैसी cells को एक file में combine करते हैं और images, interactive charts, table outputs को code के पास रखते हैं
  • execution results देखते हुए step-by-step explore करना और results present करना आसान होता है
  • Jupyter, Google Colab, Deepnote, marimo प्रमुख उदाहरण हैं
  • Databricks और Snowflake जैसे platforms भी अपने notebooks provide करते हैं

machine learning में डेटा consumption

• ML feature store, training, tracking और deployment tools वाला अलग क्षेत्र है, लेकिन data का प्रमुख consumer भी है
• LLM के अलावा churn prediction, recommendation, demand forecasting, customer segmentation जैसे specialized models होते हैं, और production में जाने से पहले curated training data की जरूरत होती है
• Data scientist या ML engineer पिछले 30 दिनों के orders की संख्या, last login के बाद बीते दिन जैसे features को warehouse से लाकर model train और deploy करते हैं
• prediction results फिर CRM में churn score जैसे operational analytics या users के लिए product recommendations में वापस उपयोग होते हैं

embedded analytics

• embedded analytics marketplace sellers को popular products, customer regions, search rankings जैसी analytics application के अंदर उपलब्ध कराता है
• अगर बात सिर्फ 5 predefined charts और limited filters तक है, तो query, UI और chart library को खुद implement किया जा सकता है
• अगर users को complex queries करनी हों, तो Metabase, Looker, Tableau जैसे BI tools या Sisense, Luzmo जैसे embed-focused products इस्तेमाल किए जा सकते हैं
• host application authentication और authorization संभालता है, और embedded tool query UI और chart rendering handle करता है

डेटा को product के रूप में बेचना

• डेटा feature का raw material होने से आगे बढ़कर product itself बन सकता है
• कई cryptocurrency blockchains का data collect, transform और index करके analysts को access बेचा जा सकता है, या Google search results collect करके SEO professionals को बेचा जा सकता है
• data और query access बेचने के लिए समय पर collect करने वाली robust pipeline और high-performance query capabilities जरूरी हैं

डेटा governance

• डेटा governance यह manage करता है कि personally identifiable information, health information जैसे sensitive data तक कौन access कर सकता है और access records कैसे रखे जाते हैं
• इसमें data ownership, right to be forgotten जैसी privacy processing, physical storage location और retention period भी शामिल हैं
• warehouse में roles/access control, catalog में ownership information, lineage के जरिए PII usage tracking जैसी technologies इसे support कर सकती हैं
• यह सिर्फ technology की समस्या नहीं है; इसमें people और processes की भूमिका बड़ी होती है और यह legal, compliance और security teams से closely जुड़ा होता है
• पूरे data landscape को source से collect करके store, process और use करने के flow के रूप में देखा जा सकता है, और हर category के नीचे और ज्यादा tools व detailed choices लगातार सामने आ रहे हैं