Ringkasan kebijakan pembaruan

  • Artikel

Kebijakan pembaruan adalah mekanisme otomatisasi yang dipicu saat data baru ditulis ke tabel. Mereka menghilangkan kebutuhan akan orkestrasi khusus dengan menjalankan kueri untuk mengubah data yang diserap dan menyimpan hasilnya ke tabel tujuan. Beberapa kebijakan pembaruan dapat ditentukan pada satu tabel, memungkinkan transformasi yang berbeda dan menyimpan data ke beberapa tabel secara bersamaan. Tabel target dapat memiliki skema, kebijakan penyimpanan, dan kebijakan lainnya yang berbeda dari tabel sumber.

Misalnya, tabel sumber jejak tingkat tinggi dapat berisi data yang diformat sebagai kolom teks bebas. Tabel target dapat menyertakan garis jejak tertentu, dengan skema terstruktur baik yang dihasilkan dari transformasi data teks bebas tabel sumber menggunakan operator urai. Untuk informasi selengkapnya, skenario umum.

Diagram berikut menggambarkan tampilan tingkat tinggi dari kebijakan pembaruan. Ini menunjukkan dua kebijakan pembaruan yang dipicu saat data ditambahkan ke tabel sumber kedua dan menghasilkan data yang diubah ditambahkan ke dua tabel target.

Diagram memperlihatkan gambaran umum kebijakan pembaruan.

Kebijakan pembaruan tunduk pada batasan dan praktik terbaik yang sama dengan penyerapan reguler. Kebijakan tersebut menyesuaikan dengan ukuran kluster, dan lebih efisien saat menangani penyerapan massal.

Catatan

  • Tabel sumber dan target harus berada dalam database yang sama.
  • Skema fungsi kebijakan pembaruan dan skema tabel target harus cocok dengan nama, jenis, dan urutan kolomnya.

Menyerap data yang diformat meningkatkan performa, dan CSV lebih dipilih karena formatnya yang terdefinisi dengan baik. Namun, terkadang, Anda tidak memiliki kontrol atas format data, atau Anda ingin memperkaya data yang diserap, misalnya, dengan menggabungkan rekaman dengan tabel dimensi statis dalam database Anda.

Kueri kebijakan pembaruan

Jika kebijakan pembaruan ditentukan pada tabel target, beberapa kueri dapat berjalan pada data yang diserap ke dalam tabel sumber. Jika ada beberapa kebijakan pembaruan, urutan eksekusi belum tentu diketahui.

Batasan kueri

  • Kueri terkait kebijakan dapat memanggil fungsi yang disimpan, tetapi:
    • Ini tidak dapat melakukan kueri lintas kluster.
    • Ini tidak dapat mengakses data eksternal atau tabel eksternal.
    • Ini tidak dapat membuat panggilan (dengan menggunakan plugin).
  • Kueri tidak memiliki akses baca ke tabel yang mengaktifkan kebijakan RestrictedViewAccess .
  • Untuk memperbarui batasan kebijakan dalam penyerapan streaming, lihat batasan penyerapan streaming.

Peringatan

Kueri yang salah dapat mencegah penyerapan data ke dalam tabel sumber. Penting untuk dicatat bahwa batasan, serta kompatibilitas antara hasil kueri dan skema tabel sumber dan tujuan, dapat menyebabkan kueri yang salah untuk mencegah penyerapan data ke dalam tabel sumber.

Batasan ini divalidasi selama pembuatan dan eksekusi kebijakan, tetapi tidak ketika fungsi tersimpan arbitrer yang mungkin diperbarui oleh kueri. Oleh karena itu, sangat penting untuk membuat perubahan apa pun dengan hati-hati untuk memastikan kebijakan pembaruan tetap utuh.

Saat merujuk tabel Source di bagian Query kebijakan, atau dalam fungsi yang dirujuk oleh bagianQuery:

  • Jangan gunakan nama tabel yang memenuhi syarat. Sebagai gantinya, gunakan TableName.
  • Jangan gunakan database("DatabaseName").TableName atau cluster("ClusterName").database("DatabaseName").TableName.

