Databricks में CREATE TABLE: टेबल बनाने और प्रबंधित करने की संपूर्ण गाइड

Databricks टेबल्स Databricks Lakehouse प्लेटफ़ॉर्म का एक मुख्य घटक हैं, जिन्हें बड़े पैमाने पर डेटा स्टोरेज और प्रोसेसिंग संभालने के लिए डिज़ाइन किया गया है। ये टेबल्स संरचित और असंरचित डेटा को एकीकृत करके तथा विश्लेषणात्मक वर्कलोड का समर्थन करके टीमों के बीच सहयोग सक्षम करती हैं।

इस लेख में, मैं आपको विभिन्न उपयोग मामलों के अनुरूप कई सिंटैक्स वेरिएशन्स के साथ CREATE TABLE कमांड का उपयोग करके Databricks में टेबल बनाने की विभिन्न तकनीकों से परिचित कराऊंगा। साथ ही, Databricks में टेबल्स बनाते और प्रबंधित करते समय दक्षता और विश्वसनीयता के लिए सर्वोत्तम प्रथाओं पर टिप्स भी दूंगा।

शुरू करते समय, मैं आपको DataCamp का How to Learn Databricks: A Beginner’s Guide to the Unified Data Platform ब्लॉग पोस्ट देखने की दृढ़ता से सलाह देता हूँ, जो Databricks की मुख्य विशेषताएँ और अनुप्रयोग समझने में मदद करेगा और सीखना शुरू करने के लिए एक संरचित मार्ग देगा। मैं हमारा Introduction to Databricks कोर्स लेने की भी अनुशंसा करता हूँ। भले ही आपको SQL का अनुभव हो, आप देखेंगे कि Databricks Lakehouse प्लेटफ़ॉर्म में चीज़ें अलग दिख सकती हैं। हमारे कोर्स के इंटरैक्टिव अभ्यास आपको SQL क्वेरीज़ के साथ-साथ प्लेटफ़ॉर्म फीचर्स और बाहरी सिस्टम कनेक्शंस के माध्यम से मार्गदर्शन करेंगे।

Databricks टेबल्स का परिचय

शुरुआत में, यह कहना चाहिए कि Databricks टेबल्स संरचित डेटासेट्स हैं जो Databricks Lakehouse परिवेश में डेटा के संगठन और पहुँच को सुगम बनाती हैं। इसके दो प्रकार होते हैं:

• मैनेज्ड टेबल्स: ये टेबल्स पूरी तरह Databricks द्वारा नियंत्रित होती हैं, जो स्टोरेज और मेटाडेटा दोनों को मैनेज करता है। जब एक मैनेज्ड टेबल बनाई जाती है, तो Databricks अंतर्निहित डेटा फाइलों का ध्यान रखता है, और यदि टेबल हटाई जाती है, तो संबंधित डेटा भी हटा दिया जाता है। 
• एक्सटर्नल टेबल्स: बाहरी टेबल्स उस डेटा को संदर्भित करती हैं जो Databricks के बाहर रहता है, आमतौर पर AWS S3 या Azure Blob Storage जैसे क्लाउड स्टोरेज सिस्टम में। Databricks इन टेबल्स के लिए मेटाडेटा मैनेज करता है, लेकिन यदि टेबल ड्रॉप कर दी जाए, तो वास्तविक डेटा जस का तस रहता है। इन्हें unmanaged tables भी कहा जाता है।

Databricks में टेबल्स अक्सर Delta Lake पर डिफ़ॉल्ट होती हैं, इसकी उन्नत विशेषताओं और ऑप्टिमाइज़ेशन्स के कारण। Delta Lake ACID ट्रांज़ैक्शंस, स्केलेबिलिटी, प्रदर्शन बढ़ाने के लिए कैशिंग और इंडेक्सिंग जैसी ऑप्टिमाइज़ेशन, और बैच और स्ट्रीमिंग डेटा प्रोसेसिंग का एकीकृत समर्थन प्रदान करता है।

ध्यान दें कि Azure Databricks के शुरुआती संस्करणों में पुराना “Hive format” टेबल्स उपयोग होता था, जिन्हें अब आधुनिक Delta टेबल्स ने बदल दिया है। समग्र रूप से, आधुनिक Delta टेबल्स विश्वसनीयता और प्रदर्शन में लेगेसी Hive टेबल्स से बेहतर हैं, इसलिए वे Databricks वर्कफ़्लोज़ के लिए डिफ़ॉल्ट विकल्प हैं।

