Bagikan melalui


Apa itu arsitektur medallion lakehouse?

Arsitektur medali menjelaskan serangkaian lapisan data yang menunjukkan kualitas data yang disimpan di lakehouse. Azure Databricks merekomendasikan untuk mengambil pendekatan berlapis untuk membangun satu sumber kebenaran untuk produk data perusahaan.

Arsitektur ini menjamin atomitas, konsistensi, isolasi, dan durabilitas saat data melewati beberapa lapisan validasi dan transformasi sebelum disimpan dalam tata letak yang dioptimalkan untuk analitik yang efisien. Istilah perunggu (mentah), perak (divalidasi), dan emas (diperkaya) menggambarkan kualitas data di masing-masing lapisan ini.

Arsitektur medali sebagai pola desain data

Arsitektur medali adalah pola desain data yang digunakan untuk mengatur data secara logis. Tujuannya adalah untuk secara bertahap dan progresif meningkatkan struktur dan kualitas data saat mengalir melalui setiap lapisan arsitektur (dari perunggu ⇒ tabel lapisan Silver ⇒ Gold). Kadang-kadang, arsitektur medali juga disebut sebagai arsitektur multi-hop.

Dengan memajukan data melalui lapisan ini, organisasi dapat secara bertahap meningkatkan kualitas dan keandalan data, sehingga lebih cocok untuk kecerdasan bisnis dan aplikasi pembelajaran mesin.

Mengikuti arsitektur medali adalah praktik terbaik yang direkomendasikan tetapi bukan persyaratan.

Pertanyaan Perunggu Perak Emas
Apa yang terjadi di lapisan ini? Penyerapan data mentah Pembersihan dan validasi data Pemodelan dan agregasi dimensi
Siapa pengguna yang dimaksudkan? - Teknisi data
- Operasi data
- Tim kepatuhan dan audit
- Teknisi data
- Analis data (gunakan lapisan Silver untuk himpunan data yang lebih halus yang masih mempertahankan informasi terperinci yang diperlukan untuk analisis mendalam)
- Ilmuwan data (membangun model dan melakukan analitik tingkat lanjut)
- Analis bisnis dan pengembang BI
- Ilmuwan data dan teknisi pembelajaran mesin (ML)
- Eksekutif dan pembuat keputusan
- Tim operasional

Contoh arsitektur medali

Contoh arsitektur medali ini menunjukkan lapisan perunggu, perak, dan emas untuk digunakan oleh tim operasi bisnis. Setiap lapisan disimpan dalam skema katalog ops yang berbeda.

Arsitektur medali perunggu, perak, dan lapisan emas

  • Lapisan perunggu (ops.bronze): Menyerap data mentah dari penyimpanan cloud, Kafka, dan Salesforce. Tidak ada pembersihan atau validasi data yang dilakukan di sini.
  • Lapisan perak (ops.silver): Pembersihan dan validasi data dilakukan di lapisan ini.
    • Data tentang pelanggan dan transaksi dibersihkan dengan menghilangkan null dan mengkarantina rekaman yang tidak valid. Himpunan data ini digabungkan ke dalam himpunan data baru yang disebut customer_transactions. Ilmuwan data dapat menggunakan himpunan data ini untuk analitik prediktif.
    • Demikian pula, akun dan himpunan data peluang dari Salesforce bergabung untuk membuat account_opportunities, yang ditingkatkan dengan informasi akun.
    • Data leads_raw dibersihkan dalam himpunan data yang disebut leads_cleaned.
  • Lapisan emas (ops.gold): Lapisan ini dirancang untuk pengguna bisnis. Ini berisi lebih sedikit himpunan data daripada perak dan emas.
    • customer_spending: Rata-rata dan total pengeluaran untuk setiap pelanggan.
    • account_performance: Performa harian untuk setiap akun.
    • sales_pipeline_summary: Informasi tentang proses alur penjualan end-to-end.
    • business_summary: Informasi yang sangat agregat untuk staf eksekutif.

Menyerap data mentah ke lapisan perunggu

