Mengembangkan dan menyebarkan dependensi lintas gudang

Dalam artikel ini, Anda mempelajari cara memodelkan dan menyebarkan dependensi lintas gudang menggunakan proyek database SQL di Visual Studio Code. Anda mulai dari dua proyek gudang yang ada dan mengonfigurasi dependensi satu arah di antara mereka menggunakan referensi database dan, jika perlu, pra-penyebaran dan skrip pasca-penyebaran.

Artikel ini dibangun berdasarkan konsep dalam Mengembangkan proyek gudang di Visual Studio Code dan mengasumsikan Anda sudah nyaman membangun dan menerbitkan satu proyek gudang.

Prasyarat

Sebelum memulai, pastikan Anda:

Buat dua Gudang Fabric di ruang kerja yang sama.
- Untuk membuat gudang sampel baru, lihat Membuat sampel Gudang di Microsoft Fabric.
Membuat atau mengekstrak proyek database untuk setiap gudang di Visual Studio Code.
- Untuk membuat proyek database untuk gudang yang sudah ada atau gudang baru, lihat Mengembangkan proyek gudang di Visual Studio Code.
Instal Visual Studio Code di stasiun kerja Anda.
Instal .NET SDK untuk membangun dan menerbitkan proyek database.
Instal dua ekstensi Visual Studio Code: Proyek SQL Database dan SQL Server (mssql).
- Anda dapat menginstal ekstensi yang diperlukan langsung dari dalam marketplace Visual Studio Code dengan mencari "Proyek SQL Database" atau "SQL Server (mssql)".
Proyek gudang memvalidasi, membangun, dan dapat diterbitkan di Visual Studio Code.

Nota

Artikel ini berfokus pada proyek gudang di Visual Studio Code dan bagaimana Anda membuat versinya di Git sebagai proyek kode reguler. Integrasi Fabric Git untuk ruang kerja dan item gudang dicakup secara terpisah dalam kontrol Sumber dengan Fabric Data Warehouse dan dokumen integrasi Git. Artikel ini mengasumsikan bahwa ruang kerja Fabric Anda adalah target penyebaran dan skema T-SQL berada di satu atau beberapa proyek Visual Studio Code yang Anda kontrol versinya di Git.

Artikel ini tidak membahas pengembangan lintas gudang untuk titik akhir analitik SQL dari Lakehouse. Tabel Lakehouse dan objek SQL endpoint bukanlah objek yang dilacak dalam kontrol sumber dengan metode yang sama seperti proyek gudang. Gunakan item Gudang dengan proyek database untuk integrasi git lengkap dan dukungan penyebaran dalam pengalaman asli Fabric dan alat klien.

Skenario: Gudang lintas domain Zava Analytics

Zava Analytics menggunakan dua domain bisnis:

Penjualan – pesanan pelanggan, pendapatan, dan metrik alur.
Pemasaran – kampanye, saluran, dan metrik keterlibatan.

Setiap domain memiliki:

Gudang Fabric di ruang kerja yang sama:
- ZavaSalesWarehouse
- ZavaMarketingWarehouse
Proyek database di Visual Studio Code:
- Zava.Sales.Warehouse
- Zava.Marketing.Warehouse

Untuk membangun proses ELT dan pelaporan menyeluruh, setiap domain memerlukan tampilan read-only untuk mengakses data dari domain lain:

Sales membutuhkan keterlibatan pemasaran oleh pelanggan.
Marketing membutuhkan performa penjualan per kampanye.

Anda perlu:

Menetapkan dependensi lintas gudang satu arah melalui referensi database.
Hindari dependensi siklik.
Gunakan skrip pra-dan pasca-penyebaran untuk kasus di mana objek di kedua gudang bergantung satu sama lain.

Pastikan dependensi antar gudang adalah satu arah

Untuk setiap pasangan gudang, pilih arah untuk dependensi logis:

Contoh:

Sales tergantung pada Marketing data keterlibatan.
Marketing tidak bergantung pada Sales objek apa pun yang diperlukan pada waktu penyebaran.

Dalam praktiknya:

Zava.Sales.Warehouse memiliki referensi database ke Zava.Marketing.Warehouse.

T-SQL di Sales gudang dapat menggunakan nama tiga bagian seperti:

SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement

Zava.Marketing.Warehouse tidak merujuk pada Sales objek yang akan memaksa siklus dependensi saat implementasi.

Tip