यहाँ एक सारांश है जो, मेरे विचार में, आपको दोनों के बीच का अंतर समझने में मदद करेगा:

CREATE TABLE के सिंटैक्स वेरिएशन्स

Databricks में CREATE TABLE कमांड विभिन्न मामलों को समायोजित करने के लिए कई वेरिएशन्स को सपोर्ट करता है। हर वेरिएशन का एक उद्देश्य होता है, जैसे फ़ाइल लोकेशन, क्लोनिंग और मेटाडेटा मैनेजमेंट जैसे लक्षित विकल्प। यदि आपको Databricks SQL के बारे में अपना ज्ञान ताज़ा करने की आवश्यकता है, तो मैं हमारा Databricks SQL ट्यूटोरियल पढ़ने की सलाह देता हूँ ताकि, अन्य बातों के अलावा, आप सीख सकें कि Databricks SQL वेयरहाउस में Notebook का उपयोग कैसे करें।

नीचे मुख्य सिंटैक्स शैलियाँ उदाहरणों और स्पष्टीकरणों के साथ दी गई हैं।

CREATE TABLE [USING]

यह सिंटैक्स निर्दिष्ट स्कीमा और डेटा फॉर्मेट के साथ एक नई टेबल बनाता है। निम्नलिखित क्वेरी एक sales_data नामक टेबल बनाती है, जो किसी विशिष्ट लोकेशन पर स्टोर किए गए Parquet फाइलों से डेटा पढ़ती है।

-- Create a table from files in a specific format
CREATE TABLE sales_data
USING PARQUET
LOCATION '/mnt/data/sales';संचालित द्वारा

CREATE TABLE (Hive format)

यह लेगेसी सिंटैक्स मानक SQL CREATE TABLE कमांड जैसा है, जिसका उपयोग तब किया जाता है जब Databricks द्वारा मैनेज किए गए मेटाडेटा के साथ टेबल परिभाषित करनी हो और बाहरी फाइलों का संदर्भ न देना हो। नीचे दी गई क्वेरी hive_table नामक एक Hive-शैली की टेबल बनाती है, जिसमें एक पूर्व-परिभाषित स्कीमा और अतिरिक्त मेटाडेटा प्रॉपर्टीज़ हैं।

-- Hive-style table creation with schema definition
CREATE TABLE hive_table (
    id INT,
    name STRING
)
COMMENT 'Hive format example'
TBLPROPERTIES ('created_by' = 'databricks');संचालित द्वारा

ऊपर की क्वेरी में, COMMENT क्लॉज़ वर्णनात्मक मेटाडेटा जोड़ता है जबकि TBLPROPERTIES टेबल के बारे में कस्टम प्रॉपर्टीज़ स्टोर करता है।

CREATE TABLE LIKE

यह कमांड किसी मौजूदा टेबल की स्कीमा और प्रॉपर्टीज़ का उपयोग करके नई टेबल बनाता है। जब आप बिना डेटा कॉपी किए किसी मौजूदा टेबल की संरचना दोहराना चाहते हैं, तब यह सिंटैक्स उपयोग करें। यह परीक्षण या विकास उद्देश्यों के लिए उपयोगी है।

-- Create a table with the same schema as another table
CREATE TABLE new_table LIKE existing_table;संचालित द्वारा

CREATE TABLE CLONE

यह सिंटैक्स मौजूदा Delta Lake टेबल को गहराई (deep) या सतही (shallow) क्लोन करके नई टेबल बनाने की अनुमति देता है। इसलिए, जब आपको किसी टेबल के डेटा और मेटाडेटा की स्वतंत्र कॉपी (deep clone) या सिर्फ मेटाडेटा की कॉपी चाहिए जो मूल डेटा को रेफरेंस करे (shallow clone), तब CREATE TABLE CLONE सिंटैक्स का उपयोग करें। इसे वर्ज़निंग या बैकअप बनाने के लिए सोचें।

निम्न उदाहरण Databricks में deep clone और shallow clone टेबल्स बनाने की क्वेरीज़ दिखाता है।

 -- Deep clone by default
CREATE TABLE cloned_table CLONE original_table;

-- Shallow clone
CREATE TABLE shallow_clone_table SHALLOW CLONE original_table;  संचालित द्वारा

