Bagikan melalui

Praktik terbaik untuk Alur Deklaratif Lakeflow Spark

Halaman ini menjelaskan pola yang direkomendasikan untuk merancang, membangun, dan mengoperasikan alur dengan Alur Deklaratif Lakeflow Spark. Terapkan panduan ini saat memulai alur baru atau meningkatkan yang sudah ada.

Pilih jenis himpunan data yang tepat

Alur Deklaratif Lakeflow Spark menawarkan tiga jenis himpunan data: tabel streaming, tampilan materialisasi, dan tampilan sementara. Memilih jenis yang tepat untuk setiap lapisan alur Anda menghindari biaya komputasi yang tidak perlu dan membuat kode Anda mudah dipahami.

Tabel streaming adalah pilihan yang tepat untuk penyerapan data dan transformasi streaming latensi rendah. Setiap baris input dibaca dan diproses hanya sekali, yang membuatnya ideal untuk beban kerja khusus tambahan, data volume tinggi, dan pemrosesan berbasis peristiwa dari penyimpanan cloud atau bus pesan.

Materialized view adalah pilihan yang tepat untuk transformasi kompleks dan kueri analitis. Hasilnya telah dihitung sebelumnya dan terus diperbarui menggunakan pembaharuan bertahap, sehingga kueri terhadapnya dilakukan dengan cepat. Anda tidak dapat langsung mengubah data dalam tampilan materialisasi — definisi kueri mengontrol output.

Tampilan sementara adalah tampilan cakupan alur yang mengatur logika transformasi Anda tanpa mewujudkan data apa pun ke penyimpanan. Gunakan mereka untuk langkah perantara yang tidak perlu tabel mereka sendiri.

Tabel berikut ini meringkas kapan harus menggunakan setiap jenis:

Skenario penggunaan Jenis yang disarankan Alasan
Pengambilan data dari penyimpanan cloud atau bus pesan digital Tabel streaming Memproses setiap rekaman sekali; menangani beban kerja volume tinggi dan hanya tambahan.
Aliran CDC (sisipan, pembaruan, penghapusan) Tabel streaming Digunakan sebagai target untuk penyerapan APPLY CHANGES INTO CDC yang diurutkan dan dideduplikasi.
Agregasi dan gabungan kompleks Tampilan Tervirtualisasi Disegarkan secara bertahap; menghindari komputasi ulang penuh pada setiap pembaruan.
Akselerasi kueri pada dasbor Tampilan Tervirtualisasi Hasil prakomputasi membuat permintaan lebih cepat daripada terhadap tabel mentah.
Transformasi menengah (tidak ada pembaca hilir) Tampilan sementara Mengatur logika alur tanpa menimbulkan biaya penyimpanan.

Untuk informasi selengkapnya, lihat Tabel streaming, Tampilan terwujud, dan konsep Alur Deklaratif Lakeflow Spark.

Gunakan CDC deklaratif daripada MERGE imperatif

Menerapkan change data capture (CDC) dengan pernyataan SQL MERGE imperatif memerlukan kode kustom yang signifikan untuk menangani pengurutan peristiwa, deduplikasi, pembaruan parsial, dan evolusi skema dengan benar. Masing-masing kekhawatiran ini harus diselesaikan secara independen, dan kode yang dihasilkan sulit untuk dipertahankan dan diuji.

Lakeflow Spark Declarative Pipelines menyediakan APPLY CHANGES INTO pernyataan (SQL) dan apply_changes() fungsi (Python), yang menangani pemesanan, deduplikasi, peristiwa di luar urutan, dan evolusi skema secara deklaratif. Anda menjelaskan bentuk umpan perubahan dan tabel target — alur menangani sisanya. APPLY CHANGES INTO mendukung SCD Tipe 1 (timpa) dan SCD Tipe 2 (pelestarian riwayat).

Untuk informasi selengkapnya, lihat Mengubah pengambilan dan rekam jepret data dan API CDC OTOMATIS: Menyederhanakan perubahan pengambilan data dengan alur.