Untuk setiap sepasang gudang, gambar diagram panah sederhana (Sales → Marketing). Jika Anda menemukan panah yang menunjuk ke kedua arah untuk jenis objek yang sama, Anda mungkin perlu merefaktor atau memindahkan beberapa logika ke dalam skrip pra-dan pasca-penyebaran.

Hindari dependensi siklik

Dependensi siklik terjadi ketika Warehouse A dan Warehouse B bergantung satu sama lain dengan cara yang tidak dapat diselesaikan oleh sistem dalam penyebaran tunggal.

Contoh masalah (jangan lakukan ini):

ZavaSalesWarehouse.dbo.CustomerRollup tampilan:

CREATE VIEW dbo.CustomerRollup AS
SELECT  c.CustomerId,
        c.TotalRevenue,
        m.LastCampaignId
FROM    dbo.CustomerRevenue AS c
LEFT OUTER JOIN   
        ZavaMarketingWarehouse.dbo.CustomerEngagement AS m
        ON c.CustomerId = m.CustomerId;

ZavaMarketingWarehouse.dbo.CampaignAttribution tampilan:

CREATE VIEW dbo.CampaignAttribution AS
SELECT  m.CampaignId,
        SUM(s.TotalRevenue) AS RevenueAttributed
FROM    dbo.Campaigns AS m
LEFT OUTER JOIN    
        ZavaSalesWarehouse.dbo.CustomerRollup AS s
        ON m.CampaignId = s.LastCampaignId
GROUP BY m.CampaignId;

Dalam pola anti ini:

CustomerRollup penjualan tergantung pada CustomerEngagementpemasaran.
CampaignAttribution dalam Pemasaran tergantung pada CustomerRolluppenjualan.

Anti-pola ini membuat sebuah siklus: Tampilan Penjualan → Tampilan Pemasaran → Tampilan Penjualan lagi.

Panduan:

Jangan memodelkan dependensi timbal balik antara gudang sebagai objek tingkat skema biasa. Jika Anda benar-benar membutuhkan logika semacam ini, pindahkan satu sisi dependensi ke:

Skrip pasca-penyebaran, atau
Model semantik hilir atau laporan yang bergabung dengan dua gudang selama proses kueri berlangsung.

Menggunakan skrip pra-pasca penyebaran untuk logika lintas gudang yang sensitif terhadap penyebaran.

Karena penyebaran gudang merupakan operasi pembandingan skema lengkap (bukan penyebaran parsial per objek), perlakukan item lintas gudang dengan hati-hati:

Jika Gudang A dan Gudang B keduanya membutuhkan objek yang bergantung satu sama lain:

Pertahankan tabel inti dan tampilan inti di setiap proyek gudang.
Pindahkan tampilan jembatan atau objek utilitas yang membuat siklus ke dalam skrip pra-atau pasca-penyebaran dalam satu proyek.
Pastikan skrip tersebut idempoten dan aman untuk dieksekusi ulang.

Contoh pola:

Skrip pra-penyebaran: hapus sementara tampilan lintas gudang sebelum menerapkan perubahan skema yang dapat merusaknya.
Skrip pasca-penyebaran: buat ulang atau perbarui tampilan lintas gudang setelah kedua gudang disebarkan.

Pola 1: Referensi lintas gudang langsung melalui referensi database

Dalam pola ini, Anda memodelkan dependensi satu arah langsung dalam proyek database menggunakan Referensi Database.

Langkah 1: Mulai dari dua proyek gudang yang ada

Anda harus sudah memiliki:

Zava.Sales.Warehouse → disebarkan ke ZavaSalesWarehouse
Zava.Marketing.Warehouse → disebarkan ke ZavaMarketingWarehouse

Setiap proyek dibuat atau diekstrak menggunakan langkah-langkah dalam Mengembangkan proyek gudang di Visual Studio Code.

Langkah 2: Menambahkan referensi database dari Penjualan ke Pemasaran

Di Visual Studio Code, buka tampilan Proyek Database .
Klik kanan pada proyek Zava.Sales.Warehouse.
Pilih Tambahkan Referensi Database....
Pilih salah satu dari:
- Proyek database di ruang kerja saat ini (Proyek database yang dirujuk dengan cara ini juga harus terbuka di Visual Studio Code), atau
- Aplikasi tingkat data (.dacpac) (Asumsikan telah Anda buat jika Anda memiliki bawaan .dacpacMarketing untuk gudang).
Atur opsi referensi:
- Jenis referensi: Server yang sama, database yang berbeda.
- Nama atau variabel database: Gunakan variabel SQLCMD, misalnya [$(MarketingWarehouseName)].
Simpan dan kompilasi ulang proyek Penjualan.