CREATE OR REPLACE TABLE

यह एकल, संयोजित कमांड मौजूदा टेबल को नए से प्रतिस्थापित करता है, वही टेबल नाम बनाए रखते हुए, एक ही ऑपरेशन में। जब आप मौजूदा टेबल को पूरी तरह ओवरराइट करना चाहते हैं जबकि उसका नाम बनाए रखना हो, तो यह सिंटैक्स उपयोग करें। यह विशेष रूप से उपयोगी है जब आपको पहले टेबल ड्रॉप किए बिना ही उसकी संरचना या डेटा अपडेट करना हो।

नीचे दिया उदाहरण sales टेबल को नए स्कीमा के साथ बनाता या प्रतिस्थापित करता है।

-- Create or replace a sales table with a new schema
CREATE OR REPLACE TABLE sales (
    sale_id INT,
    amount FLOAT
)
USING DELTA
LOCATION '/mnt/delta/sales';संचालित द्वारा

Databricks में CREATE TABLE सिंटैक्स के साथ आप अन्य प्रासंगिक क्लॉज़ भी उपयोग कर सकते हैं, ताकि विशिष्ट आवश्यकताओं के अनुसार टेबल्स मैनेज कर सकें। नीचे प्रत्येक क्लॉज़ के उपयोग का सारांश है। मैंने इनमें से कुछ को पहले ही उदाहरणों में उपयोग किया है, पर सभी नहीं।

• IF NOT EXISTS: यदि टेबल पहले से मौजूद है तो निर्माण को स्किप करके त्रुटियों से बचाता है।

• USING: फ़ाइल फॉर्मेट निर्दिष्ट करता है (जैसे, Delta, Parquet, CSV)।

• EXTERNAL: ऐसी टेबल घोषित करता है जिसका डेटा Databricks के मैनेज्ड स्टोरेज के बाहर रहता है।

• PARTITIONED BY: बड़े डेटासेट्स के लिए ऑप्टिमाइज़ेशन हेतु पार्टिशन्स परिभाषित करता है।

• LOCATION: टेबल डेटा वाली डायरेक्टरी की ओर इंगित करता है।

• TBLPROPERTIES: कस्टम टेबल कॉन्फ़िगरेशन और ऑप्टिमाइज़ेशन के लिए मेटाडेटा जोड़ता है।

स्टेप-बाय-स्टेप डिमॉन्स्ट्रेशन

इस अनुभाग में, मैं Databricks में टेबल बनाने और प्रबंधित करने के विभिन्न तरीकों का प्रदर्शन करूँगा, संक्षिप्त उदाहरणों और प्रमुख क्लॉज़ की व्याख्याओं के साथ। मैं हमारा Databricks Tutorial: 7 Must-know Concepts For Any Data Specialist ट्यूटोरियल देखने की सलाह देता हूँ ताकि आप Databricks प्लेटफ़ॉर्म में SQL कमांड्स कैसे चलाएँ, यह सीख सकें।

खाली टेबल कैसे बनाएँ

खाली Delta टेबल बनाने के लिए, कॉलम नामों और डेटा प्रकारों के साथ टेबल स्कीमा परिभाषित करें। टेबल फॉर्मेट परिभाषित करने के लिए USING DELTA क्लॉज़ का उपयोग करें और वर्णनात्मक मेटाडेटा जोड़ने के लिए COMMENT का।

यह क्वेरी employees नामक खाली Delta टेबल बनाती है, जिसमें पूर्व-परिभाषित स्कीमा है—id, name, department, और hire_date कॉलम सहित। 

-- Create an empty Delta table with a defined schema
CREATE TABLE employees (
    id BIGINT,
    name STRING,
    department STRING,
    hire_date DATE
)
USING DELTA
COMMENT 'Table to store employee information';संचालित द्वारा

मौजूदा डेटा से टेबल कैसे बनाएँ

मौजूदा डेटा से टेबल बनाने के लिए, CSV, Parquet या JSON जैसे फॉर्मेट्स में बाहरी डेटा फाइल्स से टेबल को लिंक करें। आप टेबल को फाइल पाथ से लिंक करने के लिए LOCATION क्लॉज़ और डेटा फॉर्मेट बताने के लिए USING क्लॉज़ का उपयोग कर सकते हैं।

उदाहरण के लिए, नीचे दी गई क्वेरी /mnt/data/sales_data/ पर स्टोर Parquet फाइलों को रेफरेंस करके sales_data नामक टेबल बनाती है।

-- Create a table from Parquet files in a specified location
CREATE TABLE sales_data
USING PARQUET
LOCATION '/mnt/data/sales_data/';संचालित द्वारा

टेबल को AS SELECT (CTAS) के रूप में कैसे बनाएँ

आप किसी क्वेरी को निष्पादित करके और परिणाम को स्टोर करके टेबल AS SELECT भी बना सकते हैं। इस परिदृश्य में, AS SELECT क्लॉज़ क्वेरी परिणाम से टेबल को पॉपुलेट करता है।

उदाहरण के लिए, नीचे दी गई क्वेरी मौजूदा sales_data टेबल से डेटा चुनकर और ट्रांसफ़ॉर्म करके high_value_sales नामक नई टेबल बनाती है। यह उन पंक्तियों को फ़िल्टर करती है जहाँ total_amount 1000 से अधिक है, और केवल sale_id, customer_id और total_amount कॉलम रखती है। 

-- Create a table by selecting and transforming data from another table
CREATE TABLE high_value_sales AS
SELECT
    sale_id,
    customer_id,
    total_amount
FROM sales_data
WHERE total_amount > 1000;संचालित द्वारा

एक्सटर्नल टेबल कैसे बनाएँ

एक्सटर्नल टेबल बनाना Databricks के मैनेज्ड स्टोरेज के बाहर स्टोर डेटा को रेफरेंस करना शामिल करता है। बाहरी डेटा लोकेशन निर्दिष्ट करने के लिए आपको LOCATION क्लॉज़ का उपयोग करना चाहिए।

नीचे दी गई क्वेरी /mnt/external_storage/external_table/ पर स्टोर डेटा को रेफरेंस करके external_table नामक एक्सटर्नल Delta टेबल बनाती है।

-- Create an external table referencing data outside Databricks storage
CREATE TABLE external_table
USING DELTA
LOCATION '/mnt/external_storage/external_table/';संचालित द्वारा

टेबल LIKE कैसे बनाएँ

टेबल LIKE बनाने के लिए, किसी मौजूदा टेबल की स्कीमा को डेटा कॉपी किए बिना डुप्लिकेट करें। नीचे के उदाहरण में, क्वेरी मौजूदा sales टेबल के समान स्कीमा के साथ sales_backup नामक नई टेबल बनाती है।

-- Create a new sales table with the same schema as an existing table
CREATE TABLE sales_backup LIKE sales;संचालित द्वारा

TABLE CLONE कैसे बनाएँ

आप CLONE क्लॉज़ का उपयोग करके बैकअप या टेस्टिंग के लिए Delta टेबल की shallow या deep कॉपी बनाकर टेबल क्लोन बना सकते हैं।

निम्न उदाहरण में, क्वेरी केवल मेटाडेटा (स्कीमा और टेबल प्रॉपर्टीज़) कॉपी करते हुए sales_shallow_clone नामक नई टेबल बनाती है।

-- Shallow clone: Copies only metadata (references original data)
CREATE TABLE sales_shallow_clone CLONE sales_data;संचालित द्वारा

नीचे का उदाहरण sales_deep_clone नामक नई टेबल बनाता है, जो मेटाडेटा और वास्तविक डेटा दोनों कॉपी करता है।

-- Deep clone: Copies both metadata and actual data
CREATE TABLE sales_deep_clone CLONE sales_data DEEP;संचालित द्वारा

अस्थायी टेबल (temp table) कैसे बनाएँ

सेशन-विशिष्ट टेबल सुनिश्चित करने के लिए अस्थायी टेबल बनाते समय TEMPORARY क्लॉज़ का उपयोग करें।

नीचे दी गई क्वेरी temp_table नामक अस्थायी टेबल बनाती है जो केवल वर्तमान सेशन के लिए मौजूद रहती है। यह sales_data से id, name और sales_amount चुनती है, और उन पंक्तियों के लिए फ़िल्टर करती है जहाँ region = 'US' है।

-- Create a temporary table that exists only in the session
CREATE TEMPORARY TABLE temp_table AS
SELECT
    id,
    name,
    sales_amount
FROM sales_data
WHERE region = 'US';संचालित द्वारा

