Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Batasan saat ini dalam database cermin Microsoft Fabric dari Snowflake tercantum di halaman ini. Halaman ini dapat berubah.
Batasan koneksi dan autentikasi
- Tabel berikut mencantumkan metode autentikasi mana yang didukung untuk pencerminan untuk Snowflake:
| Metode autentikasi | Dukungan | Catatan |
|---|---|---|
| Nama pengguna dan kata sandi | Yes | Autentikasi bawaan Snowflake |
| Microsoft Entra ID (SSO) | Yes | Masuk sekali melalui Entra ID |
| Autentikasi pasangan kunci | Yes | Pasangan kunci RSA untuk skenario akun layanan |
| Identitas ruang kerja | Tidak. | Saat ini tidak didukung untuk Snowflake |
Identitas ruang kerja saat ini tidak didukung untuk pencerminan Snowflake. Ini tersedia untuk sumber tertentu seperti SharePoint.
Konektivitas Private Link antara ruang kerja Fabric dan Snowflake belum tersedia. Gunakan gateway data jaringan virtual atau gateway data lokal untuk konektivitas privat untuk sementara.
Anda harus menambahkan penerima berbagi ke ruang kerja. Untuk berbagi himpunan data atau laporan, pertama-tama tambahkan access ke ruang kerja dengan peran admin, anggota, pembaca, atau kontributor.
Peka huruf besar/kecil: Semua pengidentifikasi Snowflake—termasuk nama warehouse, nama database, nama skema, nama tabel, dan nama tampilan—membedakan huruf besar/kecil saat mengonfigurasi koneksi pencerminan dan saat menggunakan API REST pencerminan. Casing yang Anda masukkan di Fabric harus sama persis dengan apa yang dikonfigurasi di Snowflake. Casing yang tidak cocok dapat menyebabkan kegagalan koneksi atau tabel tidak muncul untuk replikasi, seringkali tanpa pesan kesalahan deskriptif. Misalnya, jika gudang Snowflake Anda diberi nama ANALYTICS_WH, Anda harus memasukkan ANALYTICS_WH dalam koneksi Fabric, bukan analytics_wh.
Jenis objek yang didukung
- Tabel berikut ini mencantumkan jenis objek Snowflake mana yang didukung untuk pencerminan:
| Jenis objek | Dukungan | Catatan |
|---|---|---|
| Tabel yang dikelola | Yes | Didukung penuh untuk replikasi |
| Tabel Iceberg | Yes | Memerlukan koneksi penyimpanan ke penyimpanan tabel Iceberg yang mendasar. Hanya tabel Iceberg yang dapat diakses melalui koneksi penyimpanan yang sama yang dapat dicerminkan secara bersamaan. |
| Views | Yes | Didukung dengan sinkronisasi setiap 12 jam |
| Tampilan Materialisasi | Yes | Didukung dengan sinkronisasi setiap 12 jam |
| Tabel eksternal | Tidak. | Tidak didukung |
| Tabel sementara | Tidak. | Tidak didukung |
| Tabel sementara | Tidak. | Tidak didukung |
| Tabel dinamis | Tidak. | Tidak didukung |
Replikasi dan batasan data
- Jika tidak ada pembaruan dalam tabel sumber, mesin replikator mulai mundur dengan durasi yang meningkat secara eksponensial untuk tabel tersebut, hingga satu jam. Hal yang sama dapat terjadi jika ada kesalahan sementara, mencegah refresh data. Mesin replikator akan secara otomatis melanjutkan polling reguler setelah data yang diperbarui terdeteksi.
- Hierarki skema sumber direplikasi ke database cermin. Untuk database cermin yang dibuat sebelum fitur ini diaktifkan, skema sumber diratakan, dan nama skema dikodekan ke dalam nama tabel. Jika Anda ingin mengatur ulang tabel dengan skema, buat ulang database cermin Anda. Pelajari selengkapnya dari Replikasi hierarki skema sumber.
- Pencerminan mendukung replikasi kolom yang berisi spasi atau karakter khusus dalam nama (seperti
,;{}()\n\t=). Untuk tabel di bawah replikasi sebelum fitur ini diaktifkan, Anda perlu memperbarui pengaturan database yang dicerminkan atau memulai ulang pencerminan untuk menyertakan kolom tersebut. Dapatkan informasi lebih lanjut tentang dukungan pemetaan kolom Delta . - Jumlah maksimum tabel yang dapat dicerminkan ke dalam Fabric adalah 1.000 tabel. Tabel apa pun di atas batas 1000 saat ini tidak dapat direplikasi.
- Jika Anda memilih Cerminkan semua data saat mengonfigurasi Pencerminan, tabel yang akan dicerminkan akan ditentukan dengan mengambil 1.000 tabel pertama saat semua tabel diurutkan menurut abjad berdasarkan nama skema lalu nama tabel. Kumpulan tabel yang tersisa di bagian bawah daftar alfabet tidak akan disinkronkan.
- Jika Anda membatalkan pilihan Mencerminkan semua data dan memilih tabel individual, Anda dicegah memilih lebih dari 1.000 tabel.
- Kolom terhitung dan tabel terhitung: Database cermin bersifat baca-saja. Anda tidak dapat membuat kolom terhitung atau tabel terhitung langsung pada database cermin. Untuk menambahkan kolom terhitung, buat Lakehouse dan gunakan pintasan untuk merujuk ke data hasil pencerminan, lalu buat kolom terhitung di Lakehouse menggunakan notebook atau SQL.
Keterbatasan kinerja
- Jika Anda mengubah sebagian besar data dalam tabel besar, lebih efisien untuk menghentikan dan memulai ulang Mirroring. Menyisipkan atau memperbarui miliaran rekaman bisa memakan waktu lama.
- Beberapa perubahan skema tidak segera tercermin. Beberapa perubahan skema memerlukan perubahan data (sisipkan, perbarui, atau hapus) sebelum perubahan skema direplikasi ke Fabric.
- Pertimbangan lintas wilayah: Jika instans Snowflake dan kapasitas Fabric Anda berada di wilayah cloud yang berbeda, Anda mungkin mengalami latensi replikasi dan biaya keluar data yang lebih tinggi. Untuk performa optimal dan untuk menghindari biaya keluar lintas wilayah, sebarkan kapasitas Fabric Anda di wilayah cloud yang sama dengan instans Snowflake Anda. Jika deployment lintas wilayah tidak dapat dihindari, perhitungkan biaya egress tambahan dari Snowflake dan/atau Azure. Lihat dokumentasi egress Snowflake untuk selengkapnya.
- Saat mereplikasi data dari Snowflake ke OneLake milik pelanggan, proses ini biasanya menyimpan sementara data melalui URL inline untuk meningkatkan kinerja. Jika parameter tingkat akun Snowflake PREVENT_UNLOAD_TO_INLINE_URL diatur ke true, perilaku berikut berlaku:
| Metode konektivitas | Dampak saat PREVENT_UNLOAD_TO_INLINE_URL = true |
|---|---|
| Langsung (titik akhir publik) | Pencerminan beralih ke pembacaan langsung dari Snowflake. Fallback ini menghasilkan waktu replikasi yang lebih lambat dan peningkatan risiko batas waktu koneksi, terutama untuk himpunan data besar. |
| gateway data Jaringan Virtual (VNet) | Pencerminan diblokir sepenuhnya. Skenario gateway VNet tidak dapat menggunakan pembacaan langsung dan harus menggunakan jalur penahapan URL inline. |
| Gateway data di lokasi (OPDG) | Pencerminan sepenuhnya diblokir. Skenario OPDG tidak dapat menggunakan pembacaan langsung dan mengharuskan jalur staging URL inline. |
Solusi yang direncanakan: Dukungan integrasi penyimpanan sedang dikembangkan dan akan menyediakan jalur staging alternatif yang berfungsi saat PREVENT_UNLOAD_TO_INLINE_URL diatur ke true. Solusi ini mengatasi hambatan pada skenario VNet dan OPDG. Periksa halaman ini untuk mengetahui pembaruan ketersediaan.
-
Perilaku penyemaian ulang: Penyemaian ulang adalah pemuatan ulang data secara penuh untuk seluruh tabel. Tidak seperti sinkronisasi bertambah bertahap (yang hanya memproses baris yang diubah), reseed membaca ulang dan menulis ulang semua data dalam tabel. Reseed dapat menimbulkan biaya komputasi Snowflake yang besar, terutama untuk tabel berukuran besar.
- Apa yang memicu reseed:
| Trigger | Deskripsi |
|---|---|
| Perubahan DDL | Setiap perubahan pada DDL yang mengubah stempel waktu DDL suatu tabel akan memicu reseed. Pemicu ini mencakup pernyataan ALTER TABLE yang menambahkan, menghilangkan, atau mengganti nama kolom, mengubah jenis data, atau mengubah properti tabel. |
| Alat modifikasi skema (misalnya, DBT) | Jika alat seperti DBT memodifikasi definisi tabel pada jadwal berulang (misalnya, melalui dbt run yang menghilangkan dan membuat ulang tabel), setiap modifikasi memicu reseed. Menjalankan alat ini terlalu sering (misalnya, setiap beberapa menit) dapat menyebabkan siklus penyemaian ulang yang terus-menerus. |
| Menghentikan dan memulai ulang pencerminan | Setiap kali Anda berhenti dan memulai ulang pencerminan, seluruh tabel diambil lagi dari awal. |
| Jeda kapasitas yang diperpanjang | Jika kapasitas Fabric dijeda dalam jangka waktu lama, pencerminan mungkin dimulai ulang dari awal saat dilanjutkan. Lihat Perubahan pada kapasitas Fabric. |
- Praktik terbaik untuk menghindari penyemaian ulang yang tidak perlu:
- Jadwalkan perubahan skema di luar pencerminan aktif. Jika Anda menggunakan DBT atau alat pengelolaan skema lainnya, jadwalkan perubahan skema pada periode pemeliharaan atau hentikan sementara pencerminan sebelum menjalankan perubahan skema tersebut.
- Hindari perubahan DDL yang terlalu sering. Konsolidasikan perubahan skema menjadi batch yang lebih sedikit dan lebih besar daripada membuat perubahan bertambah bertahap sepanjang hari.
- Pantau penyemaian ulang yang tidak terduga. Pada halaman Status Pencerminan, perhatikan tabel yang berulang kali menampilkan perilaku penyalinan awal. Jika tabel besar diinisialisasi ulang setiap beberapa menit, periksa perubahan DDL pada sistem hulu.
- Waspadai dampak biaya. Pengisian ulang nilai seed pada tabel dengan 226 juta baris (~26,5 GB) memerlukan waktu komputasi yang signifikan. Kalikan biaya ini dengan frekuensi perubahan skema untuk memperkirakan dampak biaya.
Batasan keamanan
- Fabric tidak mereplikasi kebijakan Snowflake Row-Level Security (RLS) dan Column-Level Security (CLS). Anda harus mengonfigurasi ulang kebijakan keamanan yang setara secara manual dalam Fabric.
- Penerima berbagi harus ditambahkan ke ruang kerja. Untuk berbagi himpunan data atau laporan, pertama-tama tambahkan access ke ruang kerja dengan peran admin, anggota, pembaca, atau kontributor.
Pertimbangan biaya dan penagihan
Untuk meminimalkan biaya komputasi Snowflake dari pencerminan, pertimbangkan praktik terbaik berikut:
- Gunakan kembali gudang yang ada. Alih-alih membuat gudang khusus untuk pencerminan, konfigurasikan pencerminan untuk menggunakan gudang yang sama dengan yang sudah digunakan aplikasi Anda untuk memperbarui tabel sumber. Pendekatan ini menghindari siklus bangun gudang dan auto-suspend yang tidak perlu. Ketika aplikasi Anda memperbarui tabel, replikator pencerminan mendeteksi perubahan hampir seketika ketika gudang data masih aktif, sehingga tidak perlu mengaktifkan gudang data terpisah. Beberapa organisasi mungkin lebih suka gudang khusus untuk isolasi anggaran. Pilihan ini adalah trade-off antara penghematan biaya dan granularitas anggaran.
- Cerminkan hanya tabel yang Anda butuhkan. Mereplikasi seluruh basis data dapat menyebabkan penggunaan Snowflake yang sangat tinggi secara tidak terduga dan lonjakan penggunaan kapasitas Fabric. Mulailah dengan memilih hanya tabel yang diperlukan untuk skenario analitik Anda. Anda dapat menambahkan tabel nanti sesuai kebutuhan.
- Pantau penyemaian ulang yang tidak terduga. Reseed (reload data penuh) memproses seluruh tabel dan menimbulkan biaya komputasi sebanding dengan ukuran tabel. Perubahan skema - termasuk yang dipicu oleh alat seperti DBT - dapat menyebabkan penyemaian ulang secara terus-menerus. Pantau halaman Status Pencerminan untuk tabel yang memperlihatkan perilaku penyalinan awal berulang, dan tinjau bagian Reseeding untuk panduan pemicu dan pemecahan masalah.
- Perlu diketahui bahwa pencerminan berjalan terus-menerus. Pencerminan saat ini tidak mendukung penjadwalan atau jendela replikasi. Replikator terus memeriksa perubahan secara berkala, yang mengakibatkan penggunaan komputasi Snowflake secara berkelanjutan. Rencanakan anggaran Snowflake Anda dengan tepat.
Wilayah yang didukung
Pencerminan database dan pencerminan terbuka tersedia di semua wilayah Microsoft Fabric. Untuk informasi selengkapnya, lihat Ketersediaan wilayah Fabric.