Di dalam file .sqlproj, Anda seharusnya melihat entri yang mirip dengan:

<ItemGroup>
  <ArtifactReference Include="..\Zava.Marketing.Warehouse\bin\Debug\Zava.Marketing.Warehouse.dacpac">
    <DatabaseVariableLiteralValue>$(MarketingWarehouseName)</DatabaseVariableLiteralValue>
  </ArtifactReference>
</ItemGroup>
<ItemGroup>
  <SqlCmdVariable Include="MarketingWarehouseName">
    <DefaultValue>ZavaMarketingWarehouse</DefaultValue>
  </SqlCmdVariable>
</ItemGroup>

Tip

Menggunakan variabel SQLCMD untuk nama gudang jarak jauh memungkinkan Anda menggunakan kembali proyek yang sama di semua lingkungan Anda, seperti Dev/Test/Prod, di mana nama gudang mungkin berbeda.

Langkah 3: Membuat tampilan lintas gudang di Penjualan

Dalam proyek Sales, tambahkan tampilan yang membaca dari gudang Marketing.

-- schema/Views/dbo.CustomerEngagementFact.sql
CREATE VIEW [dbo].[CustomerEngagementFact] AS
SELECT
    s.CustomerId,
    s.TotalRevenue,
    m.LatestChannel,
    m.LastEngagementDate
FROM dbo.CustomerRevenue AS s
JOIN [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] AS m
    ON s.CustomerId = m.CustomerId;

Poin utama:

Nama [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] tiga bagian cocok dengan pola T-SQL yang digunakan untuk kueri lintas gudang di editor Fabric SQL.
DacFx menentukan database eksternal melalui referensi database.

Bangun proyek untuk memastikan tidak ada SQL71501 kesalahan referensi yang tidak terselesaikan .

Langkah 4: Publikasikan gudang Pemasaran, lalu Penjualan

Untuk menghindari masalah penyebaran:

Membangun dan menerbitkanZava.Marketing.Warehouse pertama:
- Klik kanan proyek → Build.
- Klik kanan proyek → Terbitkan → pilih ZavaMarketingWarehouse.
Setelah Marketing penyebaran berhasil, bangun dan terbitkanZava.Sales.Warehouse:
- Klik kanan proyek → Build.
- Klik kanan proyek → Terbitkan → pilih ZavaSalesWarehouse.

Alur penyebaran yang dihasilkan adalah:

Zava.Marketing.Warehouse (tidak ada dependensi eksternal) → Zava.Sales.Warehouse (tergantung pada Marketing)

Sekarang, kueri T-SQL apa pun di ZavaSalesWarehouse dapat menggunakan tampilan dbo.CustomerEngagementFact, yang secara internal membaca dari gudang Marketing menggunakan T-SQL lintas gudang.

Pola 2: Dependensi lintas gudang yang dikelola melalui skrip pra dan pasca penyebaran

Dalam beberapa skenario Zava Analytics, kedua domain mungkin memerlukan objek agregat yang bergantung satu sama lain. Contohnya:

Sales menginginkan tampilan yang menggunakan data kampanye pemasaran untuk menyediakan informasi pendapatan penjualan per kampanye pemasaran.
Pemasaran menginginkan tampilan yang menggunakan data pendapatan penjualan untuk memberikan efisiensi kampanye pemasaran.

Anda tidak ingin kedua objek ini menjadi tampilan biasa yang terlibat dalam penyebaran model secara penuh, karena itu berisiko dependensi siklik atau urutan penyebaran yang rentan.

Sebagai gantinya, Anda:

Menjaga model inti setiap gudang tetap independen.
Gunakan skrip pasca-penyebaran dalam satu proyek untuk membuat lebih banyak tampilan lintas gudang setelah kedua skema diberlakukan.

Langkah 1: Menambahkan referensi database untuk validasi waktu kompilasi

Siapkan referensi yang mirip dengan Pola 1, tetapi untuk kedua proyek:

Di Zava.Sales.Warehouse, tambahkan referensi ke Pemasaran melalui [$(MarketingWarehouseName)].
Dalam Zava.Marketing.Warehouse, secara opsional tambahkan referensi ke Penjualan melalui [$(SalesWarehouseName)] jika Anda ingin validasi saat kompilasi untuk pandangan lintas gudang yang digunakan dalam skrip.

Di dalam file .sqlproj, Anda mungkin mengatur:

<SqlCmdVariable Include="SalesWarehouseName">
  <DefaultValue>ZavaSalesWarehouse</DefaultValue>
</SqlCmdVariable>

