1. परिचय
आजकल के एंटरप्राइज़ डेटा क्लाउड में, डेटा अलग-अलग फ़िज़िकल स्टोरेज सिस्टम में सेव होता है. इसलिए, सुरक्षा को लेकर एक बड़ी समस्या यह है कि डेटा को अलग-अलग हिस्सों में बांटा जाता है.
जब डेटा को Google Cloud Storage पर Parquet जैसे ओपन-सोर्स फ़ॉर्मैट में सेव किया जाता है और BigQuery SQL या Apache Spark जैसे कई अलग-अलग इंजन से क्वेरी किया जाता है, तो यह कैसे पक्का किया जाता है कि संवेदनशील डेटा (जैसे कि वित्तीय लेन-देन की रकम) को लगातार सुरक्षित रखा जाए?
इस कोडलैब में, आपको एक ऐसा डेटा लेकहाउस आर्किटेक्चर बनाना है जो इन समस्याओं को हल कर सके. इसके लिए, आपको Apache Iceberg टेबल, BigQuery, और Dataplex Universal Catalog का इस्तेमाल करना होगा. आपके पास, Infrastructure as Code (IaC) का इस्तेमाल करके, ज़ीरो-ट्रस्ट सुरक्षा नीतियां तय करने का विकल्प होगा. साथ ही, यह तय करने का विकल्प होगा कि अलग-अलग कंप्यूट इंजन पर इन नीतियों को डाइनैमिक तरीके से कैसे लागू किया जाए.
ज़रूरी शर्तें
- बिलिंग की सुविधा वाला Google Cloud प्रोजेक्ट.
- SQL, IAM, और Cloud Storage के कॉन्सेप्ट की बुनियादी जानकारी.
आपको क्या सीखने को मिलेगा
- BigQuery में Apache Iceberg के लिए BigLake टेबल कैसे बनाएं, जहां Cloud Storage में डेटा सेव होता है.
- कॉलम-लेवल पर सुरक्षा और डेटा मास्किंग के लिए, नीति टैग का इस्तेमाल करके, डेटा से जुड़ी नीतियों को कैसे लागू करें.
- क्लाउड रिसोर्स कनेक्शन का इस्तेमाल करके, फ़िज़िकल स्टोरेज के ऐक्सेस को लॉजिकल डेटा ऐक्सेस से अलग करने का तरीका.
- Google Cloud Serverless for Apache Spark का इस्तेमाल करके, ज़ीरो-ट्रस्ट कंप्यूट डेलिगेशन को लागू करने का तरीका. इससे यह पक्का किया जा सकता है कि ओपन-सोर्स इंजन, गवर्नेंस को बायपास न कर पाएं.
- अपने-आप जनरेट होने वाले डेटा लीनेज को विज़ुअलाइज़ करने का तरीका.
आर्किटेक्चर के बारे में खास जानकारी: Iceberg पर यूनिवर्सल गवर्नेंस
ओपन-सोर्स डेटा फ़ॉर्मैट पर बेहतर तरीके से ऐक्सेस कंट्रोल (जैसे, कॉलम-लेवल की सुरक्षा और डेटा मास्किंग) पाने के लिए, आपको सुरक्षा से जुड़ा एक मज़बूत और एक जैसा स्ट्रक्चर बनाना होगा.
डायग्राम में दिखाए गए इस पैटर्न में, सुरक्षा से जुड़ी चुनौतियों को हल करने के लिए दो मुख्य बातों का ध्यान रखा जाता है:
🛡️ सुरक्षित आर्किटेक्चर लेयर (बाईं ओर)
उपयोगकर्ताओं या बाहरी इंजन को Cloud Storage को सीधे तौर पर ऐक्सेस करने की अनुमति देने के बजाय, एक सुरक्षित फ़ाउंडेशन बनाएं. Cloud Storage में सिर्फ़ बकेट-लेवल की सुरक्षा की सुविधा उपलब्ध है.
- ओपन फ़ॉर्मैट, मैनेज किया गया मेटाडेटा: डेटा, Apache Iceberg (Parquet) के ओपन फ़ॉर्मैट का इस्तेमाल करके, Cloud Storage में सेव रहता है. वहीं, BigLake, मेटाडेटा को आसानी से मैनेज करता है.
- लॉजिकल सुरक्षा सीमा: सुरक्षित क्लाउड रिसोर्स कनेक्शन का इस्तेमाल करके, फ़िज़िकल स्टोरेज के ऐक्सेस को लॉजिकल डेटा ऐक्सेस से अलग किया जाता है. असली उपयोगकर्ताओं को, GCS की रॉ फ़ाइलों का सीधा फ़िज़िकल IAM ऐक्सेस कभी नहीं दिया जाता.
- ज़िरो-ट्रस्ट कंप्यूट डेलिगेशन: यह पक्का करने के लिए कि कोई भी एक्ज़ीक्यूशन इंजन, गवर्नेंस के नियमों को बायपास न कर सके, डेटा पढ़ने के सभी अनुरोधों को BigQuery Storage API के ज़रिए भेजा जाता है. यह इस बात पर लागू होता है कि क्वेरी, BigQuery के नेटिव एसक्यूएल से शुरू हुई है या ओपन-सोर्स Apache Spark से.
🎯 नीति उल्लंघन ठीक करने का तरीका (सही)
सुरक्षा से जुड़े बुनियादी ढांचे के साथ, Dataplex डेटा गवर्नेंस के लिए एक यूनीफ़ाइड प्लैटफ़ॉर्म के तौर पर काम करता है:
- एक बार तय करें और हर जगह लागू करें: Dataplex में नीति के टैग सिर्फ़ एक बार तय किए जाते हैं. इसके बाद, आर्किटेक्चर, डेटा को मास्क करने के नियमों को सभी प्लैटफ़ॉर्म पर एक जैसा लागू करता है.
- डेटा को डाइनैमिक तरीके से मास्क करना: जब डेटा के बारे में क्वेरी की जाती है, तो सिस्टम तुरंत उपयोगकर्ता की पहचान का आकलन करता है. अनुमति वाले उपयोगकर्ताओं को एसक्यूएल और स्पार्क, दोनों में बिना मास्क की गई रॉ वैल्यू (जैसे, 100.0) दिखेंगी. वहीं, जिन उपयोगकर्ताओं पर पाबंदी है उन्हें दोनों इंजन में, पाबंदी वाले कॉलम के लिए मास्क की गई NULL वैल्यू अपने-आप मिलेंगी.
- डेटा लीनेज की जानकारी अपने-आप जनरेट होना: डेटा के फ़्लो और बदलाव के साथ-साथ, Dataplex बदलाव का मेटाडेटा अपने-आप कैप्चर करता है. इससे, कस्टम लॉगिंग कोड की ज़रूरत के बिना, एंड-टू-एंड ऑडिट और ट्रेस करने की सुविधा मिलती है.
2. सेटअप और ज़रूरी शर्तें
Cloud Shell शुरू करें
Google Cloud को अपने लैपटॉप से रिमोटली ऐक्सेस किया जा सकता है. हालांकि, इस कोडलैब में Google Cloud Shell का इस्तेमाल किया जाएगा. यह क्लाउड में चलने वाला कमांड लाइन एनवायरमेंट है.
Google Cloud Console में, सबसे ऊपर दाएं कोने में मौजूद टूलबार पर, Cloud Shell आइकॉन पर क्लिक करें:
इसे चालू करने और एनवायरमेंट से कनेक्ट करने में सिर्फ़ कुछ सेकंड लगेंगे. यह प्रोसेस पूरी होने के बाद, आपको कुछ ऐसा दिखेगा:
इस वर्चुअल मशीन में, डेवलपमेंट के लिए ज़रूरी सभी टूल पहले से मौजूद हैं. यह 5 जीबी की होम डायरेक्ट्री उपलब्ध कराता है. साथ ही, यह Google Cloud पर काम करता है. इससे नेटवर्क की परफ़ॉर्मेंस और पुष्टि करने की प्रोसेस बेहतर होती है. इस कोडलैब में मौजूद सभी टास्क, ब्राउज़र में किए जा सकते हैं. आपको कुछ भी इंस्टॉल करने की ज़रूरत नहीं है.
एनवायरमेंट शुरू करें
Cloud Shell खोलें और अपने प्रोजेक्ट के वैरिएबल सेट करें, ताकि यह पक्का किया जा सके कि सभी कमांड सही इंफ़्रास्ट्रक्चर को टारगेट कर रही हैं.
export PROJECT_ID=$(gcloud config get-value project)
export REGION="us-central1"
export ICEBERG_BUCKET="iceberg-retail-demo-${PROJECT_ID}"
export DATASET_ID="lakehouse_retail_demo"
export CONN_NAME="iceberg-bq-conn-demo"
इसके बाद, हमारे दो पर्सोना तय करो.
export USER_ANALYST="retail-analyst-demo"
export EMAIL_ANALYST="${USER_ANALYST}@${PROJECT_ID}.iam.gserviceaccount.com"
export USER_MANAGER="retail-manager-demo"
export EMAIL_MANAGER="${USER_MANAGER}@${PROJECT_ID}.iam.gserviceaccount.com"
export CURRENT_USER=$(gcloud config get-value account)
एपीआई चालू करना
ज़रूरी Google Cloud सेवाएं चालू करें.
gcloud services enable \
bigquery.googleapis.com \
bigqueryconnection.googleapis.com \
datacatalog.googleapis.com \
bigquerydatapolicy.googleapis.com \
datalineage.googleapis.com \
dataplex.googleapis.com \
dataproc.googleapis.com \
storage-component.googleapis.com
कोडलैब का सोर्स कोड डाउनलोड करना
Cloud Shell को व्यवस्थित रखने के लिए, स्पार्स चेकआउट किया जाएगा. इससे, Google Cloud DevRel रिपॉज़िटरी से सिर्फ़ इस कोडलैब के लिए ज़रूरी Python स्क्रिप्ट डाउनलोड की जा सकेंगी.
# Shallow clone without full history
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
# Download only the specific folder
git sparse-checkout set data-analytics/governed-lakehouse
cd data-analytics/governed-lakehouse
स्टोरेज बनाना
बेहद सुरक्षित और मैनेज किए गए Iceberg डेटा को सेव करने के लिए बकेट बनाएं.
gcloud storage buckets create gs://${ICEBERG_BUCKET} --location=${REGION}
पहचान और सुरक्षा से जुड़ी जानकारी तैयार करना
क्लाउड रिसोर्स के कनेक्शन को कॉन्फ़िगर करें. यह ऐसी इकलौती इकाई है जिसके पास, Iceberg फ़ाइलों को पढ़ने के लिए स्थायी फ़िज़िकल IAM कुंजियां होती हैं.
# Create the BigQuery connection
bq mk --connection \
--connection_type=CLOUD_RESOURCE \
--location=${REGION} \
${CONN_NAME}
# Retrieve the connection's automatically generated Service Account
export BQ_CONN_SVC_ACCT=$(bq show --format=json --connection ${REGION}.${CONN_NAME} \
| jq -r '.cloudResource.serviceAccountId')
# Grant Storage Object Admin to the connection for the Iceberg bucket
gcloud storage buckets add-iam-policy-binding gs://${ICEBERG_BUCKET} \
--member="serviceAccount:${BQ_CONN_SVC_ACCT}" \
--role="roles/storage.objectAdmin" \
--quiet
इसके बाद, उपयोगकर्ता के पर्सोना सेट अप करें. उपयोगकर्ताओं को लॉजिकल ऐक्सेस दिया जाता है, न कि फ़िज़िकल स्टोरेज का ऐक्सेस. IAM के बदलावों को लागू होने में लगने वाले समय की वजह से होने वाली गड़बड़ियों से बचने के लिए, पहले खाते बनाएं. इसके बाद, कुछ सेकंड इंतज़ार करें और फिर उन्हें भूमिकाएं असाइन करें.
echo "Creating Service Accounts..."
for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
gcloud iam service-accounts create ${USER} --display-name="Lakehouse ${USER}"
done
echo "⏳ Waiting 15 seconds for IAM propagation..."
sleep 15
echo "Granting IAM Roles to Service Accounts..."
for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
EMAIL="${USER}@${PROJECT_ID}.iam.gserviceaccount.com"
# Allow Cloud Shell to impersonate them for testing
gcloud iam service-accounts add-iam-policy-binding ${EMAIL} \
--member="user:${CURRENT_USER}" \
--role="roles/iam.serviceAccountTokenCreator" \
--quiet
# Allow logical viewing of the catalog, querying, and running Dataproc jobs
for ROLE in "roles/datacatalog.viewer" "roles/bigquery.dataViewer" "roles/bigquery.user" "roles/bigquery.connectionUser" "roles/serviceusage.serviceUsageConsumer" "roles/dataproc.worker"; do
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${EMAIL}" \
--role="${ROLE}" \
--quiet
done
done
# Grant the Manager data creation rights
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${EMAIL_MANAGER}" \
--role="roles/bigquery.dataEditor" \
--quiet
echo "✅ Identity and Security setup completed!"
3. BigLake की मदद से, नेटिव Iceberg टेबल बनाना
मैनेज की गई Iceberg टेबल बनाने के लिए, BigLake की नेटिव क्षमताओं का इस्तेमाल किया जाएगा.
BigQuery डेटासेट बनाना
सबसे पहले, Iceberg टेबल को लॉजिक के हिसाब से ग्रुप करने के लिए, BigQuery डेटासेट बनाएं.
echo "Creating BigQuery Dataset..."
bq mk --location=${REGION} --dataset ${PROJECT_ID}:${DATASET_ID}
Iceberg टेबल बनाना
इसके बाद, टेबल बनाने के लिए ये कमांड चलाएं. OPTIONS ब्लॉक पर ध्यान दें. इसमें हमने table_format = 'ICEBERG' के बारे में बताया है. साथ ही, इसे सीधे तौर पर Cloud Storage बकेट और कनेक्शन से मैप किया है.
echo "Creating Iceberg tables..."
# Inventory table
bq query --use_legacy_sql=false \
"CREATE OR REPLACE TABLE \`${PROJECT_ID}.${DATASET_ID}.inventory\` (
product_id INT64,
product_name STRING,
stock_count INT64
)
WITH CONNECTION \`${REGION}.${CONN_NAME}\`
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'gs://${ICEBERG_BUCKET}/inventory/'
);"
# Transactions table
bq query --use_legacy_sql=false \
"CREATE OR REPLACE TABLE \`${PROJECT_ID}.${DATASET_ID}.transactions\` (
id INT64,
item STRING,
amount FLOAT64,
transaction_date DATE
)
WITH CONNECTION \`${REGION}.${CONN_NAME}\`
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'gs://${ICEBERG_BUCKET}/transactions/'
);"
टेबल में डेटा डालना
आखिर में, नई बनाई गई Iceberg टेबल में सैंपल डेटा डालें.
echo "Inserting data into Iceberg tables..."
# Insert into Inventory table
bq query --use_legacy_sql=false \
"INSERT INTO \`${PROJECT_ID}.${DATASET_ID}.inventory\` (product_id, product_name, stock_count)
VALUES (101, 'Widget A', 500), (102, 'Widget B', 250), (103, 'Widget C', 800);"
# Insert into Transactions table
bq query --use_legacy_sql=false \
"INSERT INTO \`${PROJECT_ID}.${DATASET_ID}.transactions\` (id, item, amount, transaction_date)
VALUES
(1, 'Widget A', 100.0, DATE '2024-01-01'),
(2, 'Widget B', 150.0, DATE '2024-01-02'),
(3, 'Widget C', 50.0, DATE '2024-01-03');"
अब आपके पास पूरी तरह से काम करने वाली दो आइसबर्ग टेबल हैं. BigLake, मेटाडेटा को मैनेज करता है. हालांकि, Parquet फ़ाइलें आपके GCS बकेट में सुरक्षित तरीके से मौजूद रहती हैं!
ईटीएल पाइपलाइन को सिम्युलेट करना
असल दुनिया में, कारोबार की रिपोर्टिंग के लिए अक्सर रॉ डेटा को खास जानकारी वाली टेबल में एग्रीगेट किया जाता है. हम डेटा इंजीनियर की भूमिका निभाते हैं और लेन-देन के रॉ डेटा से, रोज़ाना की बिक्री की खास जानकारी वाली टेबल बनाते हैं.
(ध्यान दें: इस चरण को अभी पूरा करें, ताकि Google Cloud के पास बैकग्राउंड मेटाडेटा को प्रोसेस करने के लिए काफ़ी समय हो. आपको कोडलैब में आगे पता चलेगा कि यह क्यों ज़रूरी है!)
echo "Creating transactions summary table..."
bq query --use_legacy_sql=false \
"CREATE TABLE \`${PROJECT_ID}.${DATASET_ID}.transactions_summary\` AS
SELECT transaction_date, SUM(amount) as total_sales, COUNT(id) as transaction_count
FROM \`${PROJECT_ID}.${DATASET_ID}.transactions\`
GROUP BY transaction_date;"
4. एक ही जगह से कंट्रोल करने की सुविधा: Python का इस्तेमाल करके नीतियां तय करना
प्रोडक्शन एनवायरमेंट में, यूज़र इंटरफ़ेस (यूआई) के ज़रिए गवर्नेंस की नीतियां कॉन्फ़िगर करना मुश्किल होता है. इसके बजाय, हमारा सुझाव है कि आप इंफ़्रास्ट्रक्चर ऐज़ कोड (आईएसी) का इस्तेमाल करें.
इस सेक्शन में, Google Cloud Python SDK का इस्तेमाल करके, प्रोग्राम के हिसाब से ज़ीरो-ट्रस्ट गवर्नेंस के नियमों को सिलसिलेवार तरीके से बनाया और लागू किया जाएगा.
Python एनवायरमेंट सेट अप करना
सबसे पहले, लाइब्रेरी के टकराव से बचने के लिए, एक अलग Python एनवायरमेंट (venv) सेट अप करें. इसके बाद, ज़रूरी Google Cloud SDK टूल इंस्टॉल करें.
Cloud Shell में ये कमांड चलाएं:
# Create and activate a virtual environment
python3 -m venv lakehouse_env
source lakehouse_env/bin/activate
# Install required Dataplex and BigQuery governance libraries
pip install google-cloud-datacatalog google-cloud-bigquery-datapolicies google-cloud-bigquery --quiet
echo "✅ Python environment is ready!"
टैक्सोनॉमी और नीति टैग बनाना
टैक्सोनॉमी एक लॉजिकल कंटेनर होता है. वहीं, नीति टैग वह खास लेबल होता है जिसे आपको संवेदनशील कॉलम से जोड़ना होता है. कॉलम-लेवल की सुरक्षा लागू करने के लिए, आपको सबसे पहले लॉजिकल कंटेनर (टैक्सोनॉमी) और खास लेबल (नीति टैग) की ज़रूरत होती है.
1_create_taxonomy.py में आपको यह मुख्य लॉजिक दिखेगा:
# Create Taxonomy with Fine-Grained Access Control enabled
taxonomy = datacatalog_v1.Taxonomy(
display_name="BusinessCritical",
activated_policy_types=[datacatalog_v1.Taxonomy.PolicyType.FINE_GRAINED_ACCESS_CONTROL]
)
created_taxonomy = client.create_taxonomy(parent=parent, taxonomy=taxonomy)
# Create Policy Tag inside the Taxonomy
policy_tag = datacatalog_v1.PolicyTag(display_name="RestrictedFinancial")
created_policy_tag = client.create_policy_tag(parent=created_taxonomy.name, policy_tag=policy_tag)
FINE_GRAINED_ACCESS_CONTROL नीति का टाइप साफ़ तौर पर सेट करके, स्टैंडर्ड मेटाडेटा टैग को ज़ीरो-ट्रस्ट सुरक्षा सीमा में बदला जा सकता है. इस टैग वाले किसी भी कॉलम को डिफ़ॉल्ट रूप से, सभी उपयोगकर्ताओं के लिए ऐक्सेस नहीं किया जा सकेगा.
संसाधन बनाने के लिए, स्क्रिप्ट चलाएं:
python 1_create_taxonomy.py
मास्किंग के नियम (डेटा से जुड़ी नीति) को कॉन्फ़िगर करना
अब आपको यह तय करना होगा कि टैग किए गए कॉलम के लिए, बिना अनुमति वाला कोई व्यक्ति क्वेरी करता है, तो क्या होगा. आपको एक डेटा नीति बनानी होगी, ताकि वैल्यू को NULL के तौर पर दिखाया जा सके. इसके बाद, इस नियम को विश्लेषक पर्सोना से जोड़ना होगा.
2_create_masking.py में, स्क्रिप्ट अभी बनाए गए नीति टैग आईडी को डाइनैमिक तौर पर ढूंढती है और डेटा से जुड़ी नीति लागू करती है:
# Define a Masking Policy that always returns NULL
data_policy = bigquery_datapolicies_v1.DataPolicy(
data_policy_id="mask_financial_null",
policy_tag=policy_tag_id,
data_policy_type=bigquery_datapolicies_v1.DataPolicy.DataPolicyType.DATA_MASKING_POLICY,
data_masking_policy=bigquery_datapolicies_v1.DataMaskingPolicy(
predefined_expression=bigquery_datapolicies_v1.DataMaskingPolicy.PredefinedExpression.ALWAYS_NULL
)
)
# ... (Policy creation code) ...
# Bind the Masked Reader role to the Analyst
iam_policy.bindings.add(
role="roles/bigquerydatapolicy.maskedReader",
members=[f"serviceAccount:{analyst_email}"]
)
यह कोड, प्रोग्राम के हिसाब से एक ऐसा नियम बनाता है जिससे बुनियादी वैल्यू को NULL के तौर पर दिखाया जाता है. इसके बाद, यह Analyst persona को maskedReader IAM भूमिका असाइन करता है. इससे यह पक्का होता है कि वे सिर्फ़ डेटा का मास्किंग किया गया वर्शन देख सकें.
मास्किंग का नियम कॉन्फ़िगर करने के लिए, स्क्रिप्ट चलाएं:
python 2_create_masking.py
ज़्यादा बेहतर तरीके से ऐक्सेस देना
ज़िरो-ट्रस्ट सेटअप की वजह से, फ़िलहाल कोई भी टैग किए गए कॉलम को नहीं पढ़ सकता. आपको मैनेजर खाते और अपने निजी खाते को ऐक्सेस करने की अनुमति देनी होगी.
3_grant_access.py में, नीति टैग की आईएएम नीति में बदलाव किया जाता है:
# Grant original data read access
iam_policy.bindings.add(
role="roles/datacatalog.categoryFineGrainedReader",
members=[f"serviceAccount:{manager_email}", f"user:{current_user}"]
)
client.set_iam_policy(request=iam_policy_pb2.SetIamPolicyRequest(resource=policy_tag_id, policy=iam_policy))
categoryFineGrainedReader की भूमिका जोड़ने से, इन खास प्रिंसिपल को मास्किंग के नियमों को बायपास करने और बिना मास्क किए गए रॉ डेटा को पढ़ने की अनुमति मिलती है.
ऐक्सेस देने के लिए, स्क्रिप्ट चलाएं:
python 3_grant_access.py
BigQuery टेबल में नीति टैग अटैच करना
आखिर में, आपको इस लॉजिकल नीति टैग को हमारे फ़िज़िकल आइसबर्ग टेबल स्कीमा से अटैच करना होगा.
4_attach_tag.py पर एक नज़र डालें. यह स्क्रिप्ट, BigQuery टेबल स्कीमा को फ़ेच करती है. इसके बाद, फ़ील्ड में बदलाव करती है और टैग को खास तौर पर amount कॉलम से जोड़ती है:
new_schema =[]
for field in table.schema:
if field.name == 'amount':
# Wrap the Policy Tag ID and attach it to the column
policy_tags_list = bigquery.PolicyTagList(names=[policy_tag_id])
new_field = bigquery.SchemaField(
name=field.name, field_type=field.field_type, mode=field.mode,
description=field.description, policy_tags=policy_tags_list
)
new_schema.append(new_field)
else:
new_schema.append(field)
# Update the table schema in BigQuery
table.schema = new_schema
client.update_table(table, ["schema"])
स्कीमा अपडेट लागू होने के बाद, BigLake हमारे Dataplex लॉजिकल टैग को आपके Cloud Storage बकेट में सेव की गई फ़िज़िकल Parquet फ़ाइलों से तुरंत कनेक्ट कर देता है.
टेबल स्कीमा को अपडेट करने के लिए, स्क्रिप्ट चलाएं:
python 4_attach_tag.py
5. Dataplex की नीतियों की पुष्टि करना
अब यह जांच करने का समय है कि हमारा सेंट्रलाइज़्ड गवर्नेंस काम करता है या नहीं. आपको यह जांच करनी होगी कि Dataplex की नीतियां, सभी इंजन पर लागू होती हैं. इसके लिए, आपको दो अलग-अलग इंजन पर यह जांच करनी होगी.
BigQuery के नेटिव एसक्यूएल का इस्तेमाल करके पुष्टि करना
सबसे पहले, Cloud Shell का इस्तेमाल करके, हमारे दो पर्सोना की पहचान की जाएगी. इसके बाद, BigQuery के नेटिव एसक्यूएल इंजन का इस्तेमाल करके टेबल से क्वेरी की जाएगी.
मैनेजर (खास अधिकार वाला उपयोगकर्ता) के तौर पर टेस्ट करें:
# Impersonate the manager
gcloud config set auth/impersonate_service_account ${EMAIL_MANAGER}
# Query the transactions table
bq query --use_legacy_sql=false "SELECT * FROM \`${PROJECT_ID}.${DATASET_ID}.transactions\`"
मैनेजर के पास फ़ाइन-ग्रेन्ड रीडर की भूमिका है. इसलिए, उसे रकम की असल वैल्यू दिखेंगी
+----+----------+--------+------------------+
| id | item | amount | transaction_date |
+----+----------+--------+------------------+
| 1 | Widget A | 100.0 | 2024-01-01 |
| 3 | Widget C | 50.0 | 2024-01-03 |
| 2 | Widget B | 150.0 | 2024-01-02 |
+----+----------+--------+------------------+
विश्लेषक (पाबंदी वाला उपयोगकर्ता) के तौर पर टेस्ट करें:
gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}
bq query --use_legacy_sql=false "SELECT * FROM \`${PROJECT_ID}.${DATASET_ID}.transactions\`"
Dataplex के मास्किंग नियम की वजह से, हर लाइन के लिए 'राशि' कॉलम में NULL दिखता है.
+----+----------+--------+------------------+
| id | item | amount | transaction_date |
+----+----------+--------+------------------+
| 1 | Widget A | NULL | 2024-01-01 |
| 3 | Widget C | NULL | 2024-01-03 |
| 2 | Widget B | NULL | 2024-01-02 |
+----+----------+--------+------------------+
अपनी पहचान वापस पाना
अपने Cloud Shell की पुष्टि करने की स्थिति को साफ़ करें, ताकि एडमिन उपयोगकर्ता के तौर पर वापस आ सकें.
# Unset impersonation
gcloud config unset auth/impersonate_service_account
Apache Spark (Compute delegation) का इस्तेमाल करके पुष्टि करना
अगर कोई डेटा साइंटिस्ट इस टेबल को पढ़ने के लिए Apache Spark का इस्तेमाल करता है, तो क्या होगा? अगर Spark, GCS की Parquet फ़ाइलों को सीधे तौर पर पढ़ता है, तो Dataplex के मास्किंग नियमों को पूरी तरह से अनदेखा कर दिया जाता है. ऐसा इसलिए होता है, क्योंकि Cloud Storage सिर्फ़ बकेट-लेवल की अनुमतियों को समझता है.
इससे बचने के लिए, Spark-BigQuery Connector का इस्तेमाल करके, कंप्यूट डेलिगेशन लागू किया जाता है. यह कनेक्टर, सुरक्षित ब्रिज के तौर पर काम करता है. यह Spark के रीड अनुरोधों को BigQuery Storage API के ज़रिए रूट करता है, ताकि Dataplex के गवर्नेंस के नियमों का आकलन, Spark क्लस्टर को कोई भी डेटा भेजने से पहले किया जा सके.
डाउनलोड की गई read_transactions.py स्क्रिप्ट में मौजूद मुख्य लॉजिक देखें:
# Reading data via Compute Delegation (Dataplex policies are applied dynamically here)
df = spark.read \
.format("bigquery") \
.option("table", f"{project_id}.{dataset_id}.{table_name}") \
.load()
print("\n=== 📊 Data Preview ===")
df.show(truncate=False)
ध्यान दें कि हम Spark को Iceberg फ़ाइलों के gs:// पाथ के बारे में नहीं बता रहे हैं. .format("bigquery") को तय करने पर, BigQuery Storage API, पढ़ने के अनुरोध को इंटरसेप्ट करता है. साथ ही, Spark जॉब चलाने वाले उपयोगकर्ता की पहचान की पुष्टि करता है. इसके बाद, Dataplex के मास्किंग के नियमों को लागू करता है. इसके बाद, सिर्फ़ अनुमति वाला डेटा, Spark DataFrame को वापस भेजता है.
इस PySpark स्क्रिप्ट को अपनी Cloud Storage बकेट में अपलोड करें, ताकि Dataproc इसे ऐक्सेस कर सके:
# Upload script to GCS
gsutil cp read_transactions.py gs://${ICEBERG_BUCKET}/scripts/read_transactions.py
मैनेजर के तौर पर Spark चलाएं:
Google Cloud Serverless for Apache Spark का इस्तेमाल किया जाएगा. इस मैनेज की गई सेवा की मदद से, सीधे तौर पर Spark वर्कलोड चलाए जा सकते हैं. इसके लिए, आपको अलग से क्लस्टर बनाने, कॉन्फ़िगर करने या मैनेज करने की ज़रूरत नहीं होती.
echo "🚀 Submitting Dataproc Serverless Job as [MANAGER]..."
gcloud dataproc batches submit pyspark gs://${ICEBERG_BUCKET}/scripts/read_transactions.py \
--project=${PROJECT_ID} \
--region=${REGION} \
--service-account=${EMAIL_MANAGER} \
--version=2.3 \
-- ${PROJECT_ID} ${DATASET_ID} \
--format="value(name)"
टर्मिनल में, जॉब आउटपुट लॉग देखें. मैनेजर के पास फ़ाइन-ग्रेन्ड रीडर की भूमिका है. इसलिए, Spark बिना मास्क किए गए डेटा को आसानी से ऐक्सेस कर सकता है.
=== 📊 Data Preview ===
+---+--------+------+-------------------+
|id |item |amount|transaction_date |
+---+--------+------+-------------------+
|1 |Widget A|100.0 |2024-01-01 |
|2 |Widget B|150.0 |2024-01-02 |
|3 |Widget C|50.0 |2024-01-03 |
+---+--------+------+-------------------+
ऐनलिस्ट के तौर पर Spark चलाएं:
अब, उसी Spark जॉब को सबमिट करें. हालांकि, इस बार विश्लेषक की भूमिका में काम करें.
echo "🚀 Submitting Dataproc Serverless Job as [ANALYST]..."
gcloud dataproc batches submit pyspark gs://${ICEBERG_BUCKET}/scripts/read_transactions.py \
--project=${PROJECT_ID} \
--region=${REGION} \
--service-account=${EMAIL_ANALYST} \
--version=2.3 \
-- ${PROJECT_ID} ${DATASET_ID} \
--format="value(name)"
लॉग फिर से देखें. विश्लेषक ने भले ही एक जैसा Spark कोड चलाया हो, लेकिन BigQuery Storage API ने अनुरोध को इंटरसेप्ट कर लिया और Dataplex की नीति लागू कर दी. विश्लेषक के Spark DataFrame में, रकम के लिए null दिखता है!
=== 📊 Data Preview ===
+---+--------+------+-------------------+
|id |item |amount|transaction_date |
+---+--------+------+-------------------+
|1 |Widget A|null |2024-01-01 |
|2 |Widget B|null |2024-01-02 |
|3 |Widget C|null |2024-01-03 |
+---+--------+------+-------------------+
आर्किटेक्चर से जुड़ी कमियां: BigQuery SQL बनाम Spark
आपने अभी-अभी यह साबित किया है कि इंजन कोई भी हो, नतीजा एक जैसा ही होता है! Dataplex की नीति लागू कर दी गई है. हालांकि, प्रोडक्शन में आपको किसका इस्तेमाल करना चाहिए?
- BigQuery एसक्यूएल: यह उन वर्कफ़्लो के लिए सबसे सही है जहां एसक्यूएल का इस्तेमाल किया जाता है. साथ ही, यह सीधे तौर पर कंप्यूटेशन करता है. यह तेज़ गति से आंकड़ों का विश्लेषण करने और बिज़नेस इंटेलिजेंस के लिए सबसे सही है.
- Apache Spark: यह Python का इस्तेमाल करता है. इसलिए, इससे ज़्यादा जटिल वर्कलोड को मैनेज किया जा सकता है. इस वजह से, यह ऐडवांस मशीन लर्निंग पाइपलाइन या लेगसी Hadoop कोड के लिए सबसे सही है.
मुख्य जानकारी: चाहे किसी भी इंजन का इस्तेमाल किया गया हो, कंप्यूट डेलिगेशन लागू करने पर, ज़ीरो-ट्रस्ट गवर्नेंस लेयर को कभी भी बायपास नहीं किया जा सकता!
6. डेटा लीनिएज की जानकारी अपने-आप जनरेट होना
किसी भी एंटरप्राइज़ डेटा आर्किटेक्चर में, यह जानना ज़रूरी होता है कि आपका डेटा कहां से आया है और इसमें कैसे बदलाव किया गया है. इससे नियमों का पालन करने, डीबग करने, और भरोसा कायम करने में मदद मिलती है. इस कॉन्सेप्ट को डेटा लीनेज कहा जाता है. इससे बुनियादी सवालों के जवाब मिलते हैं. जैसे: "अगर कोई मैनेजर, रोज़ की बिक्री की रिपोर्ट देख रहा है, तो उन नंबरों का हिसाब लगाने के लिए किन रॉ टेबल का इस्तेमाल किया गया था?"
आम तौर पर, इस लाइफ़साइकल को ट्रैक करने के लिए, डेटा इंजीनियर को मैन्युअल तरीके से कस्टम लॉगिंग कोड लिखना होता है. इसके अलावा, वे एसक्यूएल स्क्रिप्ट को पार्स करने के लिए, तीसरे पक्ष के जटिल टूल का इस्तेमाल कर सकते हैं. हालांकि, मैनेज किए जा रहे Google Cloud Lakehouse में, यह ट्रैकिंग पहले से मौजूद होती है और इसे मैनेज करने की ज़रूरत नहीं होती.
क्या आपको याद है कि आपने कोडलैब में पहले रॉ ट्रांज़ैक्शन टेबल से transactions_summary टेबल बनाई थी? जब BigQuery ने उस CREATE TABLE AS SELECT स्टेटमेंट को लागू किया, तो Compute Engine ने ट्रांसफ़ॉर्मेशन मेटाडेटा को अपने-आप कैप्चर कर लिया और उसे Dataplex को भेज दिया. चलिए, नतीजे देखते हैं.
डेटा सोर्स का लीनेज विज़ुअलाइज़ करना
- Google Cloud Console में, Dataplex यूनिवर्सल कैटलॉग > खोजें पर जाएं.
- खोज बार में
lakehouse_retail_demo.transactionsटाइप करें और टेबल पर क्लिक करें. - डेटा सोर्स की जानकारी टैब पर क्लिक करें.
आपको Dataplex Knowledge Engine से जनरेट किया गया एक इंटरैक्टिव ग्राफ़ दिखेगा. इससे यह साबित होता है कि टारगेट टेबल (transactions_summary) को, रॉ गवर्न्ड आइसबर्ग टेबल (transactions) से लिया गया है. आपने डेटा ऑडिटिंग के लिए ज़रूरी एंड-टू-एंड ट्रेसबिलिटी हासिल कर ली है.
7. व्यवस्थित करें
इस कोडलैब में इस्तेमाल किए गए संसाधनों के लिए, अपने Google Cloud खाते से शुल्क न लिए जाने के लिए, यह तरीका अपनाएं.
Dataplex के गवर्नेंस रिसॉर्स हटाना
BigQuery डेटासेट या Cloud Storage बकेट को मिटाने से पहले, आपको लॉजिकल गवर्नेंस के नियमों को हटाना होगा. अगर आपको रिपॉज़िटरी से cleanup_governance.py स्क्रिप्ट में यह जानकारी मिलती है, तो आपको यह टीयर्डाउन सीक्वेंस दिखेगा:
# 1. Delete Data Policy
data_policy_name = f"{parent_loc}/dataPolicies/mask_financial_null"
dp_client.delete_data_policy(name=data_policy_name)
# 2. Find and Delete Taxonomy (This auto-deletes child Policy Tags)
taxonomies = catalog_client.list_taxonomies(parent=parent_loc)
taxonomy_id = next((t.name for t in taxonomies if t.display_name == "BusinessCritical"), None)
catalog_client.delete_taxonomy(name=taxonomy_id)
यहां क्रम का ध्यान रखना ज़रूरी है. स्क्रिप्ट, सबसे पहले डेटा नीति (मास्किंग का नियम) को मिटाती है, क्योंकि यह नीति के टैग पर निर्भर करती है. नीति हटा दिए जाने के बाद, पैरंट टैक्सोनॉमी को मिटाने पर, उससे जुड़ी सभी नीतियां अपने-आप मिट जाएंगी. साथ ही, संसाधन की निर्भरता से जुड़ी गड़बड़ियां भी नहीं दिखेंगी.
Python की क्लीनअप स्क्रिप्ट चलाएं:
python cleanup_governance.py
पहचान, स्टोरेज, और कंप्यूट ऐसेट हटाना
गवर्नेंस लेयर अलग होने के बाद, BigQuery टेबल, Cloud Storage बकेट, सेवा खाते, और लोकल Python एनवायरमेंट को सुरक्षित तरीके से मिटाया जा सकता है.
अपने Cloud Shell में, यहां दिए गए पूरे क्लीनअप ब्लॉक को कॉपी करें और चलाएं:
echo "Deleting Service Accounts and Impersonation Bindings..."
export CURRENT_USER=$(gcloud config get-value account)
for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
EMAIL="${USER}@${PROJECT_ID}.iam.gserviceaccount.com"
# Remove impersonation binding
gcloud iam service-accounts remove-iam-policy-binding ${EMAIL} \
--member="user:${CURRENT_USER}" \
--role="roles/iam.serviceAccountTokenCreator" \
--quiet > /dev/null 2>&1
# Delete the Service Account
gcloud iam service-accounts delete ${EMAIL} --quiet
done
echo "Removing BigQuery Dataset and Tables..."
bq rm -f ${DATASET_ID}.transactions_summary
bq rm -f ${DATASET_ID}.transactions
bq rm -f ${DATASET_ID}.inventory
bq rm -f -d ${DATASET_ID}
echo "Removing BigQuery Cloud Resource Connection..."
bq rm --connection --location=${REGION} ${CONN_NAME}
echo "Removing Iceberg Cloud Storage Bucket..."
gcloud storage rm --recursive gs://${ICEBERG_BUCKET} --quiet
echo "Removing Auto-generated Dataproc Staging & Temp Buckets..."
for BUCKET in $(gcloud storage ls | grep -E "gs://dataproc-(staging|temp)-${REGION}"); do
gcloud storage rm --recursive $BUCKET --quiet
done
echo "Deactivating and removing the local Python environment..."
deactivate
cd ../..
rm -rf devrel-demos
echo "✅ Clean up completed successfully!"
इन चरणों को पूरा करने के बाद, यह पक्का हो जाता है कि आपके प्रोजेक्ट में कोई अनाथ संसाधन या छिपी हुई नीतियां मौजूद नहीं हैं.
8. बधाई हो!
आपने पूरी तरह से मैनेज किया जाने वाला, खोजा जा सकने वाला डेटा लेकहाउस लागू कर दिया है.
आपने सीखा कि:
- नेटिव आइसबर्ग इंटिग्रेशन: BigLake, ओपन-सोर्स आइसबर्ग टेबल को नेटिव तरीके से मैनेज कर सकता है. साथ ही, फ़िज़िकल फ़ाइलों को Cloud Storage में सुरक्षित तरीके से सेव कर सकता है.
- सुरक्षा के लिए कंप्यूट डेलिगेशन: BigQuery Storage API के ज़रिए क्वेरी को रूट करके, आपने फ़िज़िकल फ़ाइलों पर फ़ाइन-ग्रेन्ड डाइनैमिक मास्किंग लागू की. इन फ़ाइलों में, आंशिक ऐक्सेस को मूल रूप से प्रतिबंधित नहीं किया जा सकता.
- इंजन से जुड़ी पाबंदियां नहीं: नीति के टैग की मदद से, नियमों को एक बार तय किया जा सकता है. इसके बाद, उन्हें हर जगह लागू किया जा सकता है. भले ही, क्वेरी नेटिव एसक्यूएल या Apache Spark रनटाइम के ज़रिए की गई हो.
- डेटा की खोज: Dataplex Knowledge Engine, डेटा लीनेज को अपने-आप ट्रैक करता है. इससे एंटरप्राइज़ ऑडिट के लिए ज़रूरी जानकारी मिलती है.
आगे क्या करना है?
- ऐडवांस ऐक्सेस कंट्रोल के बारे में जानें: सुरक्षा से जुड़े ज़्यादा मुश्किल मामलों को लागू करने के लिए, ज़्यादा सुविधाओं के साथ BigLake को पसंद के मुताबिक बनाने के बारे में आधिकारिक दस्तावेज़ पढ़ें.
- जनरेटिव एआई के लिए, अनस्ट्रक्चर्ड डेटा को मैनेज करना: BigLake ऑब्जेक्ट टेबल के बारे में जानें. इस सिक्योर ब्रिज पैटर्न को Cloud Storage में मौजूद बिना स्ट्रक्चर वाली फ़ाइलों (PDF, इमेज) के लिए भी इस्तेमाल करें. इससे Vertex AI और RAG पाइपलाइन के लिए, सुरक्षित और नियंत्रित डेटा फ़ाउंडेशन तैयार किया जा सकेगा.