Bagikan melalui

Kebijakan pemartisian

Berlaku untuk: ✅Microsoft Fabric✅Azure Data Explorer

Kebijakan pemartisian adalah ketentuan dan cara melakukan pemartisian pada jangkauan (data shard) untuk tabel tertentu atau tampilan materialisasi.

Kebijakan ini memicu proses latar belakang tambahan yang terjadi setelah pembuatan jangkauan, mengikuti penyerapan data. Proses ini mencakup penyerapan ulang data dari tingkat sumber dan menghasilkan tingkat homogen , di mana semua nilai kolom yang ditetapkan sebagai kunci partisi berada dalam satu partisi.

Tujuan utama kebijakan pemartisian adalah untuk meningkatkan performa kueri dalam skenario tertentu yang didukung.

Catatan

Secara default, ketika kebijakan pemartisian data tidak ditentukan (adalah null), tingkatan dipartisi berdasarkan waktu pembuatan (penyerapan). Dalam kebanyakan kasus, anda tidak perlu mengatur kebijakan pemartisian data.

Skenario yang didukung

Berikut ini adalah satu-satunya skenario di mana pengaturan kebijakan partisi data direkomendasikan. Dalam semua skenario lain, menetapkan kebijakan tidak disarankan.

  • guid sedang atau tinggi:
    • Misalnya: solusi multipenyewa, atau tabel metrik di mana sebagian besar atau semua kueri memfilter pada kolom jenis string atau guid, seperti TenantId atau MetricId.
    • Kardinalitas sedang setidaknya 10.000 nilai yang berbeda.
    • Atur uniform
  • Agregasi atau gabungan yang sering pada kardinalitas string atau guid kolom tinggi:
    • Misalnya, informasi IoT dari berbagai sensor, atau catatan akademik dari banyak siswa yang berbeda.
    • Kardinalitas tinggi setidaknya 1.000.000 nilai yang berbeda, di mana distribusi nilai dalam kolom kira-kira merata.
    • Dalam hal ini, atur kunci partisi hash menjadi kolom yang sering dikelompokkan atau digabungkan, dan atur PartitionAssignmentMode properti ke ByPartition.
  • Penyerapan data yang tidak berurutan:
    • Data yang tertelan ke dalam tabel mungkin tidak dipesan dan dipartisi menjadi luas (pecahan) sesuai dengan kolom tertentu datetime yang mewakili waktu pembuatan data dan biasanya digunakan untuk memfilter data. Ini bisa disebabkan oleh pengisian ulang dari file sumber heterogen yang menyertakan nilai tanggalwaktu selama rentang waktu yang besar.
    • Dalam hal ini, atur kunci partisi tanggalwaktu rentang seragam menjadi kolom datetime.
    • Jika Anda memerlukan kebijakan retensi dan penembolokan agar selaras dengan nilai tanggalwaktu di kolom, alih-alih menyelaraskan dengan waktu penyerapan, atur OverrideCreationTime properti ke true.

Perhatian

  • Tidak ada batasan kode keras yang ditetapkan pada jumlah tabel dengan kebijakan partisi yang ditentukan. Tapi, setiap tabel tambahan menambahkan overhead ke proses pemartisian data latar belakang. Menetapkan kebijakan pada lebih banyak tabel akan mengakibatkan lebih banyak sumber daya digunakan, dan biaya yang lebih tinggi karena transaksi penyimpanan yang mendasar. Untuk informasi selengkapnya, lihat kapasitas.
  • Tidak disarankan untuk menetapkan kebijakan partisi jika ukuran data terkompresi per partisi diperkirakan kurang dari 1GB.
  • Proses partisi menghasilkan artefak penyimpanan residu untuk semua tingkatan yang diganti selama proses partisi dan selama proses penggabungan. Sebagian besar artefak penyimpanan residu diharapkan dihapus selama proses pembersihan otomatis. Meningkatkan nilai MaxPartitionCount properti meningkatkan jumlah artefak penyimpanan residu dan dapat mengurangi performa pembersihan.
  • Sebelum menerapkan kebijakan partisi pada tampilan materialisasi, tinjau rekomendasi untuk kebijakan partisi pandangan material.