Lapisan perunggu berisi data mentah dan tidak valid. Data yang diserap dalam lapisan perunggu biasanya memiliki karakteristik berikut:

  • Berisi dan mempertahankan status mentah sumber data dalam format aslinya.
  • Ditambahkan secara bertahap dan tumbuh dari waktu ke waktu.
  • Ditujukan untuk konsumsi oleh beban kerja yang memperkaya data untuk tabel perak, bukan untuk akses oleh analis dan ilmuwan data.
  • Berfungsi sebagai sumber kebenaran tunggal, mempertahankan keakuratan data.
  • Memungkinkan pemrosesan ulang dan audit dengan menyimpan semua data historis.
  • Dapat berupa kombinasi transaksi streaming dan batch dari sumber, termasuk penyimpanan objek cloud (misalnya, S3, GCS, ADLS), bus pesan (misalnya, Kafka, Kinesis, dll.), dan sistem federasi (misalnya, Lakehouse Federation).

Membatasi pembersihan atau validasi data

Validasi data minimal dilakukan di lapisan perunggu. Untuk mencegah hilangnya data, Azure Databricks merekomendasikan menyimpan kebanyakan bidang sebagai string, VARIANT, atau biner untuk perlindungan dari perubahan skema yang tidak terduga. Kolom metadata mungkin ditambahkan, seperti bukti atau sumber data (misalnya, _metadata.file_name ).

Memvalidasi dan mendeduplikasi data di lapisan perak

Pembersihan dan validasi data dilakukan dalam lapisan perak.

Membangun tabel perak dari lapisan perunggu

Untuk membangun lapisan perak, baca data dari satu atau beberapa tabel perunggu atau perak, dan tulis data ke tabel perak.

Azure Databricks tidak merekomendasikan menulis ke tabel silver langsung dari pemasukan data. Jika Anda menulis langsung dari pengambilan data, Anda akan menyebabkan kesalahan karena perubahan skema atau catatan yang rusak di sumber data. Dengan asumsi semua sumber bersifat hanya-tambah, konfigurasikan sebagian besar pembacaan dari bronze sebagai pembacaan streaming. Pembacaan batch harus dicadangkan untuk himpunan data kecil (misalnya, tabel dimensi kecil).

Lapisan perak mewakili versi data yang divalidasi, dibersihkan, dan diperkaya. Lapisan perak:

  • Harus selalu menyertakan setidaknya satu representasi yang divalidasi dan tidak diagregasi dari setiap rekaman. Jika representasi agregat mendorong banyak beban kerja hilir, representasi tersebut mungkin berada di lapisan perak, tetapi biasanya berada di lapisan emas.
  • Adalah tempat Anda melakukan pembersihan data, deduplikasi, dan normalisasi.
  • Meningkatkan kualitas data dengan memperbaiki kesalahan dan inkonsistensi.
  • Menyusun data ke dalam format yang lebih dapat dikonsumsi untuk pemrosesan hilir.

Menegakkan kualitas data

Operasi berikut dilakukan dalam tabel perak:

  • Penerapan skema
  • Penanganan nilai null dan nilai yang hilang
  • Deduplikasi data
  • Penyelesaian masalah data yang tidak berurutan dan terlambat tiba
  • Pemeriksaan dan penegakan kualitas data
  • Evolusi skema
  • Pengecoran jenis
  • Penggabungan

Mulai pemodelan data

Adalah umum untuk mulai melakukan pemodelan data di lapisan perak, termasuk memilih cara mewakili data yang sangat berlapis atau semi terstruktur:

  • Gunakan VARIANT jenis data.
  • Gunakan JSON string.
  • Buat struktur, peta, dan array.
  • Meratakan skema atau menormalkan data ke dalam beberapa tabel.

Analisis daya dengan lapisan emas

Lapisan emas mewakili pandangan terperinci dari data yang mendukung analitik hilir, dasbor, pembelajaran mesin, dan aplikasi. Data lapisan emas sering kali sangat diagregasi dan difilter untuk periode waktu atau wilayah geografis tertentu. Ini berisi himpunan data yang bermakna secara semantik yang memetakan ke fungsi dan kebutuhan bisnis.