Menerapkan kualitas data dengan harapan

Ekspektasi adalah ekspresi SQL true/false yang diterapkan ke setiap baris yang melewati himpunan data. Saat baris mengalami kegagalan kondisi, alur akan merespons sesuai dengan kebijakan pelanggaran yang telah Anda konfigurasi. Ekspektasi memancarkan metrik ke log peristiwa alur terlepas dari kebijakan, sehingga Anda dapat melacak tren kualitas data dari waktu ke waktu.

Pilih kebijakan pelanggaran

Tersedia tiga kebijakan pelanggaran. Pilih salah satu yang cocok dengan toleransi Anda untuk data yang buruk:

  • peringatan (default): Rekaman yang tidak valid ditulis ke tabel target dan ditandai dalam metrik. Gunakan kebijakan ini saat Anda perlu mengambil semua data tetapi menginginkan visibilitas ke dalam masalah kualitas.
  • drop: Rekaman yang tidak valid dihilangkan sebelum penulisan. Gunakan ini saat baris yang tidak valid diharapkan dan tidak boleh diteruskan ke hilir.
  • gagal: Pembaruan alur berhenti pada rekaman pertama yang tidak valid. Gunakan ini untuk data penting di mana catatan buruk menunjukkan masalah hulu yang serius.

Contoh berikut menunjukkan setiap kebijakan yang diterapkan ke tabel streaming:

SQL

-- Warn: write invalid records but track them in metrics
CREATE OR REFRESH STREAMING TABLE orders_raw (
  CONSTRAINT valid_order_id EXPECT (order_id IS NOT NULL)
) AS SELECT * FROM STREAM read_files("/volumes/raw/orders", format => "json");

-- Drop: discard invalid records before writing
CREATE OR REFRESH STREAMING TABLE orders_clean (
  CONSTRAINT non_negative_amount EXPECT (amount >= 0) ON VIOLATION DROP ROW
) AS SELECT * FROM STREAM(orders_raw);

-- Fail: stop the pipeline on any invalid record
CREATE OR REFRESH STREAMING TABLE orders_critical (
  CONSTRAINT required_customer_id EXPECT (customer_id IS NOT NULL) ON VIOLATION FAIL UPDATE
) AS SELECT * FROM STREAM(orders_clean);

Python

from pyspark import pipelines as dp

# Warn: write invalid records but track them in metrics
@dp.table
@dp.expect("valid_order_id", "order_id IS NOT NULL")
def orders_raw():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "json") \
        .load("/volumes/raw/orders")

# Drop: discard invalid records before writing
@dp.table
@dp.expect_or_drop("non_negative_amount", "amount >= 0")
def orders_clean():
    return spark.readStream.table("orders_raw")

# Fail: stop the pipeline on any invalid record
@dp.table
@dp.expect_or_fail("required_customer_id", "customer_id IS NOT NULL")
def orders_critical():
    return spark.readStream.table("orders_clean")

Mengkarantina rekaman yang tidak valid

Ketika Anda ingin mempertahankan rekaman yang terhapus untuk penyelidikan daripada membuangnya secara diam-diam, gunakan pola karantina. Rutekan baris yang gagal divalidasi ke tabel streaming terpisah dengan menggunakan dua alur: yang pertama menghapus baris yang tidak valid dari tabel utama, dan yang kedua menulis hanya baris yang tidak valid ke tabel karantina. Ini memungkinkan Anda menyelidiki, memperbaiki, dan memproses ulang data yang buruk tanpa mengkontaminasi himpunan data bersih Anda.

Untuk contoh terperinci pola karantina, lihat Rekomendasi ekspektasi dan pola tingkat lanjut.

Untuk informasi selengkapnya tentang ekspektasi, lihat Mengelola kualitas data dengan ekspektasi alur.

Parameterisasi alur kerja Anda