टेबल को कैसे प्रतिस्थापित करें

आप CREATE OR REPLACE क्लॉज़ का उपयोग करके टेबल की परिभाषा और सामग्री को प्रतिस्थापित कर सकते हैं। नीचे दी गई क्वेरी मौजूदा updated_table को नए स्कीमा और डेटा के साथ प्रतिस्थापित करती है। यह टेबल को तीन कॉलम (id, name, total_sales) के साथ परिभाषित करती है।

-- Replace an existing table with a new schema or data
CREATE OR REPLACE TABLE updated_table (
    id BIGINT,
    name STRING,
    total_sales DOUBLE
)
USING DELTA
LOCATION '/mnt/delta/updated_table/';संचालित द्वारा

एडवांस्ड टॉपिक्स

इस अनुभाग में, मैं Databricks टेबल्स की उन्नत विशेषताओं का अन्वेषण करूँगा जो कार्यक्षमता, प्रदर्शन और सुरक्षा को बढ़ाती हैं।

जनरेटेड कॉलम और आइडेंटिटी कॉलम

Databricks आइडेंटिटी कॉलम सपोर्ट करता है, जो प्रत्येक नई पंक्ति के लिए स्वतः ही अद्वितीय मान जेनरेट करते हैं। यह सुविधा डेटा वेयरहाउसिंग में सरोगेट कीज़ बनाने के लिए उपयोगी है।

नीचे दी गई क्वेरी employees नामक टेबल बनाती है जिसमें तीन कॉलम हैं: id, name, और department। id कॉलम एक आइडेंटिटी कॉलम है जो हर नई पंक्ति के साथ ऑटो-इन्क्रीमेंट होता है।

-- Identity column: auto-incremented value
CREATE TABLE employees (
    id BIGINT GENERATED ALWAYS AS IDENTITY, -- Auto-incremented column
    name STRING,
    department STRING
);संचालित द्वारा

यह दूसरी क्वेरी sales नामक टेबल बनाती है जिसमें तीन कॉलम हैं: sale_id, sale_date, और sale_year। sale_year कॉलम जनरेटेड है और sale_date कॉलम के आधार पर YEAR(sale_date) फ़ंक्शन का उपयोग करके स्वचालित रूप से गणना होता है।

-- Generated column: derived from other columns
CREATE TABLE sales (
    sale_id BIGINT,
    sale_date DATE,
    sale_year INT GENERATED ALWAYS AS (YEAR(sale_date)) -- Derived column
);संचालित द्वारा

पार्टिशनिंग और क्लस्टरिंग

पार्टिशनिंग डेटा को छोटे हिस्सों में विभाजित करती है, जिससे क्वेरी प्रदर्शन बेहतर होता है, जबकि क्लस्टरिंग पार्टिशन्स के भीतर डेटा को व्यवस्थित करती है ताकि रीड्स तेज़ हों।

उदाहरण के लिए, नीचे दी गई क्वेरी एक पार्टिशन्ड टेबल बनाती है जहाँ डेटा region कॉलम के आधार पर पार्टिशन्स में बाँटा जाता है, जिससे region पर फ़िल्टर करते समय क्वेरी प्रदर्शन में सुधार होता है।

-- Partitioned table
CREATE TABLE partitioned_table (
    id BIGINT,
    region STRING,
    sales_amount DOUBLE
)
USING DELTA
PARTITIONED BY (region); -- Querying by region will be fasterसंचालित द्वारा

नीचे दी गई क्वेरी पार्टिशन्ड टेबल को sales_amount कॉलम के आधार पर हर पार्टिशन के भीतर डेटा को क्लस्टर करके ऑप्टिमाइज़ करती है। यह कुशल रीड्स के लिए डेटा लेआउट में सुधार कर sales_amount पर क्वेरीज़ को तेज़ बनाती है। ध्यान दें, ZORDER BY क्लॉज़ पार्टिशन्स के भीतर काम करता है ताकि रीड प्रदर्शन बेहतर हो; यह पार्टिशन्स के पार क्लस्टरिंग नहीं करता।

-- Clustered table
OPTIMIZE partitioned_table
ZORDER BY (sales_amount); -- Clusters data within partitions for efficient readsसंचालित द्वारा

कॉलम मास्किंग और रो फ़िल्टर्स