Objek kebijakan pembaruan

Tabel dapat memiliki nol atau lebih objek kebijakan pembaruan yang terkait dengannya. Setiap objek tersebut direpresentasikan sebagai kantong properti JSON, dengan properti berikut ditentukan.

Properti Jenis Deskripsi
IsEnabled bool Menyatakan jika kebijakan pembaruan true - diaktifkan, atau false - dinonaktifkan
Sumber string Nama tabel yang memicu pemanggilan kebijakan pembaruan
Kueri string Kueri yang digunakan untuk menghasilkan data untuk pembaruan
IsTransactional bool Menyatakan jika kebijakan pembaruan bersifat transaksi atau tidak, defaultnya adalah false. Jika kebijakan bersifat transaksi dan kebijakan pembaruan gagal, tabel sumber tidak diperbarui.
PropagateIngestionProperties bool Menyatakan jika properti yang ditentukan selama penyerapan ke tabel sumber, seperti tag jangkauan dan waktu pembuatan, berlaku untuk tabel target.
ManagedIdentity string Identitas terkelola atas nama yang menjalankan kebijakan pembaruan. Identitas terkelola dapat berupa ID objek, atau kata yang dicadangkan system . Kebijakan pembaruan harus dikonfigurasi dengan identitas terkelola saat kueri mereferensikan tabel di database atau tabel lain dengan kebijakan keamanan tingkat baris yang diaktifkan. Untuk informasi selengkapnya, lihat Menggunakan identitas terkelola untuk menjalankan kebijakan pembaruan.

Catatan

Dalam sistem produksi, atur IsTransactional:true untuk memastikan bahwa tabel target tidak kehilangan data dalam kegagalan sementara.

Catatan

Pembaruan kaskade diperbolehkan, misalnya dari tabel A, ke tabel B, ke tabel C. Namun, jika kebijakan pembaruan ditentukan secara melingkar, maka akan terdeteksi saat runtime, dan rantai pembaruan terputus. Data diserap hanya sekali ke setiap tabel dalam rantai.

Perintah manajemen

Perintah manajemen kebijakan pembaruan meliputi:

Kebijakan pembaruan dimulai setelah penyerapan

Kebijakan pembaruan berlaku saat data diserap atau dipindahkan ke tabel sumber, atau jangkauan dibuat dalam tabel sumber, menggunakan salah satu perintah berikut:

Peringatan

Saat kebijakan pembaruan dipanggil sebagai bagian dari perintah .set-or-replace, secara default data dalam tabel turunan diganti dengan cara yang sama seperti pada tabel sumber. Data mungkin hilang di semua tabel dengan hubungan kebijakan pembaruan jika perintah replace dipanggil. Pertimbangkan untuk menggunakan .set-or-append sebagai gantinya.

Menghapus data dari tabel sumber

Setelah menyerap data ke tabel target, Anda dapat secara opsional menghapusnya dari tabel sumber. Atur periode penghapusan sementara 0sec (atau 00:00:00) dalam kebijakan penyimpanan tabel sumber, dan kebijakan pembaruan sebagai transaksional. Ketentuan berikut berlaku:

  • Data sumber tidak dapat dikueri dari tabel sumber
  • Data sumber tidak bertahan dalam penyimpanan tahan lama sebagai bagian dari operasi penyerapan
  • Performa operasional membaik. Sumber daya pasca penyerapan dikurangi untuk operasi grooming latar belakang pada jangkauan di tabel sumber.

Catatan

Ketika tabel sumber memiliki periode 0sec penghapusan sementara (atau 00:00:00), kebijakan pembaruan apa pun yang merujuk pada tabel ini harus transaksi.

Dampak performa

Kebijakan pembaruan dapat memengaruhi performa kluster, dan penyerapan untuk jangkauan data dikalikan dengan jumlah tabel target. Penting untuk mengoptimalkan kueri terkait kebijakan. Anda dapat menguji dampak performa kebijakan pembaruan dengan memanggil kebijakan pada jangkauan yang sudah ada, sebelum membuat atau mengubah kebijakan, atau pada fungsi yang digunakan dengan kueri.