Kunci partisi

Jenis kunci partisi berikut didukung.

Kind Jenis Kolom Properti partisi Nilai partisi
Hash string atau guid Function, , MaxPartitionCountSeed,PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Rentang seragam datetime RangeSize, , ReferenceOverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Kunci partisi hash

Jika kebijakan menyertakan kunci partisi hash, semua tingkat homogen yang termasuk dalam partisi yang sama akan ditetapkan ke simpul data yang sama.

Catatan

Operasi partisi data menambahkan beban pemrosesan yang signifikan. Sebaiknya terapkan kunci partisi hash pada tabel hanya dalam kondisi berikut:

  • Jika sebagian besar kueri menggunakan filter kesetaraan (==, in()).
  • Sebagian besar kueri agregat/gabungan pada kolom jenis tertentu atau string yang berdimensiguidbesar (kardinalitas 10M atau lebih tinggi), seperti , atau device_ID.user_ID
  • Pola penggunaan tabel yang dipartisi berada dalam beban kueri konkurensi tinggi, seperti dalam aplikasi pemantauan atau dasbor.
  • Fungsi hash-modulo digunakan untuk mempartisi data.
  • Data dalam tingkat homogen (dipartisi) dipesan oleh kunci partisi hash.
    • Anda tidak perlu menyertakan kunci partisi hash dalam kebijakan urutan baris, jika salah satu ditentukan pada tabel.
  • Kueri yang menggunakan strategi acak, dan di mana yang digunakan dalam shuffle key, join atau summarize merupakan kunci partisi hash tabel, diharapkan berkinerja lebih baik karena jumlah data yang make-series diperlukan untuk berpindah di seluruh simpul berkurang.

Properti partisi

Properti Deskripsi Nilai yang didukung Nilai yang direkomendasikan
Function Nama fungsi hash-modulo untuk digunakan. XxHash64
MaxPartitionCount Jumlah maksimum partisi untuk dibuat (argumen modulo ke fungsi hash-modulo) per periode waktu. Dalam jangkauan (1,2048]. Nilai yang lebih tinggi menyebabkan overhead yang lebih besar dari proses pemartisian data, dan jumlah tingkat yang lebih tinggi untuk setiap periode waktu. Nilai yang disarankan adalah 128. Nilai yang lebih tinggi akan secara signifikan meningkatkan overhead pemartisian data pasca-penyerapan, dan ukuran metadata - dan karenanya tidak disarankan.
Seed Gunakan untuk mengacak nilai hash. Bilangan bulat positif. 1, yang juga merupakan nilai default.
PartitionAssignmentMode Mode yang digunakan untuk menetapkan partisi ke simpul. ByPartition: Semua tingkat homogen (dipartisi) yang termasuk dalam partisi yang sama ditugaskan ke node yang sama.
Uniform: Nilai partisi jangkauan diabaikan. Ekstensi ditetapkan secara seragam ke simpul.		 Jika kueri tidak bergabung atau menggabungkan pada kunci partisi hash, gunakan Uniform. Jika tidak, gunakan ByPartition.

Contoh kunci partisi hash

Kunci partisi hash di atas kolom jenis string bernama tenant_id. Kunci ini menggunakan fungsi hash XxHash64, dengan MaxPartitionCount diatur ke nilai 128yang disarankan, dan default Seed dari 1.

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Kunci partisi tanggalwaktu rentang seragam

Catatan

Hanya menerapkan kunci partisi tanggalwaktu rentang seragam pada kolom jenis datetime dalam tabel ketika data yang tertelan ke dalam tabel tidak mungkin dipesan sesuai dengan kolom ini.

Dalam kasus ini, Anda dapat merombak data antar tingkat sehingga setiap tingkat mencakup catatan dari rentang waktu terbatas. Proses ini menghasilkan filter pada kolom datetime menjadi lebih efektif pada waktu kueri.

Fungsi partisi yang digunakan adalah bin_at() dan tidak dapat disesuaikan.

Properti partisi

Properti Deskripsi Nilai yang direkomendasikan
RangeSize Konstanta skalar timespan yang menunjukkan ukuran setiap partisi tanggalwaktu. Mulailah dengan nilai 1.00:00:00 (satu hari). Jangan menetapkan nilai yang lebih pendek, karena dapat mengakibatkan tabel memiliki sejumlah besar bagian kecil yang tidak dapat digabungkan.
Reference Konstanta skalar datetime yang menunjukkan titik waktu tetap, yang menurutnya partisi tanggalwaktu disejajarkan. Mulailah dengan 1970-01-01 00:00:00. Jika ada catatan di mana kunci partisi tanggalwaktu memiliki nilai null, nilai partisinya diatur ke nilai Reference.
OverrideCreationTime bool menunjukkan apakah waktu pembuatan minimum dan maksimum tingkat hasil harus ditimpa oleh rentang nilai dalam kunci partisi atau tidak. Default ke false. Atur ke true jika data tidak diserap dalam urutan waktu kedatangan. Misalnya, satu file sumber dapat menyertakan nilai tanggalwaktu yang jauh, dan/atau Anda mungkin ingin menerapkan retensi atau penembolokan berdasarkan nilai tanggalwaktu daripada waktu penyerapan.

Ketika OverrideCreationTime diatur ke true, tingkat mungkin terlewatkan dalam proses penggabungan. Tingkatan terlewatkan jika waktu pembuatannya lebih lama dari Lookback periode kebijakan penggabungan Tingkat tabel. Untuk memastikan bahwa tingkatan dapat ditemukan, atur Lookback properti ke HotCache.

Contoh partisi tanggalwaktu rentang seragam

Cuplikan memperlihatkan kunci partisi rentang tanggal seragam di atas kolom jenis datetime bernama timestamp. Ini menggunakan datetime(2021-01-01) sebagai titik referensinya, dengan ukuran 7d untuk setiap partisi, dan tidak mengesampingkan waktu pembuatan sejauh mana.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

Objek kebijakan

Secara default, kebijakan pemartisian data tabel adalah null, dalam hal ini data dalam tabel tidak akan dipartisi ulang setelah diserap.

Kebijakan partisi data memiliki properti utama berikut:

  • PartitionKeys:

  • EffectiveDateTime:

    • Tanggal UTC dari mana kebijakan tersebut efektif.
    • Properti ini bersifat opsional. Jika tidak ditentukan, kebijakan akan berlaku untuk data yang tertelan setelah kebijakan diterapkan.

Perhatian

  • Anda dapat mengatur nilai tanggalwaktu di masa lalu dan partisi data yang sudah dicerna. Namun, praktik ini dapat secara signifikan meningkatkan sumber daya yang digunakan dalam proses partisi.
  • Dalam kebanyakan kasus, disarankan untuk hanya memiliki data yang baru dicerna dipartisi, dan untuk menghindari partisi sejumlah besar data historis.
  • Jika Anda memilih untuk mempartisi data historis, pertimbangkan untuk melakukannya secara bertahap, dengan mengatur EffectiveDateTime ke langkah datetime sebelumnya hingga beberapa hari setiap kali Anda mengubah kebijakan.

Contoh pemartisian data