Lapisan emas:

  • Terdiri dari data agregat yang disesuaikan untuk analitik dan pelaporan.
  • Selaras dengan logika dan persyaratan bisnis.
  • Dioptimalkan untuk performa dalam kueri dan dasbor.

Selaras dengan logika dan persyaratan bisnis

Lapisan emas adalah tempat Anda akan memodelkan data untuk pelaporan dan analitik menggunakan model dimensi dengan membangun hubungan dan menentukan langkah-langkah. Analis dengan akses ke data dalam emas harus dapat menemukan data khusus domain dan menjawab pertanyaan.

Karena lapisan emas memodelkan domain bisnis, beberapa pelanggan membuat beberapa lapisan emas untuk memenuhi kebutuhan bisnis yang berbeda, seperti SDM, keuangan, dan IT.

Membuat agregat yang disesuaikan untuk analitik dan pelaporan

Organisasi sering kali perlu membuat fungsi agregat untuk langkah-langkah seperti rata-rata, jumlah, maksimum, dan minimum. Misalnya, jika bisnis Anda perlu menjawab pertanyaan tentang total penjualan mingguan, Anda dapat membuat tampilan materialisasi yang disebut weekly_sales yang melakukan pra-agregat data ini sehingga analis dan yang lain tidak perlu membuat ulang tampilan materialisasi yang sering digunakan.

CREATE OR REPLACE MATERIALIZED VIEW weekly_sales AS
SELECT week,
       prod_id,
       region,
       SUM(units) AS total_units,
       SUM(units * rate) AS total_sales
FROM orders
GROUP BY week, prod_id, region

Mengoptimalkan performa dalam kueri dan dasbor

Mengoptimalkan tabel berlapis emas untuk meningkatkan performa adalah praktik terbaik karena himpunan data ini sering diakses. Sejumlah besar data historis biasanya diakses di lapisan sliver dan tidak terwujud dalam lapisan emas.

Mengontrol biaya dengan menyesuaikan frekuensi penyerapan data

Mengontrol biaya dengan menentukan seberapa sering untuk menyerap data.

Frekuensi penyerapan data Biaya Latensi Contoh deklaratif Contoh prosedural
Pengambilan inkremental berkelanjutan Lebih tinggi Lebih rendah - Tabel Streaming menggunakan spark.readStream untuk mengambil dari penyimpanan awan atau bus pesan.
- Alur DLT yang memperbarui tabel streaming ini berjalan terus menerus.
- Kode Structured Streaming menggunakan spark.readStream di notebook untuk mengimpor data dari penyimpanan cloud atau bus pesan ke dalam tabel Delta.
- Buku catatan diorkestrasi dengan menggunakan pekerjaan Azure Databricks dengan pemicu pekerjaan yang berkelanjutan.
Penyerapan bertahap yang dipicu Turunkan Lebih tinggi - Pengambilan Data Tabel Streaming dari penyimpanan cloud atau bus pesan menggunakan spark.readStream.
- Alur yang memperbarui tabel streaming ini dipicu oleh pemicu terjadwal dari pekerjaan atau pemicu kedatangan berkas.
- Kode Streaming Terstruktur di notebook dengan Trigger.Available pemicu.
- Notebook ini dipicu oleh pemicu terjadwal dari suatu pekerjaan atau pemicu kedatangan file.
Penyerapan batch dengan penyerapan inkremental manual lebih rendah Tertinggi, karena pengoperasian yang jarang. - Pemasukan Tabel Streaming dari penyimpanan cloud menggunakan spark.read.
- Tidak menggunakan Streaming Terstruktur. Sebagai gantinya, gunakan metode primitif seperti timpa partisi untuk memperbarui seluruh partisi sekaligus.
- Membutuhkan arsitektur hulu yang luas untuk menyiapkan pemrosesan bertahap, yang memungkinkan biaya yang mirip dengan baca/tulis Streaming Terstruktur.
- Juga memerlukan pemartisian data sumber oleh bidang datetime dan kemudian memproses semua rekaman dari partisi tersebut ke target.