Alur memiliki pengaturan katalog dan skema default, sehingga kode yang membaca dan menulis dalam katalog dan skema yang sama berfungsi di seluruh lingkungan tanpa parameter apa pun. Namun, jika alur Anda perlu mereferensikan katalog atau skema kedua — misalnya, membaca dari katalog sumber bersama yang berbeda antara pengembangan dan produksi — hindari hardcoding nama-nama tersebut langsung dalam kode sumber Anda. Sebagai gantinya, tentukan sebagai parameter konfigurasi alur (pasangan kunci-nilai yang diatur dalam pengaturan alur) dan referensikan dalam kode Anda. Ini memungkinkan basis kode tunggal berjalan dengan benar di seluruh lingkungan dengan bertukar nilai parameter.

SQL

CREATE OR REFRESH MATERIALIZED VIEW transaction_summary AS
SELECT account_id, COUNT(txn_id) AS txn_count, SUM(amount) AS total_amount
FROM ${source_catalog}.sales.transactions
GROUP BY account_id;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import count, sum

@dp.materialized_view
def transaction_summary():
    source_catalog = spark.conf.get("source_catalog")
    return spark.read.table(f"{source_catalog}.sales.transactions") \
        .groupBy("account_id") \
        .agg(
            count("txn_id").alias("txn_count"),
            sum("amount").alias("total_amount")
        )

Untuk informasi selengkapnya, lihat Menggunakan parameter dengan alur.

Pilih mode alur yang tepat untuk setiap lingkungan

Mode pembaruan pengembangan dan produksi

Pipeline berjalan dalam mode pengembangan atau pembaruan mode produksi. Pilih mode yang cocok dengan tujuan Anda.

Dalam mode pengembangan, alur pemrosesan menggunakan kembali kluster yang berjalan lama di seluruh pembaruan dan tidak melakukan percobaan ulang jika terjadi kesalahan. Ini mempercepat siklus iterasi saat Anda menulis dan menguji kode alur karena Anda mendapatkan detail kesalahan segera tanpa menunggu mulai ulang kluster.

Dalam mode produksi, kluster segera dimatikan setelah setiap pembaruan selesai, yang mengurangi biaya komputasi. Alur juga menerapkan upaya pengulangan yang meningkat, termasuk restart kluster, untuk menangani kegagalan infrastruktur sementara secara otomatis. Gunakan mode produksi untuk semua eksekusi alur terjadwal.

Dipicu vs. mode alur berkelanjutan

Mode yang dipicu memproses semua data yang tersedia lalu berhenti. Ini adalah pilihan yang tepat untuk sebagian besar alur kerja: yang berjalan sesuai jadwal (per jam, harian, atau sesuai permintaan) dan tidak memerlukan kesegaran data di bawah satu menit.

Mode berkelanjutan membuat kluster tetap berjalan dan memproses data baru saat tiba. Ini hanya sesuai ketika kasus penggunaan Anda memerlukan latensi dalam rentang detik-ke-menit. Karena mode berkelanjutan memerlukan kluster yang selalu aktif, ini jauh lebih mahal daripada mode yang dipicu.

Untuk informasi selengkapnya, lihat Mode alur yang dipicu vs. berkelanjutan dan Mengonfigurasi Alur.

Menggunakan pengklusteran cairan untuk tata letak data

Pengklusteran cair menggantikan partisi statis dan ZORDER untuk mengoptimalkan tata letak data dalam tabel Delta. Tidak seperti partisi, yang mengharuskan Anda memilih kolom partisi terlebih dahulu dan dapat menyebabkan kecenderungan data ketika nilai didistribusikan secara tidak merata, pengklusteran cairan adalah penyetelan mandiri, tahan terhadap ketidakseimbangan, dan bertahap — hanya data yang membutuhkan reorganisasi yang ditulis ulang setiap kali dijalankan.

Ubah kolom pengklusteran kapan saja tanpa menulis ulang tabel lengkap saat pola kueri berkembang.

Tentukan kolom pengklusteran dalam definisi tabel streaming Anda:

SQL

CREATE OR REFRESH STREAMING TABLE events
CLUSTER BY (event_date, region)
AS SELECT * FROM STREAM read_files("/volumes/raw/events", format => "parquet");

Python

