Proses ekstrak terbalik, transformasi, dan pemuatan (ETL) dengan Azure Cosmos DB untuk NoSQL

Gudang data cloud dan data lake memperkaya data, memfokuskan informasi, dan mengaktifkan analitik yang kuat. Tetapi nilai nyata data terletak pada mengubah wawasan menjadi keputusan dunia nyata dan pengalaman pelanggan. Untuk mencapai tujuan ini, data yang bersih dan andal harus dipindahkan dari gudang / data lake ke dalam sistem operasional. ETL terbalik memindahkan data dari lapisan gudang data Anda, seperti Delta Lake di Azure Databricks atau Microsoft Fabric, kembali ke sistem operasional. Langkah migrasi ini memungkinkan aplikasi hilir menggunakan data terbaru yang diperkaya untuk analitik operasional real time. Reverse ETL memainkan peran penting dalam mengoptimalkan potensi aset data Anda dengan menjembatani kesenjangan antara analitik dan operasi, sehingga memungkinkan pengambilan keputusan yang lebih baik.

Azure Cosmos DB for NoSQL dirancang untuk latensi ultra rendah, distribusi global, dan skalabilitas NoSQL, menjadikannya ideal untuk aplikasi real time. Dengan Reverse ETL, Anda dapat menyinkronkan data yang diperkaya Delta ke Azure Cosmos DB, memungkinkan analitik operasional real time. Anda dapat menggunakan pola ini untuk mendorong data seperti katalog produk, info pelanggan yang dipersonalisasi, pembaruan harga, data inventaris, dan rekomendasi fitur. Anda dapat mendorong data ini ke penyimpanan data operasional Anda, memberdayakan aplikasi hilir untuk membuat keputusan berbasis data secara instan.

Arsitektur solusi

Arsitektur yang disederhanakan untuk mengimplementasikan ETL terbalik terdiri dari Apache Spark dan Azure Databricks. Arsitektur ini mengekstrak data yang dibersihkan dan diperkaya dari sumber seperti Tabel Delta dan menulis data kembali ke penyimpanan operasional di Azure Cosmos DB untuk NoSQL.

Diagram arsitektur ETL terbalik yang terdiri dari beberapa komponen yang memigrasikan data. Komponen tersebut mencakup sumber data yang dapat mencakup data produk, CRM, pesanan, atau iklan. Data dari sumber data kemudian diserap ke dalam gudang data atau data lake menggunakan alur kerja ETL. Terakhir, data dikirim dari penyimpanan perantara menggunakan alur kerja ETL terbalik. Data dikirim ke penyimpanan data operasional seperti Azure Cosmos DB untuk NoSQL.

Diagram ini mencakup komponen-komponen berikut:

• Sumber data yang menyertakan data seperti; data produk, data CRM, informasi pesanan, dan informasi iklan.

• Alur kerja ETL memindahkan data dari sumber data asli ke gudang data atau data lake untuk menyimpan dan memperkaya data menggunakan solusi seperti Azure Databricks atau Microsoft Fabric.

• Membalikkan alur kerja ETL untuk memigrasikan data yang diperkaya ke penyimpanan data operasional menggunakan tabel Apache Spark dan Delta

• Penyimpanan data operasional seperti Azure Cosmos DB untuk NoSQL agar dapat menggunakan data yang diperkaya dalam aplikasi real-time.

Proses ETL terbalik memungkinkan skenario seperti:

• Keputusan Real-Time: Aplikasi mendapatkan akses ke data terkini tanpa mengandalkan pada analis atau SQL.

• Aktivasi Data: Insight disalurkan di mana dibutuhkan—bukan hanya di dasbor.

• Sumber Kebenaran Terpadu: Delta Lake bertindak sebagai lapisan kanonis, memastikan konsistensi di seluruh sistem.

Tahap penyerapan data

Untuk skenario seperti penyimpanan fitur, mesin rekomendasi, deteksi penipuan, atau katalog produk real time, penting untuk memisahkan aliran data menjadi dua tahap. Tahapan ini mengasumsikan Anda memiliki alur ETL terbalik dari Delta Lake ke Azure Cosmos DB untuk NoSQL.

Diagram dua tahap ETL terbalik dari Delta Lake ke Azure Cosmos DB untuk NoSQL. Tahap pertama memuat data menggunakan proses batch satu kali. Tahap kedua menggunakan perubahan penangkapan data untuk menyinkronkan data. Kedua tahap menghasilkan data ke dalam Azure Cosmos DB untuk NoSQL sebagai penyimpanan data operasional.

Tahapan dalam diagram ini terdiri dari:

1. Beban awal: Beban awal adalah langkah proses batch satu kali untuk menyerap semua data historis dari Tabel Delta ke Azure Cosmos DB untuk NoSQL. Ini mengatur fondasi untuk alur ETL terbalik Anda dengan memastikan penyimpanan data operasional memiliki data historis lengkap. Beban ini adalah langkah mendasar sebelum memulai sinkronisasi data inkremental.

2. Mengubah sinkronisasi penangkapan data (CDC): Langkah ini mengimplementasikan sinkronisasi perubahan bertahap dan berkelanjutan dari Tabel Delta ke Azure Cosmos DB untuk NoSQL. Perubahan dalam tabel delta dapat diambil setelah mengaktifkan Umpan Data Perubahan Delta (CDF). Anda dapat menerapkan sinkronisasi penangkapan data perubahan (CDC) berbasis batch atau berbasis streaming.

Ada dua opsi untuk sinkronisasi CDC ke Azure Cosmos DB untuk NoSQL:

• Sinkronisasi CDC Batch: Opsi ini berjalan sesuai jadwal (misalnya harian atau per jam) dan memuat rekam jepret data bertahap berdasarkan perubahan yang diambil sejak versi atau tanda waktu terakhir.

  Petunjuk / Saran

  Beralih ke rekam jepret Azure Cosmos DB yang lebih baru untuk menghindari inkonsistensi data saat volume bertahap besar dimuat dari tabel delta ke Azure Cosmos DB untuk NoSQL. Misalnya, saat menulis ke kontainer baru atau menggunakan bendera versi, balikkan penunjuk ke cuplikan layar yang lebih baru setelah data baru dimuat sepenuhnya.

• Streaming sinkronisasi CDC: Opsi ini terus menyinkronkan perubahan inkremental mendekati real-time, menjaga sistem target tetap terbarui dengan jeda minimal. Opsi ini menggunakan streaming terstruktur Apache Spark untuk terus menangkap dan menulis perubahan. Tabel delta bertindak sebagai sumber streaming dengan readChangeData = true, dan konektor Azure Cosmos DB for NoSQL bertindak sebagai sink streaming.

  Petunjuk / Saran

  Tentukan lokasi titik pemeriksaan untuk memastikan kemajuan dilacak dan penulisan duplikat dihindari.

Praktik terbaik

• Gunakan batch job Apache Spark dengan konektor Azure Cosmos DB untuk NoSQL untuk melakukan langkah pemuatan awal.

• Optimalkan laju penyerapan dengan beralih ke laju standar yang telah disediakan jika beban awal diperkirakan akan mengonsumsi sejumlah besar RU/detik relatif terhadap laju yang Anda alokasikan. Secara khusus, gunakan throughput yang disediakan secara standar jika unit permintaan maksimum per detik (RU/dtk) digunakan secara konsisten selama sebagian besar waktu dalam proses pemuatan awal. Jangan gunakan throughput skala otomatis untuk langkah beban awal dalam skenario ini.

  Petunjuk / Saran

  Jika metrik konsumsi RU yang dinormalisasi secara konsisten 100%, maka metrik menunjukkan bahwa beban awal secara konsisten menggunakan unit permintaan skala otomatis maksimum (RU). Ambang batas ini adalah indikator yang jelas bahwa skenario ini berlaku untuk beban kerja Anda dan Anda harus menggunakan throughput standar yang disediakan.

• Pilih kunci partisi efektif yang memaksimalkan paralelisme. Untuk informasi selengkapnya, lihat rekomendasi partisi dan kunci partisi.

• Rencanakan jumlah total partisi dan total RU/dtk di semua partisi untuk ingesti data berukuran besar. Untuk informasi dan panduan lebih lanjut, lihat rekomendasi untuk partisi dan throughput.

• Gunakan kontrol throughput Apache Spark untuk membatasi konsumsi unit permintaan (RU) dari tugas. Pengendalian throughput membantu mencegah kelebihan beban kontainer operasi target.

• Gunakan throughput dengan autoscale bila memungkinkan di Azure Cosmos DB untuk NoSQL untuk sinkronisasi CDC, karena autoscale meningkatkan/menurunkan RU/s secara dinamis sesuai penggunaan. Auto-skala throughput sangat ideal untuk beban kerja yang bersifat periodik dan mengalami lonjakan seperti pekerjaan sinkronisasi terjadwal CDC. Untuk informasi selengkapnya, lihat rekomendasi throughput.

• Perkirakan durasi penyerapan awal untuk langkah pemuatan data awal Anda. Untuk informasi selengkapnya dan sampel, lihat estimasi throughput.

Langkah selanjutnya

Menerapkan ETL terbalik dengan Azure Databricks