Objek kebijakan partisi data dengan dua kunci partisi.

  1. Kunci partisi hash di atas kolom jenis string bernama tenant_id.
    • Kunci ini menggunakan fungsi hash XxHash64, dengan MaxPartitionCount diatur ke nilai 128yang disarankan, dan default Seed dari 1.
  2. Kunci partisi tanggalwaktu rentang seragam di atas datetimetyped kolom tipe bernama timestamp.
    • Ini digunakan datetime(2021-01-01) sebagai titik referensinya, dengan ukuran 7d untuk setiap partisi.
{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

Properti tambahan

Properti berikut dapat didefinisikan sebagai bagian dari kebijakan. Properti ini bersifat opsional dan kami sarankan untuk tidak mengubahnya.

Properti Deskripsi Nilai yang direkomendasikan Nilai default
MinRowCountPerOperation Target minimum untuk jumlah hitungan baris dari tingkat sumber dari operasi partisi data tunggal. 0
MaxRowCountPerOperation Target maksimum untuk jumlah hitungan baris dari luas sumber dari operasi partisi data tunggal. Tetapkan nilai yang lebih rendah dari 5M jika Anda melihat bahwa operasi partisi menghabiskan sejumlah besar memori atau CPU per operasi. 0, dengan target default 5.000.000 catatan.
MaxOriginalSizePerOperation Target maksimum untuk jumlah ukuran asli (dalam byte) dari tingkat sumber operasi partisi data tunggal. Jika operasi partisi mengonsumsi sejumlah besar memori atau CPU per operasi, tetapkan nilai yang lebih rendah dari 5 GB. 0, dengan target default 5.368.709.120 byte (5 GB).

Proses pemartisian data

  • Pemartisian data berjalan sebagai proses latar belakang pasca-penyerapan.
    • Tabel yang terus diserap diharapkan selalu memiliki "ekor" data yang belum dipartisi (tingkat nonhomogen).
  • Partisi data hanya berjalan pada tingkat panas, terlepas dari nilai properti EffectiveDateTime dalam kebijakan tersebut.

Anda dapat memantau status partisi tabel dengan kebijakan yang ditentukan dalam database dengan menggunakan perintah statistik partisi .show database extents dan metrik partisi.

Kapasitas pemartisian

  • Proses partisi data menghasilkan penciptaan lebih banyak tingkat. Tingkat kapasitas penggabungan dapat meningkat secara bertahap, sehingga proses penggabungan tingkat dapat mengikuti.

  • Jika ada throughput penyerapan tinggi, atau jumlah tabel yang cukup besar yang memiliki kebijakan partisi yang ditentukan, maka kapasitas partisi Extents dapat meningkat secara bertahap, sehingga proses tingkat partisi dapat mengikuti.

  • Untuk menghindari mengonsumsi terlalu banyak sumber daya, peningkatan dinamis ini dibatasi. Anda mungkin diminta untuk secara bertahap dan linier meningkatkannya di luar tutup, jika habis sepenuhnya.
    • Jika meningkatkan kapasitas menyebabkan peningkatan yang signifikan dalam penggunaan sumber daya kluster, Anda dapat menaikkan peningkatan/kluster, baik secara manual, atau dengan mengaktifkan skala otomatis.

Batasan

  • Upaya untuk mempartisi data dalam database yang sudah memiliki lebih dari 5.000.000 jangkauan akan dibatasi.
    • Dalam kasus seperti itu EffectiveDateTime , properti kebijakan pemartisian tabel dalam database akan secara otomatis tertunda selama beberapa jam, sehingga Anda dapat mengevaluasi ulang konfigurasi dan kebijakan Anda.

Outlier dalam kolom yang dipartisi

  • Situasi berikut dapat berkontribusi pada distribusi data yang tidak seimbang di seluruh simpul, dan menurunkan performa kueri:
    • Jika kunci partisi hash mencakup nilai yang jauh lebih umum daripada yang lain, misalnya, string kosong, atau nilai generik (seperti null atau N/A).
    • Nilai mewakili entitas (seperti tenant_id) yang lebih lazim dalam himpunan data.
  • Jika kunci partisi tanggalwaktu rentang seragam memiliki persentase nilai yang cukup besar yang "jauh" dari sebagian besar nilai dalam kolom, overhead proses partisi data ditingkatkan dan dapat menyebabkan banyak tingkat kecil untuk dilacak. Contoh situasi seperti itu adalah nilai tanggalwaktu dari masa lalu atau masa depan yang jauh.

Dalam kedua kasus ini, "perbaiki" data, atau filter rekaman yang tidak relevan dalam data sebelum atau pada waktu penyerapan, untuk mengurangi overhead partisi data. Misalnya, gunakan kebijakan pembaruan.

Konten terkait