Delta Live Tables işlem hatlarını geliştirmeye ve test etmeye yönelik İpuçları, öneriler ve özellikler

Makale
07/10/2024

Bu makalede Delta Live Tables işlem hatlarını geliştirmek ve test etmek için kullanabileceğiniz desenler açıklanmaktadır. İşlem hattı ayarları aracılığıyla Delta Live Tables, geliştirme, test ve üretim ortamlarında işlem hatlarını yalıtmak için yapılandırmalar belirtmenize olanak tanır. Bu makaledeki öneriler hem SQL hem de Python kod geliştirme için geçerlidir.

İşlem hattı güncelleştirmelerini çalıştırmak için geliştirme modunu kullanma

Delta Live Tables, işlem hattı güncelleştirmelerinizin geliştirme veya üretim modunda çalıştırılıp çalıştırılmayacağını denetlemek için bir kullanıcı arabirimi iki durumlu düğmesi sağlar. Bu mod, aşağıdakiler dahil olmak üzere işlem hattı güncelleştirmelerinin nasıl işlendiğini denetler:

Geliştirme modu, güncelleştirme başarılı veya başarısız olduktan sonra işlem kaynaklarını hemen sonlandırmaz. Bir kümenin başlatılmasını beklemeden işlem hattının birden çok güncelleştirmesini çalıştırmak için aynı işlem kaynaklarını yeniden kullanabilirsiniz.
Geliştirme modu, görev hatasında otomatik olarak yeniden denemez ve işlem hattınızdaki mantıksal veya bozulmamış hataları hemen algılamanıza ve düzeltmenize olanak sağlar.

Databricks, geliştirme ve test sırasında geliştirme modunun kullanılmasını ve üretim ortamına dağıtım yaparken her zaman üretim moduna geçmeyi önerir.

Bkz . Geliştirme ve üretim modları.

Tabloların güncelleştirilesini beklemeden işlem hattı kaynak kodunu test etme

Geliştirme ve test sırasında söz dizimi ve analiz hataları gibi işlem hattı kaynak kodunuzla ilgili sorunları denetlemek için Doğrulama güncelleştirmesi çalıştırabilirsiniz. Güncelleştirme, herhangi bir Validate tablo üzerinde gerçek bir güncelleştirme çalıştırmadan yalnızca işlem hattı kaynak kodunun doğruluğunu doğruladığı için, gerçek bir işlem hattı güncelleştirmesini çalıştırmadan önce sorunları daha hızlı bir şekilde belirleyebilir ve düzeltebilirsiniz.

Tüm geliştirme yaşam döngüsü aşamalarında hedef şema belirtme

Delta Live Tables işlem hattındaki tüm veri kümeleri, işlem hattı dışında erişilmeyen LIVE sanal şemaya başvurur. Bir hedef şema belirtilirse, LIVE sanal şema hedef şemayı gösterir. Güncelleştirme sırasında her tabloya yazılan sonuçları gözden geçirmek için bir hedef şema belirtmeniz gerekir.

Ortamınıza özgü bir hedef şema belirtmeniz gerekir. Belirli bir şemadaki her tablo yalnızca tek bir işlem hattı tarafından güncelleştirilebilir.

Farklı hedeflerle geliştirme, test ve üretim için ayrı işlem hatları oluşturarak bu ortamları yalıtılmış tutabilirsiniz. Hedef şema parametresini kullanmak, veri kaynaklarını ve hedeflerini denetlemek için dize ilişkilendirmesini veya diğer pencere öğelerini veya parametreleri kullanan mantığı kaldırmanıza olanak tanır.

Bkz . Delta Live Tablolarından Hive meta veri deposuna veri yayımlama.

Delta Live Tables işlem hatlarını yönetmek için Databricks Git klasörlerini kullanma

Databricks, Delta Live Tables işlem hattı geliştirme, test etme ve üretime dağıtım sırasında Git klasörlerinin kullanılmasını önerir. Git klasörleri aşağıdakileri etkinleştirir:

Kodun zaman içinde nasıl değiştiğini takip etme.
Birden çok geliştirici tarafından yapılan değişiklikleri birleştirme.
Kod incelemeleri gibi yazılım geliştirme uygulamaları.

Databricks, işlem hattıyla ilgili tüm kodlar için tek bir Git deposu yapılandırmanızı önerir.

Her geliştiricinin geliştirme için yapılandırılmış kendi Databricks Git klasörü olmalıdır. Geliştirme sırasında kullanıcı Databricks Git klasöründen kendi işlem hattını yapılandırarak geliştirme veri kümelerini ve yalıtılmış şemayı ve konumları kullanarak yeni mantığı test eder. Geliştirme çalışması tamamlandıkçe, kullanıcı değişiklikleri işleyip merkezi Git deposundaki dalına gönderir ve test veya Soru-Cevap dalı için bir çekme isteği açar.

Sonuçta elde edilen dal databricks Git klasöründe ve test veri kümeleri ve geliştirme şeması kullanılarak yapılandırılmış bir işlem hattında kullanıma alınmalıdır. Mantığın beklendiği gibi çalıştığı varsayıldığında, bir çekme isteği veya yayın dalı değişiklikleri üretime göndermeye hazır olmalıdır.

