Bagikan melalui

Kebijakan pemartisian

  • Artikel

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 partisi adalah untuk meningkatkan performa kueri dalam skenario tertentu yang didukung.

Catatan

Secara default, ketika kebijakan pemartisian data tidak ditentukan (adalah null), jangkauan dipartisi berdasarkan waktu pembuatan (penyerapan). Dalam kebanyakan kasus, 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.

  • Filter yang sering pada kardinalitas string atau kolom sedang atau guid tinggi:
    • Misalnya: solusi multi-penyewa, 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 kunci partisi hash menjadi string kolom atau guid , dan atur properti ke PartitionAssigmentModeuniform.
  • 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 PartitionAssigmentMode properti ke ByPartition.
  • Konsumsi data out-of-order:
    • 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. Tetapi, setiap tabel tambahan menambahkan overhead ke proses pemartisian data latar belakang yang berjalan pada node kluster. Menetapkan kebijakan pada lebih banyak tabel akan mengakibatkan lebih banyak sumber daya kluster 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.

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

Kunci partisi hash

Jika kebijakan menyertakan kunci partisi hash, semua jangkauan homogen yang termasuk dalam partisi yang sama akan ditetapkan ke node data yang sama dalam kluster.

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 string tertentu atau guid yang berdimensi besar (kardinalitas 10M atau lebih tinggi), seperti device_ID, atau 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 shuffle, dan di mana shuffle key digunakan di join, summarize atau make-series merupakan kunci partisi hash tabel, diharapkan berperforma lebih baik karena jumlah data yang diperlukan untuk bergerak melintasi node kluster 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 partisi data pada node cluster, dan jumlah 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 node dalam kluster. ByPartition: Semua tingkat homogen (dipartisi) yang termasuk dalam partisi yang sama ditugaskan ke node yang sama.
Uniform: Nilai partisi jangkauan diabaikan. Jangkauan ditetapkan secara seragam ke node kluster.		 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, jangkauan mungkin terlewatkan dalam proses penggabungan. Jangkauan terlewatkan jika waktu pembuatannya lebih lama dari Lookback periode kebijakan penggabungan Jangkauan tabel. Untuk memastikan bahwa jangkauan dapat ditemukan, atur properti ke LookbackHotCache.

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 mengambil alih waktu pembuatan jangkauan.

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

Objek kebijakan

Secara default, kebijakan partisi 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

  • Partisi data berjalan sebagai proses latar belakang pasca-penyerapan dalam kluster.
    • 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 tingkat database .show .

Kapasitas pemartisian

  • Proses partisi data menghasilkan penciptaan lebih banyak tingkat. Kluster dapat secara bertahap meningkatkan kapasitas gabungan jangkauannya, sehingga proses penggabungan dapat mengikuti.
  • Jika ada throughput penyerapan yang tinggi, atau jumlah tabel yang cukup besar yang memiliki kebijakan pemartisian yang ditentukan, maka kluster secara bertahap dapat meningkatkan kapasitas jangkauan pemartisian, sehingga proses 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 partisi tabel dalam database akan secara otomatis tertunda selama beberapa jam, sehingga Anda dapat mengevaluasi kembali konfigurasi dan kebijakan Anda.

Outlier dalam kolom yang dipartisi

  • Situasi berikut dapat berkontribusi pada distribusi data yang tidak seimbang di seluruh node kluster, 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 yang seragam memiliki persentase nilai yang cukup besar yang "jauh" dari sebagian besar nilai di kolom, overhead proses partisi data meningkat dan dapat menyebabkan banyak hal kecil yang perlu dilacak oleh kluster. Contoh situasi seperti itu adalah nilai tanggalwaktu dari masa lalu atau masa depan yang jauh.

Dalam kedua kasus ini, baik "memperbaiki" data, atau menyaring catatan yang tidak relevan dalam data sebelum atau pada waktu penyerapan, untuk mengurangi overhead partisi data pada kluster. Misalnya, gunakan kebijakan pembaruan.

Konten terkait