Langkah 2: Membuat objek inti sebagai objek proyek reguler

Contoh:

Sales proyek:
- dbo.CustomerRevenue meja
- dbo.SalesByCampaign tampilan (hanya menggunakan tabel lokal)
Marketing proyek:
- dbo.Campaigns meja
- dbo.CampaignStats tampilan (hanya menggunakan tabel lokal)

Objek ini tidak menggunakan kueri lintas gudang. Pada langkah berikutnya, kita akan memperkenalkan referensi lintas gudang.

Langkah 3: Menambahkan skrip pasca-penyebaran untuk tampilan jembatan antar gudang

Pilih satu gudang untuk menghosting objek jembatan; biasanya domain yang paling banyak mengonsumsi output gabungan. Misalkan Sales adalah domain itu.

Sales Dalam proyek: Klik kanan proyek, lalu Tambahkan → Skrip Pasca-Penyebaran.
Beri nama skrip PostDeployment_CrossWarehouse.sql.
Dalam skrip, buat atau ubah tampilan lintas gudang menggunakan pola IF EXISTS / DROP / CREATE untuk menjaganya tetap idempoten.

Contoh skrip dalam Sales yang akan mereferensikan Marketing objek gudang:

-- PostDeployment_CrossWarehouse.sql

-- Ensure object can be recreated safely
IF OBJECT_ID('dbo.CampaignRevenueBridge', 'V') IS NOT NULL
    DROP VIEW [dbo].[CampaignRevenueBridge];
GO

CREATE VIEW [dbo].[CampaignRevenueBridge] AS
SELECT
    c.CampaignId,
    c.CampaignName,
    m.Channel,
    SUM(s.TotalRevenue) AS Revenue
FROM [$(MarketingWarehouseName)].[dbo].[Campaigns] AS c
JOIN [$(MarketingWarehouseName)].[dbo].[CampaignEngagement] AS m
    ON c.CampaignId = m.CampaignId
JOIN dbo.SalesByCampaign AS s
    ON s.CampaignId = c.CampaignId
GROUP BY
    c.CampaignId,
    c.CampaignName,
    m.Channel;
GO

Sini:

Proyek inti Sales dan Marketing gudang tetap independen dan dapat disebarkan sendiri.
Tampilan jembatan dibuat setelah penyebaran skema melalui skrip pasca-penyebaran.
Jika penerapan dijalankan beberapa kali, itu idempoten, karena skrip dengan aman menghapus dan membuat ulang tampilan.

Langkah 4: (Opsional) Gunakan skrip pre-deployment untuk melindungi dependensi rentan

Dalam skenario yang lebih canggih, Anda mungkin:

Gunakan skrip pra-penyebaran untuk menghilangkan atau menonaktifkan tampilan lintas gudang yang dapat memblokir perubahan skema (misalnya, jika Anda mengganti nama kolom).
Biarkan DacFx menerapkan perbedaan skema.
Gunakan skrip pasca-penyebaran untuk membuat ulang atau memperbarui tampilan lintas gudang.

Penting

Skrip pra-dan pasca-penyebaran berjalan sebagai bagian dari rencana penyebaran dan harus:

Idempoten, artinya mereka aman untuk dijalankan beberapa kali.
Kompatibel dengan skema akhir yang diproduksi oleh DacFx.
Bebas dari perubahan destruktif yang bertentangan dengan kebijakan Anda BlockOnPossibleDataLoss .

Langkah 5: Terbitkan pesanan untuk dependensi yang dikelola skrip

Pola umum untuk Zava Analytics:

Menerbitkan proyek dasar:
- Zava.Marketing.Warehouse (Skema inti)
- Zava.Sales.Warehouse (skema inti + skrip pasca-penyebaran gudang silang)
Biarkan skrip Pasca-penyebaran Penjualan membuat tampilan jembatan setelah skemanya sendiri dan skema yang direferensikan Marketing disebarkan.

Jika Anda memperkenalkan lebih dari dua gudang, ulangi pola ini secara berlapis. Jangan pernah membuat dependensi siklik melalui objek proyek biasa.

Lanjutkan pembelajaran

Gabungkan pola-pola ini dengan kontrol sumber dan panduan CI/CD dalam Kontrol sumber dengan Fabric Data Warehouse dan dokumen integrasi git Fabric.
Perluas skenario Zava Analytics untuk menyertakan lingkungan Dev/Test/Prod , menggunakan alur penyebaran atau CI/CD eksternal untuk mengatur urutan penerbitan di beberapa gudang.

Alur kerja pengembangan dan penyebaran

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-12-09