Mengevaluasi penggunaan sumber daya

Gunakan .show queries, untuk mengevaluasi penggunaan sumber daya (CPU, memori, dan sebagainya) dengan parameter berikut:

  • Atur properti Source, nama tabel sumber, sebagai MySourceTable
  • Atur properti Query untuk memanggil fungsi bernama MyFunction()
// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
    MySourceTable
    | project ExtentId = extent_id(), IngestionTime = ingestion_time()
    | where IngestionTime > ago(10m)
    | top 1 by IngestionTime desc
    | project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
    MySourceTable
    | where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction

Kegagalan

Dengan pengaturan IsTransactional:falsedefault , data masih dapat diserap ke tabel sumber meskipun kebijakan tidak berjalan.

Pengaturan IsTransactional:true menjamin konsistensi antara data dalam tabel sumber dan target. Namun, jika kondisi kebijakan gagal, data tidak diserap ke tabel sumber. Atau, bergantung pada kondisi, terkadang data diserap ke tabel sumber, tetapi tidak ke tabel target. Namun, jika kebijakan Anda didefinisikan dengan tidak benar, atau ada ketidakcocokan skema, data tidak diserap ke tabel sumber atau target. Misalnya, ketidakcocokan antara skema output kueri dan tabel target dapat disebabkan oleh menghilangkan kolom dari tabel target.

Anda dapat melihat kegagalan menggunakan .show ingestion failures perintah.

.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true

Penanganan kegagalan

Kebijakan nontransaksi

Ketika diatur ke IsTransactional:false, kegagalan untuk menjalankan kebijakan diabaikan. Penyerapan tidak dicoba ulang secara otomatis. Anda dapat mencoba kembali penyerapan secara manual.

Kebijakan transaksional

Ketika diatur ke IsTransactional:true, jika metode penyerapan adalah pull, layanan Manajemen Data terlibat, dan penyerapan secara otomatis dicoba ulang sesuai dengan kondisi berikut:

  • Percobaan ulang dilakukan hingga salah satu pengaturan batas yang dapat dikonfigurasi berikut terpenuhi: DataImporterMaximumRetryPeriod atau DataImporterMaximumRetryAttempts
  • Secara default DataImporterMaximumRetryPeriod pengaturannya adalah dua hari, dan DataImporterMaximumRetryAttempts10
  • Periode backoff dimulai pada 2 menit, dan kelipatannya. Jadi operasi tunggu dimulai dengan 2 menit, kemudian meningkat menjadi 4 menit, lalu 8 menit, hingga 16 menit, dan seterusnya.

Dalam hal lain, Anda dapat mencoba kembali penyerapan secara manual.

Contoh ekstraksi, transformasi, pemuatan

Anda dapat menggunakan pengaturan kebijakan pembaruan untuk menjalankan ekstraksi, transformasi, pemuatan (ETL).

Dalam contoh ini, gunakan kebijakan pembaruan dengan fungsi sederhana untuk melakukan ETL. Pertama, kami buat dua tabel:

  • Tabel sumber - Berisi satu kolom berjenis string tempat data diserap.
  • Tabel target - Berisi skema yang diinginkan. Kebijakan pembaruan ditentukan pada tabel ini.

  1. Mari kita buat tabel sumber:

    .create table MySourceTable (OriginalRecord:string)

  2. Selanjutnya, buat tabel target:

    .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)

  3. Kemudian buat fungsi untuk mengekstrak data:

    .create function
 with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions')
     ExtractMyLogs()
    {
    MySourceTable
    | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string
    | project-away OriginalRecord
}

  4. Sekarang, atur kebijakan pembaruan untuk memanggil fungsi yang kita buat:

    .alter table MyTargetTable policy update
@'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'

  5. Untuk mengosongkan tabel sumber setelah data diserap ke dalam tabel target, tentukan kebijakan penyimpanan pada tabel sumber untuk memiliki 0 sebagai SoftDeletePeriod.

     .alter-merge table MySourceTable policy retention softdelete = 0s

Konten terkait