from pyspark import pipelines as dp

@dp.table(cluster_by=["event_date", "region"])
def events():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "parquet") \
        .load("/volumes/raw/events")

Jika Anda tidak yakin kolom mana yang akan diklusterkan, gunakan CLUSTER BY AUTO untuk mengizinkan Databricks memilih kolom pengklusteran optimal berdasarkan beban kerja kueri Anda secara otomatis.

Untuk informasi selengkapnya, lihat Tabel streaming dan Menggunakan pengklusteran cair untuk tabel.

Mengelola alur dengan CI/CD dan Bundel Otomatisasi Deklaratif

Kontrol versi kode sumber alur Anda dan gunakan Bundel Otomatisasi Deklaratif untuk mengelola penyebaran di seluruh lingkungan.

Untuk informasi selengkapnya, lihat Membuat alur yang dikontrol sumber, Mengonversi alur menjadi proyek bundel, dan Menggunakan parameter dengan alur.

Menyimpan kode alur dalam kontrol versi

Simpan semua file sumber alur (Python dan SQL) bersama konfigurasi bundel Anda di repositori Git. Mengontrol versi proyek lengkap memberi Anda riwayat perubahan lengkap, membuat kolaborasi lebih mudah, dan memungkinkan Anda memvalidasi perubahan di lingkungan pengembangan sebelum mempromosikannya ke produksi.

Databricks merekomendasikan Bundel Otomatisasi Deklaratif untuk mengelola alur kerja ini. Bundel menentukan konfigurasi alur Anda di YAML bersama kode sumber Anda, dan databricks bundle CLI memungkinkan Anda memvalidasi, menyebarkan, dan menjalankan alur dari terminal atau sistem CI/CD Anda.

Menggunakan target bundel untuk isolasi lingkungan

Bundel memungkinkan beberapa target (misalnya, dev, staging, prod), masing-masing dengan set pengaturan khususnya sendiri untuk nama katalog, kebijakan kluster, alamat notifikasi, dan pengaturan lainnya. Gabungkan target bundel dengan parameter alur untuk menyuntikkan nilai spesifik lingkungan yang benar pada waktu penyebaran, menjaga kode sumber Anda tetap bebas dari konstanta lingkungan.

Alur kerja umum terlihat seperti ini:

  1. Pengembang bekerja pada cabang fitur, menyebarkan ke alur pengembangan pribadi dalam katalog pengembang.
  2. Pada saat penggabungan ke cabang utama, sistem CI menjalankan databricks bundle validate dan databricks bundle deploy --target staging untuk memvalidasi dan menyebarkan pipeline ke staging.
  3. Setelah pengujian lulus, sistem CI menggelar ke produksi dengan databricks bundle deploy --target prod.

Praktik terbaik streaming

Gunakan pola ini untuk mengelola status, mengontrol data terlambat, dan menjaga alur streaming tetap andal.

Untuk informasi selengkapnya, lihat Mengoptimalkan pemrosesan stateful dengan penanda waktu, Memulihkan jalur data dari kegagalan titik pemeriksaan streaming, dan Memproses ulang data historis menggunakan jalur data.

Menggunakan penanda air untuk operasi stateful

Penanda batas waktu membatasi status yang pipa simpan dalam memori selama operasi streaming berstatus seperti agregasi berbasis jendela dan deduplikasi. Tanpa watermark, state tumbuh tidak terbatas karena pipeline mengakumulasi data untuk setiap kunci yang mungkin, akhirnya menyebabkan kesalahan kehabisan memori pada proses yang berlangsung lama.

Watermark menentukan kolom cap waktu dan ambang batas toleransi untuk data yang terlambat. Rekaman yang tiba setelah ambang batas berlalu dihilangkan. Pilih ambang batas yang menyeimbangkan toleransi Anda untuk data yang terlambat terhadap biaya memori untuk menjaga status tersebut tetap terbuka.

Contoh berikut menghitung agregasi jendela tumbling dengan durasi satu menit dan marka air tiga menit.

SQL