Git klasörleri, kodu ortamlar arasında eşitlemek için kullanılabilse de işlem hattı ayarlarının el ile veya Terraform gibi araçlar kullanılarak güncel tutulması gerekir.

Bu iş akışı, tüm Databricks işlerinde CI/CD için Git klasörlerini kullanmaya benzer. Bkz. Git ve Databricks Git klasörleri (Depolar) ile CI/CD teknikleri.

Alma ve dönüştürme adımları için segment kitaplıkları

Databricks, verileri zenginleştiren ve doğrulayan dönüştürme mantığından veri alan sorguları yalıtmanızı önerir. Ardından, geliştirme veya test veri kaynaklarından veri almak veya veri kaynaklarını test etmek için kullanılan kitaplıkları üretim verileri alma mantığından ayrı bir dizinde düzenleyerek çeşitli ortamlar için işlem hatlarını kolayca yapılandırmanıza olanak sağlayabilirsiniz. Daha sonra test için daha küçük veri kümeleri kullanarak geliştirmeyi hızlandırabilirsiniz. Bkz . Geliştirme ve test için örnek veri kümeleri oluşturma.

Geliştirme, test ve üretim için veri kaynaklarını denetlemek için parametreleri de kullanabilirsiniz. Bkz. Veri kaynaklarını parametrelerle denetleme.

Delta Live Tables işlem hatları, örnek verileri yükleyen alım kitaplıklarıyla geliştirme ve test işlem hatlarını yapılandırarak tüm veri kümesi ilişkilerini yönetmek için sanal şemayı kullandığından LIVE , kodu test etmek için üretim tablosu adlarını kullanarak örnek veri kümelerini değiştirebilirsiniz. Aynı dönüştürme mantığı tüm ortamlarda kullanılabilir.

Geliştirme ve test için örnek veri kümeleri oluşturma

Databricks, hem beklenen verilerle hem de olası hatalı biçimlendirilmiş veya bozuk kayıtlarla işlem hattı mantığını test etmek için geliştirme ve test veri kümeleri oluşturmanızı önerir. Geliştirme ve test için yararlı olabilecek veri kümeleri oluşturmanın aşağıdakiler de dahil olmak üzere birden çok yolu vardır:

Üretim veri kümesinden bir veri alt kümesi seçin.
PII içeren kaynaklar için anonimleştirilmiş veya yapay olarak oluşturulmuş verileri kullanın.
Aşağı akış dönüştürme mantığını temel alan iyi tanımlanmış sonuçlarla test verileri oluşturun.
Veri şeması beklentilerini bozan kayıtlar oluşturarak olası veri bozulmalarını, hatalı biçimlendirilmiş kayıtları ve yukarı akış veri değişikliklerini tahmin edin.

Örneğin, aşağıdaki kodu kullanarak bir veri kümesini tanımlayan bir not defteriniz varsa:

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM cloud_files("/production/data", "json")

Aşağıdaki gibi bir sorgu kullanarak belirli kayıtları içeren örnek bir veri kümesi oluşturabilirsiniz:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

Aşağıdaki örnekte, geliştirme veya test için üretim verilerinin bir alt kümesini oluşturmak üzere yayımlanan verilerin filtrelenmesi gösterilmektedir:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

Bu farklı veri kümelerini kullanmak için, dönüştürme mantığını uygulayan not defterleriyle birden çok işlem hattı oluşturun. Her işlem hattı veri kümesindeki LIVE.input_data verileri okuyabilir, ancak ortama özgü veri kümesini oluşturan not defterini içerecek şekilde yapılandırılır.

Veri kaynaklarını parametrelerle denetleme

İşlem hattı yapılandırması sırasında ayarlanan parametrelere kitaplıklarınızın içinden başvurabilirsiniz. Bu parametreler, işlem hattı ayarları kullanıcı arabiriminin İşlem > Gelişmiş > Yapılandırmaları bölümünde anahtar-değer çiftleri olarak ayarlanır. Bu düzen, aynı işlem hattının farklı yapılandırmalarında farklı veri kaynakları belirtmenize olanak tanır.

Örneğin, değişkenini data_source_path kullanarak işlem hattı için geliştirme, test ve üretim yapılandırmalarında farklı yollar belirtebilir ve ardından aşağıdaki kodu kullanarak buna başvurabilirsiniz:

SQL

CREATE STREAMING TABLE bronze
AS (
    SELECT
    *,
    _metadata.file_path AS source_file_path
    FROM cloud_files( '${data_source_path}', 'csv',
            map("header", "true"))
)

Python

import dlt
from pyspark.sql.functions import col

data_source_path = spark.conf.get("data_source_path")

@dlt.table
def bronze():
    return (spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "csv")
        .option("header", True)
        .load(data_source_path )
        .select("*", col("_metadata.file_path").alias("source_file_name"))
    )

Bu desen özellikle ilk alma sırasında alma mantığının şemada veya hatalı biçimlendirilmiş verilerde yapılan değişiklikleri nasıl işleyebileceğini test etmeniz gerekiyorsa kullanışlıdır. Veri kümelerini değiştirirken işlem hattınızın tamamında aynı kodu tüm ortamlarda kullanabilirsiniz.

Aracılığıyla paylaş