DataOps untuk gudang data modern

Azure Data Factory
Azure Databricks
Azure DevOps
Azure Key Vault
Azure Synapse Analytics

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.

Diagram arsitektur yang menunjukkan DataOps untuk gudang data modern.

Unduh file Visio arsitektur ini.

Aliran data

Azure Data Factory (ADF) mengatur dan Azure Data Lake Storage (ADLS) Gen2 menyimpan data:

  1. API layanan web parkir kota Contoso tersedia untuk mentransfer data dari tempat parkir.

  2. Ada pekerjaan penyalinan ADF yang mentransfer data ke skema Arahan.

  3. Selanjutnya, Azure Databricks membersihkan dan menstandardisasi data. Dibutuhkan data mentah dan kondisi sehingga ilmuwan data dapat menggunakannya.

  4. Jika validasi mengungkapkan data yang buruk, itu akan dibuang ke skema Malformed.

    Penting

    Orang-orang bertanya mengapa data tidak divalidasi sebelum disimpan di ADLS. 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 membuang data yang buruk sebelum Anda menambahkannya ke ADLS, maka data yang rusak tidak berguna karena Anda tidak dapat memutar ulang saluran Anda.

  5. Ada langkah transformasi Azure Databricks kedua yang mengubah data menjadi format yang dapat Anda simpan di gudang data.

  6. Terakhir, alur menyajikan data dalam dua cara berbeda:

    1. Databricks membuat data tersedia bagi ilmuwan data sehingga mereka dapat melatih model.

    2. 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 (AAS), 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.

Ketersediaan Parkir Jalan

Pertimbangan

Daftar berikut ini merangkum pembelajaran utama dan praktik terbaik yang ditunjukkan oleh solusi ini:

Catatan

Setiap item dalam daftar di bawah tertaut ke bagian Pembelajaran Utama terkait di dokumen untuk contoh solusi sensor parkir di GitHub.

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

  1. Penyiapan awal: Instal prasyarat apa pun, impor repositori Azure Samples GitHub ke repositori Anda sendiri, dan setel variabel lingkungan yang diperlukan.

  2. 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.

  3. Siapkan integrasi git di dev Data Factory: Konfigurasikan integrasi git untuk bekerja dengan repositori GitHub yang diimpor.

  4. 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 eilis 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.

Diagram yang memperlihatkan proses dan urutan untuk build dan rilis.

Unduh file Visio arsitektur ini.

  1. Pengembang berkembang di lingkungan kotak pasir mereka sendiri dalam grup sumber daya dev dan melakukan perubahan ke cabang git mereka sendiri yang berumur pendek. Contohnya,<developer_name>/<branch_name>.

  2. Saat perubahan selesai, pengembang mengajukan permintaan pull (PR) ke cabang utama untuk ditinjau. Melakukannya secara otomatis memulai jalur validasi PR, yang menjalankan pengujian unit, linting, dan build paket aplikasi tingkat data (DACPAC).

  3. Setelah validasi PR selesai, penerapan ke menu utama akan memicu alur build yang memublikasikan semua artefak build yang diperlukan.

  4. Penyelesaian alur build yang berhasil akan memicu tahap pertama dari alur rilis. Melakukannya menyebarkan artefak build terpublikasi ke dalam lingkungan dev, kecuali untuk ADF.

    Pengembang mempublikasikan secara manual ke dev ADF dari cabang kolaborasi (utama). Penerbitan manual memperbarui templat Azure Resource Manager di adf_publish cabang.

  5. Penyelesaian tahap pertama yang berhasil memicu gerbang persetujuan manual.

    Pada Persetujuan, alur rilis berlanjut dengan tahap kedua, menyebarkan perubahan ke lingkungan stg.

  6. Menjalankan tes integrasi untuk menguji perubahan di lingkungan stg.

  7. 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-adf dan Kerangka Pengujian Nutter. 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

Data Factory

Synapse Analytics

Azure Storage

Ketahanan dan pemulihan bencana

Azure Databricks

Data Factory

Synapse Analytics

Azure Storage

Penelusuran terperinci

Untuk panduan terperinci tentang solusi dan konsep utama, tonton rekaman video berikut: DataDevOps untuk Gudang Data Modern di Microsoft Azure