CREATE OR REFRESH STREAMING TABLE event_counts AS
SELECT window(event_time, '1 minute') AS time_window, region, COUNT(*) AS cnt
FROM STREAM(events_raw)
  WATERMARK event_time DELAY OF INTERVAL 3 MINUTES
GROUP BY time_window, region;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import window

@dp.table
def event_counts():
    return (
        spark.readStream.table("events_raw")
            .withWatermark("event_time", "3 minutes")
            .groupBy(window("event_time", "1 minute"), "region")
            .count()
    )

Nota

Untuk memastikan bahwa agregasi diproses secara incremental daripada dihitung ulang sepenuhnya pada setiap pembaruan, Anda harus menentukan penanda batas waktu.

Memahami status streaming dan refresh penuh

Keadaan streaming bersifat inkremental: alur membangun dan mempertahankan status di seluruh pembaruan daripada menghitung ulang dari nol setiap kali. Inilah yang membuat penyiaran berstatus efisien, namun juga berarti bahwa jika Anda mengubah logika kueri berstatus (misalnya, memodifikasi ambang batas penanda waktu atau mengubah kolom agregasi), status saat ini tidak lagi kompatibel dengan logika baru. Dalam hal ini, Anda harus melakukan refresh penuh untuk memproses ulang semua data historis dengan logika baru dan membangun kembali status dari awal.

Refresh penuh juga dapat menyebabkan kehilangan data jika sumber tidak menyimpan data historis. Misalnya, sumber Kafka dengan periode retensi singkat mungkin hanya memiliki beberapa menit terakhir data yang tersedia pada saat refresh, menghasilkan tabel yang berisi data yang jauh lebih sedikit daripada sebelumnya. Rencanakan perubahan logika kueri stateful dengan hati-hati, terutama untuk aliran volume tinggi apabila refresh penuh dianggap mahal atau sumber memiliki retensi data yang terbatas. Menggunakan arsitektur medali membantu dengan membuat tabel perunggu dengan transformasi minimal, dan memungkinkan tabel perak atau emas untuk dikompilasi ulang dari tabel perunggu dengan sejarah penuh.

Gabungan stream-stream

Gabungan aliran aliran memerlukan marka air di kedua sisi gabungan dan kondisi gabungan yang terikat waktu. Interval waktu pada kondisi join menentukan kapan mesin streaming tidak dapat menemukan kecocokan lebih lanjut, memungkinkannya untuk menghapus status yang sudah tidak bisa dicocokkan lagi. id-ID: Jika Anda menghilangkan tanda air atau kondisi terikat waktu, keadaan tumbuh tanpa batas.

Contoh berikut menggabungkan peristiwa tayangan iklan dengan peristiwa klik, mengharuskan klik terjadi dalam waktu tiga menit setelah tayangan:

SQL

CREATE OR REFRESH STREAMING TABLE impression_clicks AS
SELECT imp.ad_id, imp.impression_time, clk.click_time
FROM STREAM(ad_impressions)
    WATERMARK impression_time DELAY OF INTERVAL 3 MINUTES AS imp
JOIN STREAM(user_clicks)
    WATERMARK click_time DELAY OF INTERVAL 3 MINUTES AS clk
ON imp.ad_id = clk.ad_id
  AND clk.click_time BETWEEN imp.impression_time
    AND imp.impression_time + INTERVAL 3 MINUTES;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import expr

dp.create_streaming_table("impression_clicks")

@dp.append_flow(target="impression_clicks")
def join_impressions_and_clicks():
    impressions = spark.readStream.table("ad_impressions") \
        .withWatermark("impression_time", "3 minutes")
    clicks = spark.readStream.table("user_clicks") \
        .withWatermark("click_time", "3 minutes")
    return impressions.alias("imp").join(
        clicks.alias("clk"),
        expr("""
            imp.ad_id = clk.ad_id AND
            clk.click_time BETWEEN imp.impression_time AND imp.impression_time + INTERVAL 3 MINUTES
        """),
        "leftOuter"
    )