कॉलम मास्किंग और रो फ़िल्टर्स उपयोगकर्ता भूमिकाओं या शर्तों के आधार पर डेटा दृश्यता को सीमित करते हैं, जिससे संवेदनशील जानकारी सुरक्षित रहती है।

उदाहरण के लिए, नीचे दी गई क्वेरी employees टेबल के आधार पर masked_table नामक एक मास्क्ड व्यू बनाती है। salary कॉलम सभी उपयोगकर्ताओं के लिए रिडैक्टेड (REDACTED से प्रतिस्थापित) है, सिवाय उन लोगों के जिनकी भूमिका manager है। CASE स्टेटमेंट सुनिश्चित करता है कि केवल मैनेजर्स को वास्तविक सैलरी दिखे, जबकि अन्य मास्क्ड डेटा देखें।

-- Column masking: Redact sensitive data
CREATE MASKED VIEW masked_table AS
SELECT
    id,
    name,
    CASE
        WHEN current_user() = 'manager' THEN salary
        ELSE 'REDACTED'
    END AS salary
FROM employees;संचालित द्वारा

इसी तरह, नीचे दी गई क्वेरी रो फ़िल्टर्स का उपयोग करके sales टेबल के आधार पर filtered_table नामक व्यू बनाती या प्रतिस्थापित करती है। यह व्यू केवल उन पंक्तियों को शामिल करता है जहाँ region = 'US' है, जिससे केवल US की बिक्री डेटा तक ही पहुँच सीमित हो जाती है।

-- Row filters: Fine-grained access control
CREATE OR REPLACE VIEW filtered_table AS
SELECT *
FROM sales
WHERE region = 'US'; -- Limit data visibility to a specific regionसंचालित द्वारा

स्कीमा इवोल्यूशन

Databricks CREATE OR REPLACE TABLE और टेबल अल्टरेशन्स के माध्यम से स्कीमा इवोल्यूशन को सपोर्ट करता है। आपको स्कीमा और डेटा को ओवरराइट करने के लिए CREATE OR REPLACE TABLE स्टेटमेंट और डेटा को प्रभावित किए बिना क्रमिक रूप से स्कीमा संशोधित करने के लिए ALTER TABLE स्टेटमेंट का उपयोग करना चाहिए।

नीचे दी गई क्वेरी मौजूदा employees टेबल को नए स्कीमा के साथ प्रतिस्थापित करती है, जिसमें Delta फॉर्मेट में डेटा रखते हुए नया hire_date कॉलम जोड़ा जाता है।

-- Schema evolution with CREATE OR REPLACE TABLE
CREATE OR REPLACE TABLE employees (
    id BIGINT,
    name STRING,
    department STRING,
    hire_date DATE -- New column added
)
USING DELTA;संचालित द्वारा

यह दूसरी क्वेरी मौजूदा स्कीमा में नया salary कॉलम जोड़कर employees टेबल को संशोधित करती है।

-- Altering a table schema
ALTER TABLE employees ADD COLUMNS (salary DOUBLE);संचालित द्वारा

प्रदर्शन ट्यूनिंग

बड़े पैमाने की टेबल्स के लिए प्रदर्शन को ऑप्टिमाइज़ करने हेतु आप auto-optimization और Z-ordering जैसी विभिन्न टेबल प्रॉपर्टीज़ और तकनीकों का उपयोग कर सकते हैं।

निम्न उदाहरण में, क्वेरी delta_table पर auto-optimization सक्षम करती है, ताकि छोटे फाइलों को स्वतः कॉम्पैक्ट किया जा सके और राइट्स के दौरान फाइलें मर्ज की जा सकें, जिससे स्टोरेज दक्षता में सुधार हो।

-- Enable automatic optimizations
ALTER TABLE delta_table
SET TBLPROPERTIES (
    'delta.autoOptimize.optimizeWrite' = 'true', -- Automatically compact small files
    'delta.autoOptimize.autoCompact' = 'true'   -- Automatically merge files
);संचालित द्वारा

इसी तरह, नीचे दी गई क्वेरी region और sales_date के आधार पर डेटा को क्लस्टर करके delta_table को ऑप्टिमाइज़ करती है, विशेष रूप से इन कॉलम्स पर फ़िल्टर्स के लिए क्वेरी प्रदर्शन को बेहतर बनाने हेतु।

