Artikel ini menjelaskan bagaimana kantor perencanaan kota fiksi dapat menggunakan solusi ini. Solusi ini menyediakan jalur data end-to-end yang mengikuti pola arsitektur MDW, bersama dengan proses DevOps dan DataOps yang sesuai, untuk menilai penggunaan parkir dan membuat keputusan bisnis yang lebih tepat.
Sistem
Diagram berikut menunjukkan arsitektur solusi secara keseluruhan.
Unduh file Visio arsitektur ini.
Aliran data
Azure Data Factory mengatur dan Azure Data Lake Storage Gen2 menyimpan data:
API layanan web parkir kota Contoso tersedia untuk mentransfer data dari tempat parkir.
Ada pekerjaan penyalinan pabrik data yang mentransfer data ke dalam skema Landing.
Selanjutnya, Azure Databricks membersihkan dan menstandardisasi data. Dibutuhkan data mentah dan kondisi sehingga ilmuwan data dapat menggunakannya.
Jika validasi mengungkapkan data yang buruk, itu akan dibuang ke skema Malformed.
Penting
Orang-orang telah bertanya mengapa data tidak divalidasi sebelum disimpan di Data Lake Storage. Alasannya adalah bahwa validasi mungkin memperkenalkan bug yang dapat merusak himpunan data. Jika Anda memperkenalkan bug pada langkah ini, Anda dapat memperbaiki bug dan memutar ulang saluran Anda. Jika Anda mencadangkan data buruk sebelum menambahkannya ke Data Lake Storage, data yang rusak tidak berguna karena Anda tidak dapat memutar ulang alur Anda.
Ada langkah transformasi Azure Databricks kedua yang mengubah data menjadi format yang dapat Anda simpan di gudang data.
Terakhir, alur menyajikan data dalam dua cara berbeda:
Databricks membuat data tersedia bagi ilmuwan data sehingga mereka dapat melatih model.
Polybase memindahkan data dari data lake ke Azure Synapse Analytics dan Power BI mengakses data dan menyajikannya kepada pengguna bisnis.
Komponen
Solusinya menggunakan komponen ini:
Detail skenario
Gudang data modern (MDW) memungkinkan Anda dengan mudah menyatukan semua data dalam skala apa pun. Tidak masalah apakah itu data terstruktur, tidak terstruktur, atau semi terstruktur. Anda dapat memperoleh wawasan tentang MDW melalui dasbor analitik, laporan operasional, atau analitik tingkat lanjut untuk semua pengguna Anda.
Menyiapkan lingkungan MDW untuk lingkungan pengembangan (dev) dan produksi (prod) adalah kompleks. Mengotomatiskan proses adalah kuncinya. Ini membantu meningkatkan produktivitas sambil meminimalkan risiko kesalahan.
Artikel ini menjelaskan bagaimana kantor perencanaan kota fiksi dapat menggunakan solusi ini. Solusi ini menyediakan jalur data end-to-end yang mengikuti pola arsitektur MDW, bersama dengan proses DevOps dan DataOps yang sesuai, untuk menilai penggunaan parkir dan membuat keputusan bisnis yang lebih tepat.
Persyaratan solusi
Kemampuan untuk mengumpulkan data dari berbagai sumber atau sistem.
Infrastruktur sebagai kode: sebarkan lingkungan dev dan staging (stg) baru secara otomatis.
Menyebarkan perubahan aplikasi di lingkungan yang berbeda secara otomatis:
Menerapkan alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD).
Gunakan gerbang penyebaran untuk persetujuan manual.
Alur sebagai Kode: pastikan definisi alur CI/CD berada dalam kontrol sumber.
Lakukan tes integrasi pada perubahan menggunakan himpunan data sampel.
Jalankan alur secara terjadwal.
Mendukung pengembangan tangkas di masa depan, termasuk penambahan beban kerja ilmu data.
Dukungan untuk keamanan tingkat baris dan tingkat objek:
Fitur keamanan tersedia di SQL Database.
Anda juga dapat menemukannya di Azure Synapse Analytics, Azure Analysis Services, dan Power BI.
Mendukung 10 pengguna dasbor bersamaan dan 20 pengguna daya bersamaan.
Alur data harus melakukan validasi data dan menyaring catatan yang salah ke penyimpanan tertentu.
Mendukung pemantauan.
Konfigurasi terpusat dalam penyimpanan aman seperti Azure Key Vault.
Kemungkinan kasus penggunaan
Artikel ini menggunakan kota fiksi Contoso untuk menggambarkan skenario kasus penggunaan. Dalam narasinya, Contoso memiliki dan mengelola sensor parkir untuk kota. Selain itu juga memiliki API yang terhubung ke dan mendapatkan data dari sensor. Mereka membutuhkan platform yang akan mengumpulkan data dari berbagai sumber. Data kemudian harus divalidasi, dibersihkan, dan diubah menjadi skema yang dikenal. Perencana kota Contoso kemudian dapat menjelajahi dan menilai data laporan penggunaan parkir dengan alat visualisasi data, seperti Power BI, untuk menentukan apakah mereka membutuhkan lebih banyak tempat parkir atau sumber daya terkait.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Pertimbangan di bagian ini meringkas pembelajaran utama dan praktik terbaik yang ditunjukkan oleh solusi ini:
Catatan
Setiap pertimbangan di bagian ini menautkan ke bagian Pembelajaran Kunci terkait di dokumen untuk contoh solusi sensor parkir di GitHub.
Keamanan
Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.
Keunggulan Operasional
Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.
Menyebarkan skenario ini
Daftar berikut berisi langkah-langkah tingkat tinggi yang diperlukan untuk menyiapkan solusi Sensor Parkir dengan Alur dan Rilis yang sesuai. Anda dapat menemukan langkah-langkah penyiapan terperinci dan prasyarat di repositori Azure Samples ini.
Penyiapan dan penyebaran
Penyiapan awal: Instal prasyarat apa pun, impor repositori Azure Samples GitHub ke repositori Anda sendiri, dan setel variabel lingkungan yang diperlukan.
Menyebarkan sumber daya Azure: Solusinya dilengkapi dengan skrip penyebaran otomatis. Ini menyebarkan semua sumber daya Azure yang diperlukan dan perwakilan layanan Microsoft Entra per lingkungan. Skrip ini juga menyebarkan Azure Pipelines, grup variabel, dan koneksi layanan.
Siapkan integrasi Git di Dev Data Factory: Konfigurasikan integrasi Git untuk bekerja dengan repositori GitHub yang diimpor.
Lakukan build dan rilis awal: Buat contoh perubahan di Data Factory, seperti mengaktifkan pemicu jadwal, lalu lihat perubahan yang diterapkan secara otomatis di seluruh lingkungan.
Sumber daya yang disebarkan
Jika penyebaran berhasil, harus ada tiga grup sumber daya di Azure yang mewakili tiga lingkungan: dev, stg, dan prod. Juga harus ada alur build dan rilis end-to-end di Azure DevOps yang dapat secara otomatis menyebarkan perubahan di ketiga lingkungan ini.
Untuk daftar mendetail mengenai semua sumber daya, lihat bagian Sumber Daya yang Disebarkan pada README DataOps - Parking Sensor Demo.
Integrasi Berkelanjutan dan Penyediaan Berkelanjutan (CI/CD)
Diagram di bawah menunjukkan proses dan urutan CI/CD untuk alur build dan rilis.
Unduh file Visio arsitektur ini.
Pengembang berkembang di lingkungan kotak pasir mereka sendiri dalam grup sumber daya dev dan menerapkan perubahan ke cabang Git mereka sendiri yang berumur pendek. Contohnya,
<developer_name>/<branch_name>.Saat perubahan selesai, pengembang mengajukan permintaan pull (PR) ke cabang utama untuk ditinjau. Melakukannya secara otomatis memulai alur validasi PR, yang menjalankan pengujian unit, linting, dan build paket aplikasi tingkat data (DACPAC).
Setelah validasi PR selesai, penerapan ke menu utama akan memicu alur build yang memublikasikan semua artefak build yang diperlukan.
Penyelesaian alur build yang berhasil akan memicu tahap pertama dari alur rilis. Melakukannya menyebarkan artefak build publikasi ke lingkungan dev, kecuali untuk Data Factory.
Pengembang secara manual menerbitkan ke Dev Data Factory dari cabang kolaborasi (utama). Penerbitan manual memperbarui templat Azure Resource Manager di
adf_publishcabang.Penyelesaian tahap pertama yang berhasil memicu gerbang persetujuan manual.
Pada Persetujuan, alur rilis berlanjut dengan tahap kedua, menyebarkan perubahan ke lingkungan stg.
Menjalankan tes integrasi untuk menguji perubahan di lingkungan stg.
Setelah berhasil menyelesaikan tahap kedua, alur memicu gerbang persetujuan manual kedua.
Pada Persetujuan, alur rilis berlanjut dengan tahap ketiga, menyebarkan perubahan ke lingkungan prod.
Untuk informasi selengkapnya, baca bagian Alur Build dan Rilis di README.
Pengujian
Solusinya mencakup dukungan untuk pengujian unit dan pengujian integrasi. Ini menggunakan pytest-Data Factory dan Nutter Testing Framework. Untuk informasi selengkapnya, lihat bagian Pengujian README.
Observabilitas dan pemantauan
Solusinya mendukung observabilitas dan pemantauan untuk Databricks dan Data Factory. Untuk informasi selengkapnya, lihat bagian Observabilitas/Pemantauan dari README.
Langkah berikutnya
Jika Anda ingin menerapkan solusi, ikuti langkah-langkah di bagian Cara menggunakan sampel di DataOps - Demo Sensor Parkir README.
Contoh kode solusi di GitHub
Observabilitas/pemantauan
Azure Databricks
- Memantau Azure Databricks dengan Azure Monitor
- Memantau Pekerjaan Azure Databricks dengan Application Insights
Data Factory
- Memantau Azure Data Factory dengan Azure Monitor
- Membuat peringatan untuk memantau alur pabrik data Anda secara proaktif
Azure Synapse Analytics
- Memantau pemanfaatan sumber daya dan aktivitas kueri di Azure Synapse Analytics
- Memantau beban kerja kumpulan SQL Azure Synapse Analytics Anda menggunakan DMV
Azure Storage
Ketahanan dan pemulihan bencana
Azure Databricks
Data Factory
Azure Synapse Analytics
Azure Storage
- Pemulihan bencana dan kegagalan akun penyimpanan
- Praktik terbaik untuk menggunakan Azure Data Lake Storage Gen2 – Ketersediaan tinggi dan Pemulihan Bencana
- Azure Storage Redundancy
Penelusuran terperinci
Untuk panduan terperinci tentang solusi dan konsep utama, tonton rekaman video berikut: DataDevOps untuk Gudang Data Modern di Microsoft Azure