Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Alur Lakeflow menyediakan kerangka kerja deklaratif untuk membangun alur data batch dan streaming di SQL dan Python. Konsep intinya adalah alur, alur, tabel streaming, tampilan materialisasi, dan sink, yang bekerja sama untuk memproses data dengan orkestrasi otomatis dan pembaruan inkremental.
Alur Lakeflow memperluas Apache Spark™ Declarative Pipelines (SDP). Untuk mempelajari selengkapnya tentang SDP dan perbandingannya dengan alur Lakeflow, lihat Alur Deklaratif Apache Spark.
Tip
Baru mengenal pipeline? Mulai dari Cara menggunakan pipeline Lakeflow untuk memahami cara menggunakan pipeline di seluruh siklus hidupnya, serta alasan penggunaannya, beserta tautan ke tugas pada setiap tahap.
Note
Alur Lakeflow memerlukan paket Premium. Hubungi tim akun Databricks Anda untuk informasi selengkapnya.
Apa manfaat dari alur?
Berbeda dengan mengembangkan proses rekayasa data dengan API Apache Spark dan Spark Structured Streaming pada Databricks Runtime menggunakan orkestrasi manual melalui Pekerjaan Lakeflow, sifat deklaratif alur memberikan manfaat berikut:
- Orkestrasi otomatis: Pipeline menjalankan langkah-langkah pemrosesan (disebut "flow") dalam urutan yang benar dengan paralelisme maksimum, serta mencoba kembali kegagalan sementara secara bertahap—mulai dari tugas Spark, ke flow, hingga seluruh pipeline.
- Pemrosesan deklaratif: Fungsi deklaratif mengurangi ratusan baris kode Spark manual dan Streaming Terstruktur menjadi beberapa baris. API CDC OTOMATIS menangani peristiwa Change Data Capture (CDC) —termasuk SCD Tipe 1 dan Tipe 2—tanpa kode manual untuk peristiwa yang tidak berurutan atau konsep streaming seperti marka air.
- Pemrosesan inkremental: Mesin pemrosesan inkremental menjaga tampilan terwujud tetap mutakhir: Anda menulis logika transformasi dengan semantik batch, dan mesin hanya memproses ulang data sumber yang baru atau berubah jika memungkinkan.
Konsep Utama
Diagram di bawah ini menggambarkan konsep alur yang paling penting.
Himpunan data
Alur menghasilkan tiga jenis himpunan data, masing-masing dengan semantik pemrosesan yang berbeda:
| Jenis himpunan data | Bagaimana rekaman diproses |
|---|---|
| Tabel streaming | Setiap rekaman diproses tepat satu kali, dengan asumsi sumber khusus tambahan. Tabel streaming cocok untuk penyerapan dan pemrosesan tambahan data yang terus berkembang. |
| Tampilan Tervirtualisasi | Hasil dikomputasi ulang sesuai kebutuhan untuk mencerminkan status data saat ini. Tampilan materialisasi cocok untuk transformasi, agregasi, atau hasil pra-komputasi yang digunakan oleh beberapa himpunan data hilir. |
| Tampilan | Dievaluasi sesuai permintaan, tidak bertahan. Gunakan view untuk transformasi perantara dan pemeriksaan yang tidak perlu dipublikasikan ke katalog. |
Tabel streaming adalah bentuk tabel terkelola Katalog Unity yang juga merupakan target streaming. Tabel streaming dapat memiliki satu atau beberapa alur streaming (Tambahkan, CDC OTOMATIS) yang ditulis ke dalamnya. Anda dapat menentukan alur streaming secara eksplisit dan terpisah dari tabel streaming targetnya, atau secara implisit sebagai bagian dari definisi tabel streaming.
Materialized view juga merupakan bentuk tabel dikelola oleh Katalog Unity dan merupakan target batch. Tampilan materialisasi dapat memiliki satu atau beberapa alur tampilan materialisasi yang ditulis ke dalamnya. Tampilan materialisasi berbeda dari tabel streaming karena Anda selalu menentukan alur secara implisit sebagai bagian dari definisi tampilan materialisasi.
Untuk detail selengkapnya, lihat Tabel Streaming dan Tampilan Termaterialisasi.
Kapan menggunakan tampilan, tampilan materialisasi, dan tabel streaming
Saat menerapkan kueri alur, pilih jenis himpunan data yang paling sesuai dengan kasus penggunaan Anda.
Pertimbangkan untuk menggunakan tampilan untuk:
- Pecahkan kueri besar atau kompleks menjadi kueri yang lebih mudah dikelola.
- Validasi hasil perantara menggunakan ekspektasi.
- Kurangi biaya penyimpanan dan komputasi untuk hasil yang tidak perlu Anda pertahankan. Karena tabel terwujud, tabel memerlukan sumber daya komputasi dan penyimpanan tambahan.
Pertimbangkan untuk menggunakan tampilan materialisasi saat:
- Beberapa kueri lanjutan memproses tabel. Karena tampilan materialisasi menyimpan hasilnya, kueri hilir membaca hasil yang telah dikomputasi sebelumnya alih-alih menghitung ulang kueri pada setiap akses.
- Alur, pekerjaan, atau kueri lainnya memanfaatkan tabel. Karena tampilan terwujud dimaterialisasikan sebagai tabel Unity Catalog, konsumen di luar pipeline yang mendefinisikannya dapat melakukan kueri terhadapnya. View tidak dimaterialisasi, sehingga Anda hanya dapat menggunakannya di dalam pipeline yang sama.
- Anda ingin memeriksa hasil kueri selama pengembangan. Karena tampilan terwujud dimaterialkan dan dapat diakses melalui kueri di luar alur pemrosesan, Anda dapat memverifikasi kebenaran hasil komputasi selama pengembangan. Setelah memvalidasi, konversi kueri yang tidak memerlukan materialisasi menjadi view.
- Kueri Anda melakukan agregasi atau gabungan, atau data sumber dapat berubah karena pembaruan dan penghapusan, bukan hanya bertambah. Tampilan materialisasi menjaga hasilnya tetap konsisten dengan status data sumber saat ini, sedangkan tabel streaming dirancang untuk sumber khusus tambahan dan memproses setiap rekaman satu kali.
Pertimbangkan untuk menggunakan tabel streaming ketika:
- Kueri didefinisikan terhadap sumber data yang terus menerus atau bertambah secara bertahap.
- Hasil kueri harus dihitung secara bertahap.
- Alur membutuhkan throughput tinggi dan latensi rendah.
Note
Tabel streaming selalu didefinisikan berdasarkan sumber streaming. Anda juga dapat menggunakan sumber streaming dengan AUTO CDC ... INTO untuk menerapkan pembaruan dari umpan CDC. Lihat API CDC Otomatis: Menyederhanakan penangkapan perubahan data menggunakan pipeline.
Flows
Flow adalah konsep dasar pemrosesan data dalam pipeline, dan mendukung semantik streaming maupun batch. Alur membaca data dari sumber, menerapkan logika pemrosesan yang ditentukan pengguna, dan menulis hasilnya ke dalam target. Pipeline menggunakan jenis aliran streaming yang sama (Append, Update, Complete) seperti pada Spark Structured Streaming. (Saat ini, hanya alur Tambahkan dan Perbarui yang terekspos.) Untuk detail selengkapnya, lihat mode output di Streaming Terstruktur.
Pipeline juga menyediakan tipe alur tambahan:
- AUTO CDC adalah alur streaming unik dalam pipeline Lakeflow yang menangani peristiwa CDC yang datang tidak berurutan dan mendukung SCD Tipe 1 maupun SCD Tipe 2. CDC Otomatis tidak tersedia di SDP.
- Tampilan termaterialisasi adalah alur batch dalam pipeline yang, jika memungkinkan, hanya memproses data baru dan perubahan pada tabel sumber.
Untuk detailnya, lihat Memuat dan memproses data secara bertahap dengan alur Lakeflow.
Sinks
Sink adalah target streaming untuk alur dan mendukung tabel Delta, topik Apache Kafka, topik Azure EventHubs, dan sumber data Python kustom. Sink dapat memiliki satu atau beberapa alur streaming (Tambahkan, Perbarui) yang ditulis ke dalamnya.
Untuk detailnya, lihat Sink di alur Lakeflow.
Rantai Pengolahan
Pipeline adalah unit pengembangan dan eksekusi, serta merupakan kontainer untuk flow, tabel streaming, tampilan termaterialisasi, dan penampung yang Anda definisikan. Anda membangun alur dengan mendefinisikan objek ini dalam kode sumber alur Anda lalu menjalankan alur. Saat alur Anda berjalan, alur menganalisis dependensi objek yang Anda tentukan dan mengatur urutan eksekusi dan paralelisasinya secara otomatis.
Untuk detailnya, lihat Apa itu alur?.
Anda juga dapat menentukan tampilan materialisasi mandiri dan tabel streaming di luar alur Lakeflow, di mana Azure Databricks mengelola alur untuk Anda. Untuk membandingkan dua pendekatan, lihat Alur mandiri vs. Alur Lakeflow.
Sebuah pipeline berjalan dalam mode terpicu atau berkelanjutan, yang menentukan apakah pipeline tersebut memperbarui data yang tersedia dan berhenti, atau menjaga tabel tetap mutakhir saat data baru tiba. Untuk membandingkan kedua mode, lihat Mode pipeline terpicu vs. kontinu.
Penyerapan data
Pipeline mendukung semua sumber data yang tersedia di Azure Databricks. Databricks merekomendasikan penggunaan tabel streaming untuk sebagian besar kasus penggunaan pemrosesan data masuk. Untuk file di penyimpanan objek cloud, Auto Loader menyediakan pemuatan bertahap dan idempotensi. Untuk data streaming, alur dapat menyerap langsung dari bus pesan seperti Apache Kafka, Azure Event Hubs, Amazon Kinesis, dan Google Pub/Sub. Lihat Memuat data dalam alur.
Kualitas data
Ekspektasi adalah klausa opsional pada himpunan data yang memvalidasi data saat mengalir melalui alur. Anda menentukan harapan sebagai batasan boolean SQL dan menentukan apa yang terjadi ketika rekaman gagal: memperingatkan, menghilangkan rekaman, atau gagal memperbarui. Lihat Mengelola kualitas data dengan ekspektasi alur kerja.
Integrasi Delta
Semua tabel yang dibuat dan dikelola oleh pipeline adalah tabel Delta. Mereka memiliki garansi yang sama seperti Delta Lake, termasuk transaksi ACID, time travel, dan penegakan skema. Pipeline menambahkan properti tabel tambahan dan melakukan pemeliharaan otomatis menggunakan pengoptimalan prediktif, termasuk operasi OPTIMIZE dan VACUUM. Lihat Apa itu Delta Lake di Azure Databricks?.