-- Perform clustering for faster query performance
OPTIMIZE delta_table
ZORDER BY (region, sales_date); -- Improves query efficiency for frequent filtersसंचालित द्वारा

सर्वोत्तम प्रथाएँ और विचार

Databricks में टेबल्स बनाते समय सही तरीके से काम करने के लिए ध्यान में रखने योग्य कुछ बातें यहाँ दी गई हैं:

• टेबल नामकरण कन्वेंशन्स: खोजयोग्यता बढ़ाने और त्रुटियाँ कम करने के लिए हमेशा स्पष्ट और सुसंगत नामों का उपयोग करें। संगतता समस्याओं से बचने के लिए विशेष वर्णों या अत्यधिक लंबे नामों से परहेज करें।
• सुरक्षा और अनुमतियाँ: सभी डेटा एसेट्स पर केंद्रीकृत एक्सेस कंट्रोल के लिए Unity Catalog का उपयोग करें। यह निर्धारित करने के लिए कि कौन डेटा देख या संशोधित कर सकता है, Access Control Lists (ACLs) का उपयोग करें। साथ ही, संवेदनशील डेटा को कॉलम मास्किंग या रो फ़िल्टर्स से मास्क करें।
• बैकअप और रिकवरी: आसान रिकवरी और टाइम ट्रैवल के लिए Delta Lake के वर्ज़न इतिहास पर भरोसा करें। स्टोरेज लागत और रिकवरी आवश्यकताओं के बीच संतुलन के लिए नियमित रूप से ऐतिहासिक वर्ज़न्स के रिटेंशन की निगरानी और प्रबंधन करें।
• मैनेज्ड बनाम एक्सटर्नल टेबल्स: मैनेज्ड और एक्सटर्नल टेबल्स के बीच अंतर समझना भी महत्वपूर्ण है। मैनेज्ड टेबल्स में Databricks मेटाडेटा और डेटा दोनों को संभालता है। यह उन परिदृश्यों के लिए आदर्श है जहाँ आप डेटा लाइफसाइकल मैनेजमेंट पर पूर्ण नियंत्रण चाहते हैं। हालाँकि, एक्सटर्नल टेबल्स में, रेफरेंसेड डेटा Databricks के बाहर स्टोर होता है। यह तब उपयोगी है जब आप ऐसे डेटा पर नियंत्रण बनाए रखना चाहते हैं जिसे विभिन्न प्लेटफ़ॉर्म या सिस्टम्स के बीच साझा किया जा सकता है।

सामान्य कमियाँ और समस्या निवारण

अब जब हमने Databricks में टेबल्स प्रबंधित करने की सर्वोत्तम प्रथाओं पर चर्चा कर ली है, तो मैं उन बारंबार आने वाली समस्याओं को कवर करूँगा जिनका आप Databricks टेबल्स के साथ सामना कर सकते हैं, उनके सामान्य एरर मैसेज, और फिर उनके समाधान।

CREATE बनाम CREATE OR REPLACE उपयोग करते समय non-empty लोकेशन एरर्स

जब आप निर्दिष्ट लोकेशन (LOCATION क्लॉज़) के साथ CREATE TABLE का उपयोग करते हैं, और डायरेक्टरी खाली नहीं है, तो आपको इस तरह की त्रुटि मिल सकती है:

Error: Cannot create table because the location is not empty.संचालित द्वारा

यह त्रुटि इसलिए आती है क्योंकि CREATE TABLE कमांड निर्दिष्ट लोकेशन के लिए खाली डायरेक्टरी की अपेक्षा करता है, लेकिन मौजूदा फाइलें या मेटाडेटा इस आवश्यकता से टकराते हैं। 

इस त्रुटि को हल करने के लिए, मौजूदा डेटा और मेटाडेटा को ओवरराइट करने हेतु CREATE OR REPLACE TABLE स्टेटमेंट का उपयोग करें। या फिर, CREATE TABLE स्टेटमेंट उपयोग करने से पहले डायरेक्टरी को मैन्युअली साफ़ करें।

CREATE OR REPLACE TABLE delta_table
USING DELTA
LOCATION '/mnt/data/delta_table'; -- Overwrites table and filesसंचालित द्वारा

स्कीमा मिसमैच या कुछ डेटा प्रकारों से संबंधित समस्याएँ

डेटा इंसर्ट या क्वेरी करने पर निम्न जैसी स्कीमा मिसमैच त्रुटियाँ आ सकती हैं:

Error: Schema mismatch: Expected column type STRING, but found INT.संचालित द्वारा

यह त्रुटि टेबल स्कीमा और आने वाले डेटा प्रकारों के बीच असंगति के कारण हो सकती है। साथ ही, असमर्थित या अस्पष्ट डेटा प्रकार रूपांतरण (जैसे, जटिल nested प्रकार) भी स्कीमा मिसमैच कर सकते हैं। इस त्रुटि को हल करने के लिए, टेबल बनाते समय स्कीमा का सत्यापन करके स्कीमा मैचिंग लागू करें या Delta टेबल्स में स्कीमा एन्फोर्समेंट का उपयोग करें।

-- Enforce schema matching during table creation
CREATE TABLE schema_table (
    id INT,
    name STRING
)
USING DELTA
TBLPROPERTIES ('delta.schema.enforce' = 'true'); -- Enforces strict schemaसंचालित द्वारा

साथ ही, नए कॉलम जोड़ते समय या डेटा प्रकार बदलते समय स्कीमा इवोल्यूशन की अनुमति दें।

ALTER TABLE schema_table ADD COLUMNS (new_column DOUBLE);संचालित द्वारा

डेटा इंसर्ट करते समय explicit टाइप कास्टिंग का उपयोग करना भी इस प्रकार की त्रुटि का निवारण करने में मदद करेगा।

INSERT INTO schema_table SELECT CAST(id AS INT), CAST(name AS STRING) FROM source_table;संचालित द्वारा

आइडेंटिटी कॉलम्स के साथ समकालिक ट्रांज़ैक्शंस की सीमाएँ

आइडेंटिटी कॉलम्स का उपयोग करते समय, समकालिक ट्रांज़ैक्शंस से संबंधित समस्याएँ आ सकती हैं, जैसे:

Error: Concurrent transactions detected on identity column tableसंचालित द्वारा

आइडेंटिटी कॉलम्स stateful होते हैं और तब कॉन्फ्लिक्ट हो सकता है जब कई ट्रांज़ैक्शंस एक साथ डेटा इंसर्ट करने का प्रयास करें। इस त्रुटि का निवारण करने के लिए, सरोगेट कीज़ का उपयोग करें—uuid() या monotonically_increasing_id() जैसी फ़ंक्शंस से उत्पन्न होने वाली डिटर्मिनिस्टिक सरोगेट कीज़ के साथ आइडेंटिटी कॉलम्स को बदलें।

CREATE TABLE better_table AS
SELECT
    monotonically_increasing_id() AS id, -- Replaces identity column
    name, department
FROM source_data;संचालित द्वारा

आप जटिल insert और update वर्कफ़्लोज़ के लिए आइडेंटिटी कॉलम्स पर निर्भर हुए बिना Delta Lake के MERGE का भी उपयोग कर सकते हैं।

MERGE INTO target_table AS t
USING source_table AS s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;संचालित द्वारा

निष्कर्ष

Databricks में, CREATE TABLE कमांड डेटा संरचनाएँ परिभाषित करने, बाहरी डेटा से लिंक करने, और क्वेरीज़ के माध्यम से नए डेटासेट्स प्राप्त करने के लिए एक बहुमुखी टूल है। अपनी निर्दिष्ट आवश्यकताओं के अनुसार Databricks में टेबल्स बनाने और प्रबंधित करने के विभिन्न सिंटैक्स को समझना महत्वपूर्ण है। जैसा कि आपने देखा, चुनने के लिए टेबल बनाने के कुछ अलग-अलग तरीके हैं।

यदि आप Databricks की बुनियादी अवधारणाओं का अन्वेषण करना चाहते हैं, तो मैं DataCamp का Introduction to Databricks कोर्स लेने की अत्यधिक अनुशंसा करता हूँ, ताकि बिज़नेस इंटेलिजेंस (BI) के लिए डेटा वेयरहाउसिंग समाधान के रूप में Databricks के बारे में सीख सकें। मैं हमारा Databricks Certifications In 2025 ब्लॉग पोस्ट भी देखने की सलाह देता हूँ ताकि आप Databricks सर्टिफ़िकेशन्स प्राप्त करने, करियर लाभों का अन्वेषण करने, और अपने करियर लक्ष्यों के लिए सही सर्टिफ़िकेशन चुनने के बारे में जान सकें।