Saat Anda menggabungkan aliran terhadap tabel statis (gabungan rekam jepret), rekam jepret tabel statis disegarkan di awal setiap mikrobatch. Ini berarti rekaman dimensi yang terlambat tiba tidak diterapkan secara surut pada fakta yang sudah diproses. Jika aplikasi retroaktif diperlukan, gunakan tampilan materialisasi atau restrukturisasi alur.

Mengoptimalkan performa alur

Terapkan teknik ini untuk mengurangi biaya komputasi dan mempercepat pembaruan alur.

Untuk informasi selengkapnya, lihat Materialized views dan Optimalkan pemrosesan stateful dengan marka air.

Hindari file kecil

Memicu alur terlalu sering pada sumber volume rendah menulis sejumlah besar file kecil ke penyimpanan cloud. File-file kecil menurunkan kinerja pembacaan karena setiap file memerlukan pencarian metadata yang terpisah dan proses I/O tersendiri, dan operasi pencatatan API penyimpanan cloud diberi batasan dalam skala besar. Untuk menghindari hal ini, pilih interval pemicu yang cocok dengan volume data Anda: jalankan alur yang dipicu pada jadwal yang memungkinkan jumlah data yang bermakna terakumulasi di antara pembaruan, bukan terus menerus.

Menangani penyimpangan data

Penyimpangan data terjadi ketika nilai dalam kunci gabungan atau groupBy didistribusikan secara tidak merata di seluruh partisi, menyebabkan sejumlah kecil tugas memproses sebagian besar data. Ini menciptakan hotspot yang meningkatkan waktu pembaruan end-to-end. Gunakan pengklusteran cair untuk mengatasi penyimpangan dalam tabel tersimpan. Untuk pembobotan yang terjadi selama komputasi secara langsung, berikan tambahan acak pada kunci yang sangat miring dengan menambahkan akhiran wadah acak sebelum mengelompokkan dan menggabungkan dalam dua tahap.

Untuk informasi selengkapnya, lihat Menggunakan pengklusteran cair untuk tata letak data.

Menggunakan refresh inkremental untuk tampilan materialisasi

Saat Anda menggunakan tampilan materialisasi untuk agregasi besar, Lakeflow Spark Declarative Pipelines mencoba me-refreshnya secara bertahap — hanya memproses perubahan upstream sejak pembaruan terakhir daripada mengolah ulang tataan hasil lengkap. Penyegaran bertahap jauh lebih murah daripada menjalankan ulang kueri dari awal di setiap pemicu alur. Untuk memaksimalkan kemungkinan bahwa tampilan materialisasi dapat di-refresh secara bertahap, menulis kueri agregasi sederhana dan deterministik dan menghindari konstruksi yang mencegah pemrosesan bertahap, seperti fungsi non-deterministik.

Lihat Refresh inkremental untuk tampilan materialisasi.

Mengoptimalkan gabungan

Untuk gabungan di mana satu sisi adalah tabel dimensi kecil, tambahkan petunjuk siaran untuk menginstruksikan Spark menyiarkan tabel yang lebih kecil ke semua eksekutor alih-alih melakukan gabungan acak:

SQL

CREATE OR REFRESH MATERIALIZED VIEW enriched_orders AS
SELECT o.*, /*+ BROADCAST(p) */ p.product_name, p.category
FROM orders o
JOIN products p ON o.product_id = p.product_id;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import broadcast

@dp.materialized_view
def enriched_orders():
    orders = spark.read.table("orders")
    products = spark.read.table("products")
    return orders.join(broadcast(products), "product_id")

Untuk gabungan kedekatan rangkaian waktu (misalnya, menemukan peristiwa terdekat dalam rentang waktu), gunakan kondisi gabungan rentang dan pastikan kedua sisi memiliki marka air jika menggabungkan aliran, atau pertimbangkan peristiwa pra-binning ke dalam wadah waktu sebelum bergabung.

Memantau alur Anda

