1. Giriş
Bu codelab, veri uzmanları için teknik bir plan sunar. Veri yönetimi için "önce kod" yaklaşımını özetler ve güçlü kalite ile meta veri yönetiminin doğrudan geliştirme yaşam döngüsüne nasıl yerleştirileceğini gösterir. Knowledge Catalog, temel olarak akıllı bir veri dokusu görevi görür. Kuruluşların, veri göllerinden depolara kadar tüm mülklerindeki verileri merkezi olarak yönetmesini, izlemesini ve yönetmesini sağlar.
Bu codelab'de, karmaşık verileri düzleştirmek, programatik olarak profillendirmek, akıllı veri kalitesi kuralı önerileri oluşturmak ve otomatik kalite taramaları dağıtmak için Knowledge Catalog, BigQuery ve Antigravity CLI'nin nasıl kullanılacağı gösterilmektedir. Buradaki temel amaç, hataya açık ve ölçeklendirilmesi zor olan manuel, kullanıcı arayüzü odaklı süreçlerin ötesine geçerek bunun yerine sağlam, sürüm kontrollü bir "kod olarak politika" çerçevesi oluşturmaktır.
Neler öğreneceksiniz?
- Kapsamlı profilleme sağlamak için gerçekleştirilmiş görünümleri kullanarak iç içe yerleştirilmiş BigQuery verilerini düzleştirme
- Knowledge Catalog Python istemci kitaplığını kullanarak Knowledge Catalog profil taramalarını programatik olarak nasıl tetikleyip yöneteceğinizi öğrenin.
- Profil verilerini dışa aktarma ve üretken yapay zeka modeli için giriş olarak yapılandırma
- Antigravity CLI'da profil verilerini analiz etmek ve Knowledge Catalog ile uyumlu bir YAML kural dosyası oluşturmak için istem mühendisliği yapma
- Yapay zeka tarafından oluşturulan yapılandırmaları doğrulamak için etkileşimli, sürece insanı da dahil eden (HITL) bir sürecin önemi.
- Oluşturulan kuralları otomatik veri kalitesi taraması olarak dağıtma
İhtiyacınız olanlar
- Google Cloud hesabı ve Google Cloud projesi
- Chrome gibi bir web tarayıcısı
Temel kavramlar: Knowledge Catalog veri kalitesinin temel unsurları
Etkili bir veri kalitesi stratejisi oluşturmak için Bilgi Kataloğu'nun temel bileşenlerini anlamak önemlidir.
- Veri Profili Taraması: Verileri analiz eden ve boş değer yüzdeleri, farklı değer sayıları ve değer dağılımları gibi istatistiksel meta veriler oluşturan bir Bilgi Kataloğu işidir. Bu, programatik "keşif" aşamamız olarak işlev görür.
- Veri Kalitesi Kuralları: Verilerinizin karşılaması gereken koşulları tanımlayan bildirimsel ifadeler (ör.
NonNullExpectation,SetExpectation,RangeExpectation). - Kural Önerisi için Üretken Yapay Zeka: Bir veri profilini analiz etmek ve alakalı veri kalitesi kuralları önermek için büyük bir dil modeli (ör. Gemini) kullanma. Bu, temel kalite çerçevesi tanımlama sürecini hızlandırır.
- Veri Kalitesi Taraması: Verileri önceden tanımlanmış veya özel bir dizi kurala göre doğrulayan bir Knowledge Catalog işi.
- Programatik Yönetim: Yönetim kontrollerini (ör.kalite kuralları) kod olarak (ör. YAML dosyalarında ve Python komut dosyalarında) yönetmenin temel teması. Bu sayede otomasyon, sürüm oluşturma ve CI/CD ardışık düzenlerine entegrasyon sağlanır.
- Sürece İnsan Dahil Etme (HITL): İnsan uzmanlığını ve gözetimini otomatik bir iş akışına entegre etmenin kritik kontrol noktasıdır. Yapay zeka tarafından oluşturulan yapılandırmalarda, önerilerin doğruluğunu, işletmeyle alakasını ve güvenliğini dağıtımdan önce doğrulamak için HITL gereklidir.
2. Kurulum ve şartlar
Cloud Shell'i Başlatma
Google Cloud, dizüstü bilgisayarınızdan uzaktan çalıştırılabilir ancak bu codelab'de Cloud'da çalışan bir komut satırı ortamı olan Google Cloud Shell'i kullanacaksınız.
Google Cloud Console'da sağ üstteki araç çubuğunda Cloud Shell simgesini tıklayın:
Ortamın temel hazırlığı ve bağlantı kurulması yalnızca birkaç dakikanızı alır. İşlem tamamlandığında aşağıdakine benzer bir sonuç görürsünüz:
Bu sanal makine, ihtiyaç duyacağınız tüm geliştirme araçlarıyla birlikte gelir. 5 GB boyutunda kalıcı bir ana dizin sunar ve Google Cloud üzerinde çalışır. Bu sayede ağ performansı ve kimlik doğrulama önemli ölçüde güçlenir. Bu codelab'deki tüm çalışmalarınızı tarayıcıda yapabilirsiniz. Herhangi bir şey yüklemeniz gerekmez.
Gerekli API'leri etkinleştirme ve ortamı yapılandırma
Cloud Shell'de proje kimliğinizin ayarlandığından emin olun:
export PROJECT_ID=$(gcloud config get-value project)
gcloud config set project $PROJECT_ID
export LOCATION="us-central1"
export BQ_LOCATION="us"
export DATASET_ID="kc_dq_codelab"
export TABLE_ID="ga4_transactions"
gcloud services enable dataplex.googleapis.com \
bigquery.googleapis.com \
serviceusage.googleapis.com \
aiplatform.googleapis.com
Kullanacağımız herkese açık örnek veriler de us (çok bölgeli) konumunda bulunduğundan örnekte konum olarak us (çok bölgeli) kullanıyoruz. BigQuery, bir sorgunun kaynak verilerinin ve hedef tablosunun aynı konumda bulunmasını gerektirir.
Özel bir BigQuery veri kümesi oluşturma
Örnek verilerimizi ve sonuçlarımızı barındıracak yeni bir BigQuery veri kümesi oluşturun.
bq --location=us mk --dataset $PROJECT_ID:$DATASET_ID
Örnek verileri hazırlama
Bu codelab'de, Google Merchandise Store'dan alınmış ve kod karartma uygulanmış e-ticaret verilerini içeren herkese açık bir veri kümesi kullanacaksınız. Herkese açık veri kümeleri salt okunur olduğundan kendi veri kümenizde değiştirilebilir bir kopya oluşturmanız gerekir. Aşağıdaki bq komutu, kc_dq_codelab veri kümenizde yeni bir tablo (ga4_transactions) oluşturur. Tarama işlemlerinin hızlı bir şekilde çalışmasını sağlamak için tek bir güne (2021-01-31) ait verileri kopyalar.
bq query \
--use_legacy_sql=false \
--destination_table=$PROJECT_ID:$DATASET_ID.$TABLE_ID \
--replace=true \
'SELECT * FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_20210131`'
Demo dizinini ayarlama
Başlamak için bu codelab'de gerekli klasör yapısını ve destekleyici dosyaları içeren bir GitHub deposunu klonlayacaksınız.
# Perform a shallow clone to get only the latest repository structure without the full history
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
# Specify and download only the folder we need for this lab
git sparse-checkout set data-analytics/programmatic-dq
cd data-analytics/programmatic-dq
Bu dizin artık etkin çalışma alanınızdır. Sonraki tüm dosyalar burada oluşturulur.
3. Knowledge Catalog profilleme ile otomatik veri keşfi
Knowledge Catalog veri profili oluşturma, verilerinizle ilgili istatistiksel bilgileri (ör. boş değer yüzdeleri, benzersizlik ve değer dağılımları) otomatik olarak keşfetmek için kullanılan güçlü bir araçtır. Bu işlem, verilerinizin yapısını ve kalitesini anlamak için gereklidir. Ancak Bilgi Kataloğu profillemesinin bilinen bir sınırlaması, bir tablodaki iç içe yerleştirilmiş veya tekrarlanan alanları (ör. RECORD veya ARRAY türleri) tam olarak inceleyememesidir. Bir sütunun karmaşık bir tür olduğunu belirleyebilir ancak bu iç içe yerleştirilmiş yapıdaki tek tek alanları profillendiremez.
Bunun üstesinden gelmek için verileri amaca yönelik olarak oluşturulmuş somutlaştırılmış görünümlere dönüştüreceğiz. Bu strateji, her alanı üst düzey bir sütun haline getirerek Bilgi Kataloğu'nun her birini ayrı ayrı profillemesini sağlar.
İç içe yerleştirilmiş şemayı anlama
Öncelikle kaynak tablomuzun şemasını inceleyelim. Google Analytics 4 (GA4) veri kümesi, iç içe yerleştirilmiş ve tekrarlanan çeşitli sütunlar içerir. Tüm iç içe yerleştirilmiş yapılar da dahil olmak üzere tam şemayı programatik olarak almak için bq show komutunu kullanabilir ve çıkışı JSON dosyası olarak kaydedebilirsiniz.
bq show --schema --format=json $PROJECT_ID:$DATASET_ID.$TABLE_ID > bq_schema.json
bq_schema.json dosyası incelendiğinde cihaz, coğrafi konum, e-ticaret gibi karmaşık yapılar ve tekrarlanan kayıt öğeleri ortaya çıkıyor. Bunlar, etkili profilleme için düzleştirilmesi gereken yapılardır.
Gerçekleştirilmiş görünümlerle verileri düzleştirme
Gerçekleştirilmiş görünümler (MV'ler) oluşturmak, bu iç içe yerleştirilmiş veri sorununa yönelik en etkili ve pratik çözümdür. Düzleştirilmiş sonuçları önceden hesaplayan M'ler, sorgu performansı ve maliyet açısından önemli avantajlar sunarken analistler ve profilleme araçları için daha basit, ilişkisel benzeri bir yapı sağlar.
İlk olarak her şeyi tek bir devasa görünümde birleştirmek isteyebilirsiniz. Ancak bu sezgisel yaklaşım, ciddi veri bozulmasına yol açabilecek tehlikeli bir tuzak barındırır. Bunun neden kritik bir hata olduğunu inceleyelim.
mv_ga4_user_session_flat.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_user_session_flat`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 30
) AS
SELECT
event_date, event_timestamp, event_name, user_pseudo_id, user_id, stream_id, platform,
device.category AS device_category,
device.operating_system AS device_os,
device.operating_system_version AS device_os_version,
device.language AS device_language,
device.web_info.browser AS device_browser,
geo.continent AS geo_continent,
geo.country AS geo_country,
geo.region AS geo_region,
geo.city AS geo_city,
traffic_source.name AS traffic_source_name,
traffic_source.medium AS traffic_source_medium,
traffic_source.source AS traffic_source_source
FROM
`$PROJECT_ID.$DATASET_ID.ga4_transactions`;
mv_ga4_ecommerce_transactions.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_ecommerce_transactions`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 30
) AS
SELECT
event_date, event_timestamp, user_pseudo_id, ecommerce.transaction_id,
ecommerce.total_item_quantity,
ecommerce.purchase_revenue_in_usd,
ecommerce.purchase_revenue,
ecommerce.refund_value_in_usd,
ecommerce.refund_value,
ecommerce.shipping_value_in_usd,
ecommerce.shipping_value,
ecommerce.tax_value_in_usd,
ecommerce.tax_value,
ecommerce.unique_items
FROM
`$PROJECT_ID.$DATASET_ID.ga4_transactions`
WHERE
ecommerce.transaction_id IS NOT NULL;
mv_ga4_ecommerce_items.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_ecommerce_items`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 30
) AS
SELECT
event_date, event_timestamp, event_name, user_pseudo_id, ecommerce.transaction_id,
item.item_id,
item.item_name,
item.item_brand,
item.item_variant,
item.item_category,
item.item_category2,
item.item_category3,
item.item_category4,
item.item_category5,
item.price_in_usd,
item.price,
item.quantity,
item.item_revenue_in_usd,
item.item_revenue,
item.coupon,
item.affiliation,
item.item_list_name,
item.promotion_name
FROM
`$PROJECT_ID.$DATASET_ID.ga4_transactions`,
UNNEST(items) AS item
WHERE
ecommerce.transaction_id IS NOT NULL;
Şimdi bu şablonları bq komut satırı aracını kullanarak yürütün. envsubst komutu her dosyayı okur, $PROJECT_ID ve $DATASET_ID gibi değişkenleri kabuk ortamınızdaki değerleriyle değiştirir ve son geçerli SQL'i bq sorgu komutuna yönlendirir.
envsubst < mv_ga4_user_session_flat.sql | bq query --use_legacy_sql=false
envsubst < mv_ga4_ecommerce_transactions.sql | bq query --use_legacy_sql=false
envsubst < mv_ga4_ecommerce_items.sql | bq query --use_legacy_sql=false
Python istemcisi aracılığıyla profil taramalarını yürütme
Düzleştirilmiş, profillendirilebilir görünümlerimiz olduğuna göre artık her biri için programatik olarak Bilgi Kataloğu veri profili taramaları oluşturup çalıştırabiliriz. Aşağıdaki Python komut dosyası, bu işlemi otomatikleştirmek için google-cloud-dataplex istemci kitaplığını kullanır.
Komut dosyasını çalıştırmadan önce proje dizininizde izole bir Python ortamı oluşturmanız çok önemlidir. Bu sayede projenin bağımlılıkları ayrı olarak yönetilir ve Cloud Shell kabuk ortamınızdaki diğer paketlerle çakışmalar önlenir.
# Create the virtual environment
python3 -m venv dq_venv
# Activate the environment
source dq_venv/bin/activate
Şimdi, yeni etkinleştirilen ortamda Knowledge Catalog istemci kitaplığını yükleyin.
# Install the Knowledge Catalog client library
pip install google-cloud-dataplex
Ortam ayarlandıktan ve kitaplık yüklendikten sonra orkestrasyon komut dosyasını oluşturmaya hazırsınız.
Cloud Shell araç çubuğunda Düzenleyiciyi Aç'ı tıklayın. 1_run_scan.py adlı yeni bir dosya oluşturun ve aşağıdaki Python kodunu dosyaya yapıştırın. GitHub deposunu klonlarsanız bu dosya zaten klasörünüzde bulunur.
Bu komut dosyası, her gerçekleştirilmiş görünüm için bir tarama oluşturur (henüz yoksa), taramayı çalıştırır ve ardından tüm tarama işleri tamamlanana kadar yoklama yapar.
import os
import sys
import time
from google.cloud import dataplex_v1
from google.api_core.exceptions import AlreadyExists
def create_and_run_scan(
client: dataplex_v1.DataScanServiceClient,
project_id: str,
location: str,
data_scan_id: str,
target_resource: str,
) -> dataplex_v1.DataScanJob | None:
"""
Creates and runs a single data profile scan.
Returns the executed Job object without waiting for completion.
"""
parent = client.data_scan_path(project_id, location, data_scan_id).rsplit('/', 2)[0]
scan_path = client.data_scan_path(project_id, location, data_scan_id)
# 1. Create Data Scan (skips if it already exists)
try:
data_scan = dataplex_v1.DataScan()
data_scan.data.resource = target_resource
data_scan.data_profile_spec = dataplex_v1.DataProfileSpec()
print(f"[INFO] Creating data scan '{data_scan_id}'...")
client.create_data_scan(
parent=parent,
data_scan=data_scan,
data_scan_id=data_scan_id
).result() # Wait for creation to complete
print(f"[SUCCESS] Data scan '{data_scan_id}' created.")
except AlreadyExists:
print(f"[INFO] Data scan '{data_scan_id}' already exists. Skipping creation.")
except Exception as e:
print(f"[ERROR] Error creating data scan '{data_scan_id}': {e}")
return None
# 2. Run Data Scan
try:
print(f"[INFO] Running data scan '{data_scan_id}'...")
run_response = client.run_data_scan(name=scan_path)
print(f"[SUCCESS] Job started for '{data_scan_id}'. Job ID: {run_response.job.name.split('/')[-1]}")
return run_response.job
except Exception as e:
print(f"[ERROR] Error running data scan '{data_scan_id}': {e}")
return None
def main():
"""Main execution function"""
# --- Load configuration from environment variables ---
PROJECT_ID = os.environ.get("PROJECT_ID")
LOCATION = os.environ.get("LOCATION")
DATASET_ID = os.environ.get("DATASET_ID")
if not all([PROJECT_ID, LOCATION, DATASET_ID]):
print("[ERROR] One or more required environment variables are not set.")
print("Please ensure PROJECT_ID, LOCATION, and DATASET_ID are exported in your shell.")
sys.exit(1)
print(f"[INFO] Using Project: {PROJECT_ID}, Location: {LOCATION}, Dataset: {DATASET_ID}")
# List of Materialized Views to profile
TARGET_VIEWS = [
"mv_ga4_user_session_flat",
"mv_ga4_ecommerce_transactions",
"mv_ga4_ecommerce_items"
]
# ----------------------------------------------------
client = dataplex_v1.DataScanServiceClient()
running_jobs = []
# 1. Create and run jobs for all target views
print("\n--- Starting Data Profiling Job Creation and Execution ---")
for view_name in TARGET_VIEWS:
data_scan_id = f"profile-scan-{view_name.replace('_', '-')}"
target_resource = f"//bigquery.googleapis.com/projects/{PROJECT_ID}/datasets/{DATASET_ID}/tables/{view_name}"
job = create_and_run_scan(client, PROJECT_ID, LOCATION, data_scan_id, target_resource)
if job:
running_jobs.append(job)
print("-------------------------------------------------------\n")
if not running_jobs:
print("[ERROR] No jobs were started. Exiting.")
return
# 2. Poll for all jobs to complete
print("--- Monitoring job completion status (checking every 30 seconds) ---")
completed_jobs = {}
while running_jobs:
jobs_to_poll_next = []
print(f"\n[STATUS] Checking status for {len(running_jobs)} running jobs...")
for job in running_jobs:
job_id_short = job.name.split('/')[-1][:13]
try:
updated_job = client.get_data_scan_job(name=job.name)
state = updated_job.state
if state in (dataplex_v1.DataScanJob.State.RUNNING, dataplex_v1.DataScanJob.State.PENDING, dataplex_v1.DataScanJob.State.CANCELING):
print(f" - Job {job_id_short}... Status: {state.name}")
jobs_to_poll_next.append(updated_job)
else:
print(f" - Job {job_id_short}... Status: {state.name} (Complete)")
completed_jobs[job.name] = updated_job
except Exception as e:
print(f"[ERROR] Could not check status for job {job_id_short}: {e}")
running_jobs = jobs_to_poll_next
if running_jobs:
time.sleep(30)
# 3. Print final results
print("\n--------------------------------------------------")
print("[SUCCESS] All data profiling jobs have completed.")
print("\nFinal Job Status Summary:")
for job_name, job in completed_jobs.items():
job_id_short = job_name.split('/')[-1][:13]
print(f" - Job {job_id_short}: {job.state.name}")
if job.state == dataplex_v1.DataScanJob.State.FAILED:
print(f" - Failure Message: {job.message}")
print("\nNext step: Analyze the profile results and generate quality rules.")
if __name__ == "__main__":
main()
Şimdi komut dosyasını Cloud Shell terminalinizden çalıştırın.
python 1_run_scan.py
Komut dosyası artık üç somutlaştırılmış görünümünüzün profil oluşturma işlemini düzenleyerek anlık durum güncellemeleri sağlayacak. İşlem tamamlandığında, iş akışımızın bir sonraki aşaması olan yapay zeka destekli veri kalitesi kuralı oluşturma için hazır, her görünümle ilgili zengin ve makine tarafından okunabilir bir istatistiksel profiliniz olur.
Tamamlanan profil taramalarını Google Cloud Console'da görebilirsiniz.
- Gezinme menüsündeki Yönetim bölümünde Bilgi Kataloğu ve Veri profili oluşturma ve kalite'ye gidin.
- Listelenen üç profil taramanızın yanı sıra en son iş durumlarını da görürsünüz. Ayrıntılı sonuçları görüntülemek için bir taramayı tıklayabilirsiniz.
BigQuery profilinden yapay zekaya hazır girişe
Bilgi Kataloğu profil taramaları başarıyla çalıştırıldı. Sonuçlar Knowledge Catalog API'de kullanılabilir olsa da bunları üretken yapay zeka modeli için giriş olarak kullanmak üzere yapılandırılmış bir yerel dosyaya ayıklamamız gerekir.
Aşağıdaki Python komut dosyası (2_dq_profile_save.py), mv_ga4_user_session_flat görünümümüz için en son başarılı profil tarama işini programatik olarak bulur. Ardından, eksiksiz ve ayrıntılı profil sonucunu alır ve dq_profile_results.json adlı yerel bir JSON dosyası olarak kaydeder. Bu dosya, bir sonraki adımda yapacağımız yapay zeka analizinin doğrudan girişi olarak kullanılacaktır.
Cloud Shell düzenleyicinizde 2_dq_profile_save.py adlı yeni bir dosya oluşturun ve aşağıdaki kodu dosyaya yapıştırın. Önceki adımda olduğu gibi, depoyu klonladıysanız dosya oluşturma adımını atlayabilirsiniz.
import os
import sys
import json
from google.cloud import dataplex_v1
from google.api_core.exceptions import NotFound
from google.protobuf.json_format import MessageToDict
# --- Configuration ---
# The Materialized View to analyze is fixed for this step.
TARGET_VIEW = "mv_ga4_user_session_flat"
OUTPUT_FILENAME = "dq_profile_results.json"
def save_to_json_file(content: dict, filename: str):
"""Saves the given dictionary content to a JSON file."""
try:
with open(filename, "w", encoding="utf-8") as f:
# Use indent=2 for a readable, "pretty-printed" JSON file.
json.dump(content, f, indent=2, ensure_ascii=False)
print(f"\n[SUCCESS] Profile results were saved to '{filename}'.")
except (IOError, TypeError) as e:
print(f"[ERROR] An error occurred while saving the file: {e}")
def get_latest_successful_job(
client: dataplex_v1.DataScanServiceClient,
project_id: str,
location: str,
data_scan_id: str
) -> dataplex_v1.DataScanJob | None:
"""Finds and returns the most recently succeeded job for a given data scan."""
scan_path = client.data_scan_path(project_id, location, data_scan_id)
print(f"\n[INFO] Looking for the latest successful job for scan '{data_scan_id}'...")
try:
# List all jobs for the specified scan, which are ordered most-recent first.
jobs_pager = client.list_data_scan_jobs(parent=scan_path)
# Iterate through jobs to find the first one that succeeded.
for job in jobs_pager:
if job.state == dataplex_v1.DataScanJob.State.SUCCEEDED:
return job
# If no successful job is found after checking all pages.
return None
except NotFound:
print(f"[WARN] No scan history found for '{data_scan_id}'.")
return None
def main():
"""Main execution function."""
# --- Load configuration from environment variables ---
PROJECT_ID = os.environ.get("PROJECT_ID")
LOCATION = os.environ.get("LOCATION")
if not all([PROJECT_ID, LOCATION]):
print("[ERROR] Required environment variables PROJECT_ID or LOCATION are not set.")
sys.exit(1)
print(f"[INFO] Using Project: {PROJECT_ID}, Location: {LOCATION}")
print(f"--- Starting Profile Retrieval for: {TARGET_VIEW} ---")
# Construct the data_scan_id based on the target view name.
data_scan_id = f"profile-scan-{TARGET_VIEW.replace('_', '-')}"
# 1. Initialize client and get the latest successful job.
client = dataplex_v1.DataScanServiceClient()
latest_job = get_latest_successful_job(client, PROJECT_ID, LOCATION, data_scan_id)
if not latest_job:
print(f"\n[ERROR] No successful job record was found for '{data_scan_id}'.")
print("Please ensure the '1_run_scan.py' script has completed successfully.")
return
job_id_short = latest_job.name.split('/')[-1]
print(f"[SUCCESS] Found the latest successful job: '{job_id_short}'.")
# 2. Fetch the full, detailed profile result for the job.
print(f"[INFO] Retrieving detailed profile results for job '{job_id_short}'...")
try:
request = dataplex_v1.GetDataScanJobRequest(
name=latest_job.name,
view=dataplex_v1.GetDataScanJobRequest.DataScanJobView.FULL,
)
job_with_full_results = client.get_data_scan_job(request=request)
except Exception as e:
print(f"[ERROR] Failed to retrieve detailed job results: {e}")
return
# 3. Convert the profile result to a dictionary and save it to a JSON file.
if job_with_full_results.data_profile_result:
profile_dict = MessageToDict(job_with_full_results.data_profile_result._pb)
save_to_json_file(profile_dict, OUTPUT_FILENAME)
else:
print("[WARN] The job completed, but no data profile result was found within it.")
print("\n[INFO] Script finished successfully.")
if __name__ == "__main__":
main()
Şimdi komut dosyasını terminalinizden çalıştırın:
python 2_dq_profile_save.py
İşlem başarıyla tamamlandığında dizininizde dq_profile_results.json adlı yeni bir dosya bulunur. Bu dosya, veri kalitesi kuralları oluşturmak için kullanacağımız zengin ve ayrıntılı istatistiksel meta verileri içerir. dq_profile_results.json içeriğini kontrol etmek istiyorsanız aşağıdaki komutu çalıştırın:
cat dq_profile_results.json
4. Antigravity CLI ile veri kalitesi kuralları oluşturma
Artık yerel profil tarama sonuçlarını okumak için Antigravity CLI'yı (agy) kullanabilirsiniz. Karmaşık veri kümeleri için veri kalitesi spesifikasyonlarını manuel olarak yazmak zaman alır ve hata yapma olasılığı yüksektir. Terminalinizde üretken yapay zeka ajanı kullanmak, saniyeler içinde ilk bildirimsel yapılandırmayı taslak hâline getirerek bu iş akışını hızlandırır. Bu sayede veri ekipleri, manuel söz dizimi taslağı oluşturmaktan üst düzeyde, işletmeyle uyumlu insan müdahalesi (HITL) denetimine geçebilir.
Antigravity CLI'yı başlatmak için terminalinizde aşağıdaki komutu çalıştırın:
agy
Artık kaliteli kurallar oluşturmaya hazırsınız. CLI, geçerli dizininizdeki dosyaları okuyabildiğinden yeni profil tarama verilerinizi doğrudan kullanabilir.
Temsilciden plan oluşturmasını isteme
İlk olarak, Antigravity temsilcisinden istatistiksel profili analiz etmesini ve bir işlem planı önermesini isteyeceğiz. YAML dosyasını henüz yazmaması için açıkça talimat veriyoruz. Bu, dikkatini analiz ve gerekçelendirmeye odaklar.
Etkileşimli Antigravity CLI oturumunuzda aşağıdaki yapılandırılmış istemi girin:
# Context
You are preparing a data quality rule configuration plan for Google Cloud Knowledge Catalog based on data profile statistics.
# Input
- File Path: `./dq_profile_results.json` (contains metrics like null percentage, distinct counts, and distributions)
# Task
Analyze the input statistics and propose a step-by-step plan for establishing automated data quality rules.
*Do not write any YAML code in this step.* Focus only on analytical planning.
# Rule Mapping Strategy
For candidate columns, match the statistical metrics to the most appropriate expectations:
- `nonNullExpectation`: Propose for columns with 0% null values in the profile.
- `setExpectation`: Propose for columns with a highly limited, stable set of categorical values.
- `rangeExpectation`: Propose for numeric columns with consistent and predictable value boundaries.
# Guidelines
- Provide a metric-based justification for each proposed rule (e.g., "Recommend `nonNullExpectation` for column 'user_pseudo_id' because its null percentage is 0%").
- Flag volatile metrics such as hardcoded row counts that could cause false-positive alerts in production.
# Output Format
Provide your analysis and proposed rules as a structured, step-by-step markdown plan with clear headings.
Ajan, JSON dosyasını analiz eder ve aşağıdakine benzer yapılandırılmış bir plan döndürmelidir:
Automated Data Quality Rule Configuration Plan
Google Cloud Knowledge Catalog (Dataplex Data Quality)
──────
## Executive Summary
This analytical planning document outlines a step-by-step strategy for configuring automated data quality (DQ) rules in Google Cloud Knowledge Catalog (formerly Dataplex Data Quality) based on profiling statistics.
The dataset contains 26,489 rows representing GA4 event logs. Based on statistical metrics (null ratios, distinct value distributions, and data types), candidate columns are mapped to appropriate expectation rules.
──────
## 1. Data Profile Overview & Statistical Highlights
Column Name │ Data Type │ Null Ratio │ Distinct Count │ Key Value Range / Categories
─────────────────┼───────────┼────────────────┼────────────────┼──────────────────────────────────────────────────
event_date │ STRING │ 0.0% (0) │ 1 (3.78e-05) │ "20210131" (100%)
event_timestamp │ INTEGER │ 0.0% (0) │ ~16,539 (0.62) │ Min: 1612051200657906, Max: 1612137595412363
event_name │ STRING │ 0.0% (0) │ 16 (0.0006) │ page_view (35.8%), user_engagement (18.9%), etc.
user_pseudo_id │ STRING │ 0.0% (0) │ ~2,545 (0.09) │ 18–21 characters string identifiers
user_id │ STRING │ 100.0% (1.0) │ 0 (0.0) │ Entirely NULL
device_category │ STRING │ 0.0% (0) │ 3 (0.0001) │ desktop (57.5%), mobile (40.1%), tablet (2.4%)
... │ ... │ ... │ ... │ ...
──────
## 2. Rule Mapping Strategy & Analytical Justifications
### Step 1: Nullability Rules (nonNullExpectation)
Propose nonNullExpectation for mandatory columns where the data profile demonstrates 0% null values.
• user_pseudo_id, event_timestamp, event_name, event_date, stream_id, platform, device_category (Metric Justification: nullRatio is 0.0%)
│ [!NOTE] Exclusions:
│ • user_id: Has a nullRatio of 100.0% (unauthenticated traffic).
│ • device_language: Has a nullRatio of 37.53%.
──────
### Step 2: Categorical Value Set Validation (setExpectation)
Propose setExpectation for columns with a highly limited, stable set of categorical domain values.
• device_category: Distinct count is exactly 3. Allowed set: ['desktop', 'mobile', 'tablet']
• platform: Distinct count is 1. Allowed set expanded to: ['WEB', 'ANDROID', 'IOS'] to avoid over-fitting.
• geo_continent: Distinct count is 6. Allowed set: ['Americas', 'Asia', 'Europe', 'Africa', 'Oceania', 'Antarctica', '(not set)']
──────
### Step 3: Numeric & Timestamp Boundary Validation (rangeExpectation)
Propose rangeExpectation for numeric columns with consistent and predictable value boundaries.
• event_timestamp: rangeExpectation requiring event_timestamp > 0 (avoid dynamic microsecond range hardcoding)
• stream_id: rangeExpectation requiring positive integer stream IDs (stream_id > 0)
──────
## 3. Risk Warning: Volatile Metrics & Production False Positives
│ [!WARNING] Volatile Metrics Flagged for Risk Mitigation:
1. Hardcoded Total Row Count (rowCount = 26,489) -> Daily event volume fluctuates. Use dynamic volume thresholds.
2. Hardcoded Partition Date (event_date = '20210131') -> Breaks on future runs. Validate against YYYYMMDD regex patterns.
3. Exact Timestamp Range Bounds -> Enforcing these microsecond limits on incoming live pipelines will reject all future data.
4. Single-Value Domain Restrictions -> Single profile sample might lack active streams. Set sets according to enterprise schema.
──────
## Summary Table of Proposed Rules
Target Column │ Rule Type │ Metric-Based Justification │ Operational Considerations
─────────────────┼────────────────────┼────────────────────────────┼──────────────────────────────────────────────────
user_pseudo_id │ nonNullExpectation │ Null Ratio: 0.0% │ Core identifier, strictly required
event_timestamp │ nonNullExpectation │ Null Ratio: 0.0% │ Temporal key, strictly required
event_timestamp │ rangeExpectation │ Min: > 0 (Microseconds) │ Avoid hardcoding epoch min/max
event_name │ nonNullExpectation │ Null Ratio: 0.0% │ Required event taxonomy key
event_name │ setExpectation │ Categorical distribution │ Map to standard GA4 event taxonomy
device_category │ nonNullExpectation │ Null Ratio: 0.0% │ Required form-factor dimension
device_category │ setExpectation │ Distinct Count: 3 values │ ['desktop', 'mobile', 'tablet']
... │ ... │ ... │ ...
Veri kalitesi kurallarını oluşturma
Bu, tüm iş akışındaki en kritik adımdır: Sürece insanı dahil eden (HITL) inceleme. Ajan tarafından oluşturulan plan tamamen verilerdeki istatistiksel kalıplara dayanır. İşletmenizin bağlamı, gelecekteki veri değişiklikleri veya verilerinizin arkasındaki belirli amaç hakkında bilgi sahibi değildir. İnsan uzmanı olarak rolünüz, bu planı koda dönüştürmeden önce doğrulamak, düzeltmek ve onaylamaktır.
Ajanın sağladığı planı dikkatlice inceleyin.
- Mantıklı mı?
- İşletme bilgilerinizle uyumlu mu?
- İstatistiksel olarak sağlam ancak pratik olarak işe yaramayan kurallar var mı?
Ajanın verdiği yanıtlar farklılık gösterebilir. Hedefiniz, bu planı iyileştirmektir. Örneğin, tablodaki örnek verilerde sabit sayıda satır olduğu için planın rowCount kuralı önerdiğini varsayalım. Bir uzman olarak, bu tablonun boyutunun her gün büyümesinin beklendiğini ve bu nedenle katı bir satır sayısı kuralının pratik olmadığını ve yanlış uyarılara neden olabileceğini biliyor olabilirsiniz. Bu, yapay zekanın eksik olduğu iş bağlamını uygulamaya dair mükemmel bir örnektir.
Şimdi aracıya geri bildirimde bulunacak ve kodu oluşturması için son komutu vereceksiniz. Aşağıdaki istemi, aldığınız plana ve yapmak istediğiniz düzeltmelere göre uyarlamanız gerekir.
Aşağıdaki istem bir şablondur. İlk satırda, düzeltmelerinizi belirteceksiniz. Aracının size verdiği plan mükemmelse ve herhangi bir değişiklik yapılması gerekmiyorsa bu satırı silebilirsiniz.
Aynı Antigravity oturumunda, aşağıdaki istemin uyarlanmış sürümünü girin:
# Feedback & Approvals
[YOUR CORRECTIONS AND APPROVAL GO HERE. Examples:
- "The plan looks good. Please proceed."
- "The rowCount rule is not necessary, as the table size changes daily. The rest of the plan is approved. Please proceed."
- "For the setExpectation on the geo_continent column, please also include 'Antarctica'."]
# Objective
Based on the approved analysis plan and the provided feedback, generate the final `dq_rules.yaml` file conforming to the standard `DataQualityRule` schema.
# Instructions
1. **Rule Justifications**: For every generated rule, add a YAML comment (`#`) on the line directly above it, briefly explaining the justification established in the plan.
2. **Schema Alignment**: Ensure the structure strictly adheres to the required Knowledge Catalog data quality scan specification. Refer to the `sample_rule.yaml` file in the current directory and the `DataQualityRule` class definition in the local virtual environment path (`./dq_venv/.../google/cloud/dataplex_v1/types/data_quality.py`) as the schema authority.
3. **Data-Driven Values**: Derive all rule parameters, such as thresholds or expected values, directly from the statistical metrics in `dq_profile_results.json`.
# Constraints
- **Output Purity**: Return ONLY the raw, valid, and properly formatted YAML code block.
- Do not include conversational preambles, introductory sentences, explanations, or markdown blocks around the YAML.
Ajan artık YAML içeriğini, kesin ve insan tarafından doğrulanmış talimatlarınıza göre oluşturacak. İşlem tamamlandığında çalışma dizininizde dq_rules.yaml adlı yeni bir dosya görürsünüz.
Veri kalitesi taraması oluşturma ve çalıştırma
Artık temsilci tarafından oluşturulmuş ve insan tarafından doğrulanmış bir dq_rules.yaml dosyanız olduğuna göre, bu dosyayı güvenle dağıtabilirsiniz.
/quit yazarak veya Ctrl+C tuşuna iki kez basarak Antigravity CLI'dan çıkın.
Aşağıdaki gcloud komutu, yeni bir Knowledge Catalog veri tarama kaynağı oluşturur. Tarama henüz çalıştırılmaz. Yalnızca taramanın tanımı ve yapılandırması (YAML dosyamız) Knowledge Catalog'a kaydedilir.
Terminalinizde şu komutu çalıştırın:
export DQ_SCAN="dq-scan"
gcloud dataplex datascans create data-quality $DQ_SCAN \
--project=$PROJECT_ID \
--location=$LOCATION \
--data-quality-spec-file=dq_rules.yaml \
--data-source-resource="//bigquery.googleapis.com/projects/$PROJECT_ID/datasets/$DATASET_ID/tables/mv_ga4_user_session_flat"
Artık tanımlanmış olan taramayı çalıştırmak için bir iş tetikleyebilirsiniz.
gcloud dataplex datascans run $DQ_SCAN --location=$LOCATION --project=$PROJECT_ID
Bu komut bir iş kimliği oluşturur. Bu işin durumunu Google Cloud Console'un Bilgi Kataloğu bölümünden izleyebilirsiniz. İşlem tamamlandığında sonuçlar analiz için bir BigQuery tablosuna yazılır.
5. Sürece dahil olan insanın (HITL) kritik rolü
Kural oluşturmayı hızlandırmak için Antigravity aracını kullanmak son derece etkili olsa da yapay zekayı tamamen otonom bir pilot olarak değil, yüksek becerilere sahip bir yardımcı pilot olarak değerlendirmek çok önemlidir. Sürece insanların dahil edilmesi (HITL) isteğe bağlı bir öneri değildir. Bu, herhangi bir veri yönetimi iş akışında pazarlığı yapılamayan, temel bir adımdır. Yapay zekayla üretilen eserleri titiz bir insan gözetimi olmadan kullanmak başarısızlığa yol açar.
Yapay zekayla üretilen dq_rules.yaml öğesini, son derece hızlı ancak deneyimsiz bir yapay zeka geliştiricinin gönderdiği bir pull isteği olarak düşünebilirsiniz. Yönetim politikanızın "ana dalına" birleştirilip dağıtılabilmesi için sizden, yani kıdemli bir uzman tarafından kapsamlı bir inceleme yapılması gerekir. Bu inceleme, büyük dil modellerinin doğasında bulunan zayıflıkları azaltmak için gereklidir.
Bu gerçek kişi incelemesinin neden vazgeçilmez olduğu ve özellikle nelere dikkat etmeniz gerektiğiyle ilgili ayrıntılı açıklamayı aşağıda bulabilirsiniz:
1. Bağlamsal doğrulama: Yapay zeka, işletme bilincine sahip değil
- LLM'nin zayıf noktası: LLM, kalıplar ve istatistikler konusunda uzmandır ancak işletme bağlamınız hakkında hiçbir fikri yoktur. Örneğin,
new_campaign_idsütununun boşluk oranı% 98 ise bir LLM, istatistiksel bir nedenden dolayı bu sütunu yoksayabilir. - İnsanın kritik rolü: Uzman olarak siz,
new_campaign_idalanının önümüzdeki hafta yapılacak büyük bir ürün lansmanı için dün eklendiğini biliyorsunuz. Şu anda boş değer oranının yüksek olduğunu ancak önemli ölçüde düşmesinin beklendiğini biliyorsunuz. Ayrıca, doldurulduktan sonra belirli bir biçime uyması gerektiğini de biliyorsunuz. Yapay zeka, bu harici işletme bilgisini çıkaramaz. Sizin rolünüz, bu işletme bağlamını yapay zekanın istatistiksel önerilerine uygulamak, gerektiğinde bunları geçersiz kılmak veya artırmaktır.
2. Doğruluk ve hassasiyet: Halüsinasyon ve küçük hatalara karşı koruma
- LLM'nin zayıf noktası: LLM'ler "kendinden emin bir şekilde yanlış" olabilir. "Halüsinasyon" görebilir veya küçük hatalar içeren kodlar oluşturabilir. Örneğin, doğru adlandırılmış bir kurala sahip ancak geçersiz bir parametre içeren bir YAML dosyası oluşturabilir veya bir kural türünü yanlış yazabilir (ör. doğru olan
setExpectationyerinesetExpectations). Bu küçük hatalar dağıtımın başarısız olmasına neden olur ancak tespit edilmesi zor olabilir. - İnsanın kritik rolü: Nihai linter ve şema doğrulayıcı olarak hareket etmek sizin görevinizdir. Oluşturulan YAML'yi resmi Knowledge Catalog
DataQualityRulespesifikasyonuyla karşılaştırarak titizlikle kontrol etmeniz gerekir. Yalnızca "doğru görünüp görünmediğini" kontrol etmiyorsunuz. Hedef API ile% 100 uyumlu olduğundan emin olmak için söz dizimsel ve anlamsal doğruluğunu da onaylıyorsunuz. Bu nedenle, codelab'de hata olasılığını azaltmak için aracıdan şema dosyalarına başvurması istenir ancak son doğrulama size aittir.
3. Güvenlik ve risk azaltma: Sonraki aşamalarda oluşabilecek sonuçları önleme
- LLM'nin zayıf noktası: Üretime dağıtılan hatalı bir veri kalitesi kuralı ciddi sonuçlara yol açabilir. Yapay zeka, çok geniş bir finansal işlem tutarı için
rangeExpectationönerirse sahtekarlık içeren etkinlikleri tespit edemeyebilir. Aksine, küçük bir veri örneğine dayalı olarak çok katı bir kural önerirse nöbetçi ekibinizi binlerce yanlış pozitif uyarıyla doldurabilir. Bu durum, uyarı yorgunluğuna yol açarak gerçek sorunların gözden kaçmasına neden olabilir. - İnsanın kritik rolü: Güvenlik mühendisi sizsiniz. Yapay zekanın önerdiği her kuralın potansiyel sonraki etkisini değerlendirmeniz gerekir. Kendinize şunu sorun: "Bu kural başarısız olursa ne olur? Uyarı üzerinde işlem yapılabilir mi? Bu kural yanlışlıkla geçerse risk nedir?" Bu risk değerlendirmesi, başarısızlığın maliyetini kontrolün faydasıyla karşılaştıran, yalnızca insanlara özgü bir yetenektir.
4. Sürekli bir süreç olarak yönetim: geleceğe yönelik bilgileri dahil etme
- LLM'nin zayıf noktası: Yapay zekanın bilgisi, verilerin statik bir anlık görüntüsüne dayanır. Profil, belirli bir zamandaki sonuçlardan oluşur. Gelecekteki etkinlikler hakkında bilgisi yoktur.
- İnsanın kritik rolü: Yönetim stratejiniz ileriye dönük olmalıdır. Bir veri kaynağının gelecek ay taşınacağını ve bu işlemin stream_id değerini değiştireceğini biliyorsunuz.
geo_countrylistesine yeni bir ülke eklendiğini biliyorsunuz. HITL süreci, planlanan işletme veya teknik gelişmeler sırasında bozulmaları önlemek için kuralları güncellediğiniz ya da geçici olarak devre dışı bıraktığınız ve gelecekteki durumla ilgili bilgileri eklediğiniz yerdir. Veri kalitesi tek seferlik bir kurulum değildir. Gelişmesi gereken canlı bir süreçtir ve bu gelişimi yalnızca bir insan yönlendirebilir.
Özetle, HITL, yapay zeka destekli yönetimi yeni ancak riskli bir fikirden sorumlu, ölçeklenebilir ve kurumsal düzeyde bir uygulamaya dönüştüren temel kalite kontrolü ve güvenlik mekanizmasıdır. Bu sayede, dağıtılan son politikaların yalnızca yapay zeka destekli değil, aynı zamanda insan tarafından doğrulanmış olması sağlanır. Böylece, makinelerin hızı ile insan uzmanların bilgeliği ve bağlamı bir araya getirilir.
Ancak insan gözetimine yapılan bu vurgu, yapay zekanın değerini azaltmaz. Aksine, üretken yapay zeka, HITL sürecinin hızlandırılmasında önemli bir rol oynar.
Yapay zeka olmadan bir veri mühendisinin yapması gerekenler:
- Verileri profillemek için karmaşık SQL sorgularını manuel olarak yazın (ör. her sütun için
COUNT DISTINCT,AVG,MIN,MAX). - Sonuçları e-tablo e-tablo titizlikle analiz edin.
- YAML kural dosyasının her satırını baştan yazmak zahmetli ve hataya açık bir iştir.
Yapay zeka, bu zahmetli ve zaman alıcı adımları otomatikleştirir. Bu araç, istatistiksel profili anında işleyen ve politikaların% 80'i tamamlanmış, iyi yapılandırılmış bir "ilk taslağını" sunan yorulmak bilmez bir analist gibi çalışır.
Bu durum, insanın yaptığı işin doğasını temelden değiştirir. İnsan uzman, saatlerini manuel veri işleme ve standart kodlama ile geçirmek yerine hemen en değerli görevlere odaklanabilir:
- Önemli iş bağlamını uygulama
- Yapay zekanın mantığının doğruluğunu doğrulama
- Hangi kuralların gerçekten önemli olduğuna dair stratejik kararlar alma
Bu ortaklıkta yapay zeka "ne" (istatistiksel kalıplar nelerdir?) sorusunu yanıtlayarak insanın "neden" (bu kalıp işletmemiz için neden önemlidir?) ve "peki ne olacak?" (politikamız ne olmalıdır?) sorularına odaklanmasını sağlar. Bu nedenle yapay zeka, döngünün yerini almaz. Döngüdeki her aşamayı daha hızlı, daha akıllı ve daha etkili hale getirir.
6. Ortamınızı temizleme
Bu codelab'de kullanılan kaynaklar için Google Cloud hesabınızın gelecekte ücretlendirilmesini önlemek istiyorsanız kaynakları içeren projeyi silmeniz gerekir. Ancak projeyi tutmak istiyorsanız oluşturduğunuz kaynakları ayrı ayrı silebilirsiniz.
Bilgi Kataloğu taramalarını silme
Öncelikle oluşturduğunuz profil ve kalite taramalarını silin. Önemli kaynakların yanlışlıkla silinmesini önlemek için bu komutlarda, bu codelab'de oluşturulan taramaların belirli adları kullanılır.
# Delete the Data Quality Scan
gcloud dataplex datascans delete dq-scan \
--location=us-central1 \
--project=$PROJECT_ID --quiet
# Delete the Data Profile Scans
gcloud dataplex datascans delete profile-scan-mv-ga4-user-session-flat \
--location=us-central1 \
--project=$PROJECT_ID --quiet
gcloud dataplex datascans delete profile-scan-mv-ga4-ecommerce-transactions \
--location=us-central1 \
--project=$PROJECT_ID --quiet
gcloud dataplex datascans delete profile-scan-mv-ga4-ecommerce-items \
--location=us-central1 \
--project=$PROJECT_ID --quiet
BigQuery veri kümesini silin.
Ardından, BigQuery veri kümesini silin. Bu komut geri alınamaz ve veri kümesini ve tüm tablolarını onay olmadan kaldırmak için -f (zorla) işaretini kullanır.
# Manually type this command to confirm you are deleting the correct dataset
bq rm -r -f --dataset $PROJECT_ID:kc_dq_codelab
7. Tebrikler!
Codelab'i başarıyla tamamladınız.
Uçtan uca, programatik bir veri yönetimi iş akışı oluşturmuş olursunuz. Karmaşık BigQuery verilerini düzleştirerek analize uygun hale getirmek için materialized view'ları kullanarak başladınız. Ardından, istatistiksel meta veriler oluşturmak için Knowledge Catalog profil taramalarını programatik olarak çalıştırdınız. En önemlisi, profil çıkışını analiz etmek ve akıllıca bir "kod olarak politika" artefaktı (dq_rules.yaml) oluşturmak için Antigravity CLI'yi kullandınız. Ardından, bu yapılandırmayı otomatik bir veri kalitesi taraması olarak dağıtmak için CLI'yi kullandınız ve modern, ölçeklenebilir bir yönetim stratejisiyle döngüyü kapattınız.
Artık Google Cloud'da güvenilir, yapay zeka destekli ve insan tarafından doğrulanmış veri kalitesi sistemleri oluşturmak için temel kalıba sahipsiniz.
Sırada ne var?
- CI/CD ile entegrasyon:
dq_rules.yamldosyasını alıp Git deposuna işleyin. Kural dosyası her güncellendiğinde Knowledge Catalog taramasını otomatik olarak dağıtan bir CI/CD ardışık düzeni oluşturun (ör. Cloud Build veya GitHub Actions kullanarak). - Özel SQL kurallarını keşfedin: Standart kural türlerinin ötesine geçin. Bilgi Kataloğu, önceden tanımlanmış kontrollerle ifade edilemeyen daha karmaşık ve işletmeye özgü mantığı zorunlu kılmak için özel SQL kurallarını destekler. Bu özellik, doğrulamayı benzersiz gereksinimlerinize göre uyarlamanızı sağlar.
- Tarama işlemlerini verimlilik ve maliyet açısından optimize etme: Çok büyük tablolarda, her zaman tüm veri kümesini taramayarak performansı artırabilir ve maliyetleri düşürebilirsiniz. Tarama kapsamını belirli zaman aralıkları veya veri segmentleriyle sınırlandırmak için filtreleri kullanmayı deneyin ya da verilerinizin temsili bir yüzdesini kontrol etmek için örneklenmiş taramalar yapılandırın.
- Sonuçları görselleştirme: Her Knowledge Catalog veri kalitesi taramasının çıkışı bir BigQuery tablosuna yazılır. Bu tabloyu Looker Studio'ya bağlayarak, tanımladığınız boyutlara (ör. eksiksizlik, geçerlilik) göre zaman içindeki veri kalitesi puanlarınızı izleyen kontrol panelleri oluşturun. Bu sayede izleme proaktif hale gelir ve tüm paydaşlar tarafından görülebilir.
- En iyi uygulamaları paylaşın: Toplu deneyimden yararlanmak ve veri kalitesi stratejinizi geliştirmek için kuruluşunuzda bilgi paylaşımını teşvik edin. Verilere güven kültürünü teşvik etmek, yönetim çalışmalarınızdan en iyi şekilde yararlanmanın anahtarıdır.
- Belgeleri okuyun: