Retensi data di Fabric Data Warehouse (Pratinjau)

Diterapkan pada:✅ Gudang di Microsoft Fabric

Dalam Microsoft Fabric, gudang secara otomatis mempertahankan dan memelihara berbagai versi data berdasarkan periode retensi yang dikonfigurasi. Periode retensi ini menentukan seberapa jauh ke masa lalu Anda dapat melakukan kueri perjalanan waktu , membuat klon tabel, menggunakan titik pemulihan, dan membuat rekam jepret gudang.

Retensi data dimulai secara otomatis saat Anda membuat gudang. Secara default, gudang menyimpan riwayat data selama 30 hari kalender. Anda dapat mengonfigurasi periode retensi ke nilai apa pun antara 1 dan 120 hari. Sistem secara otomatis menghapus file yang kedaluwarsa setelah periode retensi berakhir.

Gudang data mempertahankan semua sisipan, pembaruan, dan penghapusan dalam periode retensi yang dikonfigurasi.

  • Meningkatkan periode retensi menyediakan jendela yang lebih panjang untuk kueri perjalanan waktu, klon tabel pada titik waktu lalu, titik pemulihan, dan rekam jepret gudang. Namun, periode retensi yang lebih lama meningkatkan konsumsi penyimpanan dan biaya terkait.
  • Mengurangi periode retensi mengurangi biaya penyimpanan tetapi membatasi seberapa jauh Anda dapat mengkueri atau memulihkan data historis.

Cara kerja retensi data

Saat data dimodifikasi, gudang tidak segera membuang status versi sebelumnya. Sebagai gantinya, versi data sebelumnya dipertahankan sebagai bagian dari log transaksi Delta Lake. Mekanisme penerapan versi inilah yang memungkinkan perjalanan waktu, klon tabel, titik pemulihan, dan rekam jepret gudang berfungsi.

Ketika versi data historis melebihi periode retensi yang dikonfigurasi, proses pengumpulan sampah latar belakang secara otomatis menghapus file yang kedaluwarsa dari OneLake. Proses pembersihan ini berjalan secara asinkron dan tidak memengaruhi kueri aktif atau transaksi yang sedang berlangsung.

Gudang mengukur usia data yang disimpan dalam hari kalender absolut sejak versi data dibuat, termasuk kapan saja kapasitas Microsoft Fabric dijeda.

Rentang periode retensi

Jika Anda tidak secara eksplisit mengonfigurasi periode retensi, gudang yang ada menggunakan periode retensi default 30 hari kalender. Anda dapat mengonfigurasi periode retensi data dari 1 hingga 120 hari.

Mengonfigurasi retensi data

Atur periode retensi data untuk gudang dengan menggunakan ALTER DATABASE ... ATUR perintah T-SQL. Untuk langkah-langkah dan informasi selengkapnya, lihat Cara mengonfigurasi retensi data di Fabric Data Warehouse.

Perilaku saat mengubah periode retensi

Memahami perilaku saat Anda mengubah periode retensi membantu Anda merencanakan perubahan untuk menghindari kehilangan data yang tidak terduga atau peningkatan ukuran penyimpanan.

Meningkatkan periode retensi

Saat Anda meningkatkan periode retensi, pengaturan baru akan segera berlaku. Namun, Anda tidak dapat memulihkan data historis yang sudah dibersihkan sistem di bawah periode retensi yang lebih pendek sebelumnya. Hanya versi data yang masih ada di OneLake pada saat perubahan mendapat manfaat dari periode retensi yang diperpanjang.

Misalnya, jika gudang Anda saat ini memiliki periode retensi 7 hari dan Anda meningkatkannya menjadi 60 hari, perubahan berlaku dari titik tersebut ke depan. Versi data yang sudah dibersihkan oleh sistem sebelum perubahan (lebih dari 7 hari) tidak dapat dipulihkan. Namun, semua versi data masih dalam jendela 7 hari pada saat perubahan, bersama dengan versi yang baru dibuat ke depannya, akan dipertahankan hingga 60 hari.

Mengurangi periode retensi

Saat Anda mengurangi periode retensi, versi data yang sekarang berada di luar periode retensi baru yang lebih pendek menjadi memenuhi syarat untuk pembersihan. Proses pembersihan berjalan secara asinkron di latar belakang dan tidak terjadi secara instan. Kueri aktif yang sudah berlangsung tidak akan terpengaruh.

Misalnya, jika gudang Anda memiliki periode retensi 30 hari dan Anda menguranginya menjadi 7 hari, versi data antara 8 dan 30 hari menjadi memenuhi syarat untuk pembersihan latar belakang.

Important

Mengurangi periode retensi tidak dapat diubah, dari perspektif akses data.

Bahkan jika Anda meningkatkan periode retensi lagi tak lama setelahnya, data yang jatuh di luar jendela yang lebih pendek selama waktu tersebut tidak dapat diakses lagi. Sebelum mengurangi periode retensi, pastikan bahwa periode retensi baru memenuhi persyaratan pemulihan dan kepatuhan data organisasi Anda.

Tanggal batas akhir retensi

Kolom time_travel_retention_cutoff_date dalam tampilan katalog sistem sys.databases mencerminkan tanggal paling awal aktual dari mana data perjalanan waktu tersedia, bukan periode retensi yang saat ini dikonfigurasi. Data aktual terlama dapat berbeda dari periode retensi yang dikonfigurasi.

Periode retensi yang dikonfigurasi pengguna menentukan berapa hari riwayat yang harus dipertahankan sistem ke depannya. Namun, riwayat aktual yang dapat dipulihkan tergantung pada data apa yang dipertahankan sebelum perubahan retensi apa pun.

Dua situasi menyebabkan perbedaan antara retensi yang dikonfigurasi dan riwayat aktual yang tersedia:

  • Retensi dikurangi - Gudang segera menandai data historis yang lebih lama dari periode retensi baru untuk pengumpulan sampah dan menghapusnya secara permanen.
  • Masa penyimpanan kemudian ditingkatkan - Gudang data tidak dapat memulihkan riwayat yang telah dihapus. Ini harus menunggu riwayat baru terakumulasi sebelum jendela penuh yang dikonfigurasi tersedia.

Skenario retensi data

Pertimbangkan skenario berikut saat memutuskan cara mengonfigurasi periode retensi Anda:

Kepatuhan dan audit

Organisasi dengan persyaratan peraturan atau kepatuhan mungkin perlu menyimpan data untuk jangka waktu yang lebih lama untuk memenuhi kewajiban audit. Mengonfigurasi periode retensi 90 atau 120 hari dapat memberikan jendela historis yang lebih luas bagi auditor untuk meninjau perubahan data dari waktu ke waktu.

Pengembangan dan pengujian

Untuk ruang kerja pengembangan atau pengujian di mana data historis kurang penting, periode retensi yang lebih pendek 1 hingga 7 hari dapat mengurangi biaya penyimpanan. Pengurangan ini berguna ketika ruang kerja digunakan untuk prototipe cepat atau pengembangan berulang.

Pengoptimalan biaya

Jika gudang Anda sering mengalami modifikasi data skala besar (seperti beban penuh harian), volume data historis yang disimpan dapat tumbuh secara substansial. Dalam skenario ini, mengurangi periode retensi membantu mengontrol biaya penyimpanan sambil tetap mempertahankan jendela pemulihan yang wajar.

Kesiapsiagaan pemulihan data

Untuk gudang produksi, mempertahankan periode retensi yang lebih lama memberikan lebih banyak fleksibilitas untuk pemulihan data melalui titik pemulihan, klon tabel, dan kueri perjalanan waktu jika ada kerusakan data yang tidak disengaja.

Bagaimana retensi yang dapat dikonfigurasi memengaruhi fitur dependen

Periode retensi yang dikonfigurasi berlaku secara seragam di seluruh fitur berikut dalam Fabric Data Warehouse. Mengubah periode retensi secara langsung berdampak pada ketersediaan dan perilaku fitur-fitur ini.

Perjalanan waktu

Perjalanan waktu memungkinkan Anda untuk mengkueri data seperti yang ada pada titik waktu sebelumnya dalam periode retensi. FOR TIMESTAMP AS OF Petunjuk kueri dapat mengambil data dari titik mana pun dalam periode retensi yang dikonfigurasi.

Misalnya, jika periode retensi diatur ke 15 hari, Anda dapat melakukan kueri data seperti yang ada hingga 15 hari kalender di masa lalu.

Duplikasi tabel

Klon tabel bergantung pada periode retensi. Anda dapat membuat klon tabel pada titik waktu lalu hanya dalam periode retensi yang dikonfigurasi. Jika Anda meminta kloning di luar periode retensi, kesalahan terjadi.

Titik pemulihan

Gunakan titik pemulihan untuk memulihkan gudang. Sistem mempertahankan titik pemulihan yang dihasilkan sistem dan yang ditentukan pengguna untuk periode retensi yang dikonfigurasi. Setelah periode retensi kedaluwarsa, sistem secara otomatis menghapus titik pemulihan.

  • Gudang secara otomatis membuat titik pemulihan yang dihasilkan sistem setiap delapan jam. Titik pemulihan ini tersedia untuk periode retensi yang dikonfigurasi.
  • Titik pemulihan yang ditentukan pengguna tersedia untuk periode retensi yang dikonfigurasi. Sistem secara otomatis menghapus titik pemulihan ini setelah kedaluwarsa.

Fabric mempertahankan jumlah minimum titik pemulihan untuk memastikan bahwa titik pemulihan yang memadai selalu tersedia.

Cuplikan gudang

Rekam jepret gudang dapat mereferensikan data dalam periode retensi yang dikonfigurasi. Tanda waktu rekam jepret dapat diatur ke titik mana pun dalam periode retensi yang dikonfigurasi atau ke waktu pembuatan database, mana saja yang nantinya.

Tagihan penyimpanan

Retensi data secara langsung memengaruhi konsumsi penyimpanan OneLake. Setiap versi data yang dipertahankan menempati ruang penyimpanan, dan periode retensi yang lebih lama mengumpulkan versi yang lebih historis.

Saat merencanakan konfigurasi retensi, pertimbangkan trade-off antara manfaat akses riwayat data yang lebih lama dan biaya penyimpanan terkait. Untuk informasi selengkapnya tentang pemantauan penyimpanan, lihat Pelaporan penagihan dan penggunaan di Fabric Data Warehouse.

  • File data yang disimpan: Versi lama dari data yang disimpan sebagai file parquet di OneLake memakan ruang penyimpanan. Biaya penyimpanan sebanding dengan volume dan frekuensi modifikasi data dalam periode retensi.
  • Titik pemulihan: Metadata untuk titik pemulihan yang dihasilkan sistem dan yang ditentukan pengguna juga menggunakan penyimpanan. Namun, titik pemulihan terutama menyimpan metadata dan mereferensikan file data yang ada, sehingga overhead penyimpanannya relatif kecil.
  • Tidak ada biaya komputasi untuk retensi: Tidak ada biaya komputasi yang dikeluarkan hanya untuk menyimpan data historis. Biaya komputasi hanya berlaku saat Anda secara aktif mengkueri atau memulihkan data.

Untuk memperkirakan dampak penyimpanan perubahan periode retensi, pertimbangkan:

  • Volume rata-rata modifikasi data harian di gudang Anda.
  • Periode retensi saat ini dan periode retensi baru yang diusulkan.
  • Delta antara dua periode dikalikan dengan volume modifikasi harian rata-rata memberikan perkiraan perubahan konsumsi penyimpanan.

Pertimbangan Desain

  • Konfigurasikan periode retensi berdasarkan persyaratan pemulihan, kepatuhan, dan biaya data organisasi Anda. Default 30 hari menyediakan keseimbangan antara ketersediaan data dan biaya penyimpanan untuk sebagian besar beban kerja.
  • Koordinasikan perubahan periode retensi dengan strategi pencadangan dan pemulihan bencana Anda. Pastikan bahwa periode retensi selaras dengan tujuan titik pemulihan (RPO) Anda.
  • Pantau konsumsi penyimpanan OneLake setelah mengubah periode retensi untuk memahami dampak pada biaya penyimpanan.
  • Rencanakan perubahan periode retensi selama periode aktivitas rendah jika memungkinkan sehingga tidak ada dampak pengguna.
  • Periode retensi ditetapkan pada tingkat gudang. Jika Anda memerlukan periode retensi yang berbeda untuk himpunan data yang berbeda, pertimbangkan untuk mengaturnya ke dalam gudang terpisah. Pengaturan retensi tingkat tabel individual saat ini tidak didukung.

Keterbatasan

  • Tentukan periode retensi dalam hari penuh. Nilai pecahan tidak didukung.
  • Mengurangi periode retensi tidak langsung mengosongkan penyimpanan. Pembersihan data kedaluwarsa terjadi secara asinkron di latar belakang.
  • Menghentikan sementara kapasitas komputasi Microsoft Fabric memengaruhi aktivitas penanganan sampah. Proses ini tidak menghapus data historis yang lebih lama dari pengaturan retensi data saat ini selama kapasitas dalam keadaan dijeda. Aktivitas pembersihan dilanjutkan setelah kapasitas operasional kembali.
  • Pengaturan retensi hanya berlaku untuk gudang. Titik akhir analitik SQL dari Lakehouse tidak didukung.
  • Wawasan Kueri dan log audit SQL tidak tunduk pada kebijakan retensi data ini dan dikelola secara terpisah.

Retensi item yang dihapus (pratinjau)

Retensi item yang dihapus mempertahankan gudang data beserta tabel, skema, snapshot, izin, dan kueri tersimpan yang terkait selama jangka waktu yang dapat dikonfigurasi setelah di-drop atau dihapus. Ini memastikan bahwa penghapusan yang tidak disengaja tidak mengakibatkan kehilangan data permanen atau pemadaman yang berdampak pada bisnis. Retensi yang dihilangkan menjamin periode retensi minimum 7 hari kalender, dan memiliki konfigurasi retensi tingkat penyewa terpisah. Anda dapat mengonfigurasi periode retensi item yang dihilangkan di pengaturan penyewa Pemulihan Item.

Langkah selanjutnya