Log peristiwa alur adalah primitif pengamatan utama dalam Alur Deklaratif Lakeflow Spark. Setiap kali pipeline dijalankan, akan menulis rekaman terstruktur ke log peristiwa yang mencakup kemajuan eksekusi, hasil ekspektasi mutu data, linimasa data, dan detail kesalahan. Log peristiwa adalah tabel Delta yang bisa Anda kueri secara langsung.

Untuk mengkueri log peristiwa tanpa mengetahui jalur penyimpanan yang mendasar, gunakan event_log() fungsi bernilai tabel pada kluster bersama atau gudang SQL:

SELECT * FROM event_log('<pipeline-id>')
WHERE event_type = 'flow_progress'
ORDER BY timestamp DESC
LIMIT 100;

Buat dasbor kualitas data dengan mengkueri log peristiwa untuk metrik ekspektasi. Kolom details berisi struktur JSON berlapis dengan jumlah pass/fail untuk setiap batasan, yang dapat Anda gunakan untuk melacak tren kualitas dari waktu ke waktu dan pemberitahuan tentang regresi.

Untuk pemberitahuan berbasis peristiwa, gunakan kait peristiwa untuk memicu webhook kustom atau layanan pemberitahuan (seperti Slack atau PagerDuty) saat alur gagal atau ketika ambang batas kualitas data dilanggar. Pengait peristiwa adalah fungsi Python yang dijalankan sebagai respons terhadap peristiwa alur.

Untuk informasi selengkapnya, lihat Memantau pipeline, Log peristiwa pipeline, dan Menentukan pemantauan kustom pada pipeline dengan menggunakan event hook.

Menggunakan komputasi tanpa server

Databricks merekomendasikan komputasi tanpa server untuk alur baru. Dengan tanpa server, tidak ada konfigurasi kluster manual — Databricks mengelola infrastruktur secara otomatis. Alur tanpa server menggunakan penskalaan otomatis yang ditingkatkan yang dapat menskalakan secara horizontal (lebih banyak pelaksana) dan secara vertikal (ukuran eksekutor yang lebih besar) sebagai respons terhadap tuntutan beban kerja. Alur tanpa server selalu menggunakan Katalog Unity, sehingga tata kelola dan pelacakan silsilah dibangun secara default.

Untuk informasi selengkapnya, lihat Mengonfigurasi alur tanpa server.

Mengatur alur dengan arsitektur medali

Arsitektur medali mengatur data menjadi tiga lapisan logis — perunggu, perak, dan emas — masing-masing dengan tujuan yang berbeda. Memetakan jenis himpunan data Lakeflow Spark Declarative Pipelines ke lapisan kanan membuat tanggung jawab setiap lapisan tetap jelas dan membuat alur lebih mudah dipertahankan.

  • Perunggu: Gunakan tabel streaming untuk menyerap data mentah dari penyimpanan cloud, bus pesan, atau sumber CDC. Tabel perunggu mempertahankan data sumber mentah dengan transformasi minimal, sehingga memungkinkan lapisan perak atau emas untuk diolah kembali dari sumber di lapisan perunggu jika persyaratan berubah.
  • Perak: Gunakan tabel streaming untuk transformasi tingkat baris inkremental (pemfilteran, pembersihan, dan penguraian). Gunakan tampilan materialisasi saat logika lapisan perak melibatkan gabungan pengayaan terhadap tabel dimensi atau agregasi kompleks yang mendapat manfaat dari refresh inkremental.
  • Emas: Gunakan tampilan materialisasi untuk melakukan pra-komputasi agregasi, metrik, dan ringkasan yang disajikan ke dasbor, alat pelaporan, dan konsumen hilir.

Pisahkan penyerapan (perunggu) dan transformasi (perak dan emas) menjadi DAG alur yang berbeda jika memungkinkan. Memisahkan lapisan memungkinkan Anda menjadwalkan, memantau, dan memecahkan masalah setiap lapisan secara independen, dan kegagalan dalam alur transformasi tidak memblokir data baru agar tidak mendarat di perunggu.

Untuk informasi selengkapnya, lihat Tabel streaming dan Tampilan materialisasi.

  • Last updated on