All Products
Search

This Product

    DataWorks:Konfigurasi kualitas data

    Document Center

    DataWorks:Konfigurasi kualitas data

    Last Updated:Mar 01, 2026

    Spesifikasi ini mendefinisikan resource untuk pemantauan dan aturan Kualitas Data dalam modul Data Quality DataWorks. Spesifikasi ini ditulis dalam format YAML dan digunakan sebagai parameter permintaan untuk OpenAPI guna mengelola resource dalam Produk Data Quality DataWorks.

    Definisi dasar

    Contoh YAML

    Aturan pemantauan Kualitas Data yang sederhana didefinisikan sebagai berikut:

    datasets:
  - type: Table
    tables:
      - tb_d_spec_demo
    dataSource:
      name: odps_first
      envType: Dev
rules:
  - assertion: row_count > 0

    Deskripsi properti

    Contoh spesifikasi di atas mendefinisikan aturan pemantauan Kualitas Data yang sederhana:

    • datasets: Objek yang dipantau untuk Kualitas Data. Properti ini mencakup tiga subproperti berikut:

      • type: Jenis objek yang dipantau. Saat ini, hanya enumerasi Table yang didukung.

      • dataSource: Sumber data dari objek yang dipantau. Anda dapat mengatur name dan envType untuk mengidentifikasi sumber data tersebut. Anda dapat memanggil operasi ListDataSources untuk memperoleh nama sumber data.

        Catatan

        Saat ini, hanya beberapa jenis sumber data yang didukung. Untuk informasi selengkapnya, lihat Daftar jenis sumber data yang didukung.

      • tables: Jika objek yang dipantau adalah `Table`, Anda dapat mengonfigurasi nama tabelnya.

        Catatan

        Jika sumber data disambungkan pada level database dan Anda perlu memantau tabel dalam skema non-default, Anda dapat mengonfigurasi tabel dalam format schema.table.

    • rules: Aturan yang diharapkan dipenuhi oleh data. Konfigurasi pemantauan Kualitas Data dapat berisi beberapa aturan.

      Saat pemantauan Kualitas Data dijalankan, sistem akan memindai data dalam objek yang dipantau, menghitung nilai metrik untuk setiap aturan, lalu membandingkannya dengan ambang batas yang ditentukan. Perbandingan ini menentukan apakah aturan tersebut lolos atau tidak.

      Umumnya, ekspektasi data dijelaskan melalui pernyataan assertion, yang mencakup jenis metrik (misalnya, row_count), simbol perbandingan (misalnya, >), dan ambang batas (misalnya, 0). Hasil pemeriksaan dapat berupa salah satu dari tiga status berikut:

      • pass: Pemeriksaan berhasil. Nilai metrik yang dikumpulkan berada dalam rentang yang ditentukan oleh ambang batas.

      • fail: Pemeriksaan gagal. Nilai metrik yang dikumpulkan berada di luar rentang yang ditentukan oleh ambang batas.

      • error: Terjadi error. Terjadi pengecualian lain selama pemeriksaan, seperti kesalahan sintaksis.

      Catatan

    Metode definisi ambang batas

    Pernyataan assertion mendukung metode definisi ambang batas berikut:

    Ambang batas tetap

    Metode ini cocok untuk skenario di mana Anda perlu membandingkan langsung nilai metrik dengan nilai tetap. Definisi ambang batas tetap terdiri atas bagian-bagian berikut:

    • metrik

    • argumen (opsional)

    • simbol perbandingan (opsional)

    • ambang batas (opsional)

    Contoh konfigurasi

    rules:
  # Jumlah baris data harus lebih besar dari 0.
  - assertion: row_count > 0
  # Nilai maksimum bidang size harus kurang dari atau sama dengan 500.
  - assertion: max(size) <= 500

    Tabel berikut menjelaskan keempat bagian ekspresi ambang batas tetap.

    Bagian ekspresi

    row_count > 0

    max(size) <= 500

    metrik

    row_count

    max

    argumen (opsional)

    /

    (size)

    simbol perbandingan (opsional)

    >

    <=

    ambang batas (opsional)

    0

    500

    Untuk informasi selengkapnya tentang simbol perbandingan yang didukung, lihat Simbol perbandingan yang didukung.

    Ambang batas fluktuasi

    Metode ini cocok untuk skenario di mana Anda membandingkan nilai metrik saat ini dengan nilai historis metrik yang sama. Misalnya, Anda dapat memastikan bahwa selisih jumlah pengguna hari ini dan kemarin berada dalam rentang 100, atau fluktuasi pendapatan hari ini dibandingkan rata-rata pendapatan tujuh hari terakhir berada dalam 10%.

    Umumnya, Anda dapat menambahkan change for sebelum metric untuk menggambarkan ambang batas fluktuasi. Definisi ambang batas fluktuasi terdiri atas bagian-bagian berikut:

    • change (kata kunci)

    • jenis agregasi (opsional)

    • rentang waktu

    • percent (kata kunci, opsional)

    • for (kata kunci)

    • metrik

    • argumen (opsional)

    • simbol perbandingan (opsional)

    • ambang batas (opsional)

    Format gabungan ekspresinya adalah: change [aggregate_type] [time_window] [percent] for metric [argument] [comparison_symbol threshold].

    Contoh konfigurasi

    Contoh 1: Membandingkan selisih dengan hasil pemeriksaan pada rentang waktu tertentu

    Anda dapat menambahkan rentang waktu di antara change ... for untuk secara eksplisit menentukan metrik historis mana yang akan dibandingkan dengan nilai metrik saat ini:

    rules:
  # Selisih antara jumlah baris data saat ini dan jumlah baris data dari pemeriksaan 7 hari lalu harus berada dalam rentang 10.000.
  - assertion: change 7 days ago for row_count < 10000

    Contoh 2: Mengagregasi hasil pemeriksaan pada rentang waktu tertentu lalu membandingkan selisihnya

    Anda dapat menambahkan metode agregasi (aggregate type) di antara change dan rentang waktu. Sistem menggunakan metode agregasi yang ditentukan untuk menghitung hasil antara dari catatan pemeriksaan dalam rentang waktu tersebut. Hasil ini kemudian digunakan sebagai nilai referensi untuk pemeriksaan saat ini:

    rules:
  # Selisih antara jumlah baris data saat ini dan rata-rata jumlah baris data selama 7 hari terakhir harus berada dalam rentang 10.000.
  - assertion: change average last 7 days for row_count < 10000

    Dua metode agregasi berikut didukung:

    • avg: Rata-rata.

    • var: Varians.

    Jika Anda tidak menentukan metode agregasi, sistem akan membandingkan nilai metrik saat ini dengan semua catatan pemeriksaan historis dalam rentang waktu tersebut, lalu menggunakan status dengan tingkat keparahan tertinggi sebagai status pemeriksaan akhir.

    Contoh 3: Membandingkan persentase fluktuasi dengan hasil pemeriksaan historis

    Anda dapat menambahkan percent di antara change ... for untuk menunjukkan bahwa persentase fluktuasi harus dihitung terlebih dahulu sebelum dibandingkan dengan ambang batas:

    rules:
  # Persentase fluktuasi antara jumlah baris data saat ini dan jumlah baris data dari pemeriksaan 7 hari lalu harus berada dalam rentang 50%.
  - assertion: change 7 days ago percent for row_count < 50%

    • Anda dapat menambahkan simbol % di akhir ambang batas untuk meningkatkan keterbacaan.

    • Misalkan nilai metrik saat ini adalah c dan nilai sebelumnya adalah cl. Maka, percent = (c-cl) / cl:

      • Jika `cl` bernilai 0 dan `c` juga 0, persentase yang dihitung adalah 0.

      • Jika `cl` bernilai 0 dan `c` tidak 0, persentase tidak dapat dihitung, dan hasil pemeriksaan menjadi `error`.

    • Hasilnya bisa berupa angka negatif. Perhatikan hal ini saat menentukan ambang batas. Anda dapat menggunakan between...and..., seperti yang disebutkan di bawah, untuk menentukan rentang persentase fluktuasi.

    Ambang batas rentang

    Anda dapat menggunakan between...and... untuk mendefinisikan rentang ambang batas.

    Definisikan ambang batas interval tertutup

    Interval yang didefinisikan dengan between...and... secara default merupakan interval tertutup. Misalnya, `warn` dipicu jika fluktuasi jumlah baris day-over-day berada di luar rentang [-1%, 1%]. `fail` dipicu jika fluktuasi berada di luar rentang [-5%, 5%]. Pemeriksaan lolos jika nilai berada dalam interval [10, 15].

    datasets:
  - type: Table
    tables:
      - tb_d_spec_demo
    filter: dt='$[yyyymmdd]' AND hh='$[hh24-1/24]'
    dataSource:
      name: odps_first
      envType: Dev
rules:
  - assertion: change 1 day ago percent for row_count
    warn: 
      - when not between -1% and 1%
    fail: 
      - when not between -5% and 5%

    Menambahkan definisi ambang batas multi-level

    Selain mendefinisikan ambang batas yang diharapkan dalam pernyataan assertion aturan, Anda juga dapat menghilangkan ambang batas yang diharapkan dari pernyataan assertion dan mengatur properti warn atau fail aturan untuk mendefinisikan tingkat ambang batas yang lebih granular. Contohnya:

    rules:
  - assertion: duplicate_count(phone)
    warn: when between 1 and 10
    fail: when > 10

    Pada potongan kode di atas, dua tingkat ambang batas, warn dan fail, didefinisikan:

    • Pemeriksaan lolos jika jumlah baris duplikat untuk bidang phone bernilai 0.

    • Pemeriksaan gagal jika jumlah baris duplikat untuk bidang phone lebih besar dari 10.

    • Hasil pemeriksaan adalah warn jika jumlah baris duplikat untuk bidang phone berada di antara 1 dan 10.

    Kebijakan penanganan untuk ambang batas warn dan fail yang tumpang tindih

    Rentang ambang batas untuk warn dan fail dapat tumpang tindih. Jika nilai metrik jatuh ke dalam rentang tumpang tindih ini, sistem akan menggunakan status yang lebih parah, yaitu fail.

    Gunakan not between...and... untuk mendefinisikan komplemen suatu interval

    Anda dapat menambahkan not sebelum between...and... untuk memperoleh komplemen interval tersebut. Contohnya:

    rules:
  - assertion: duplicate_count(phone)
    warn: 
      - when not between -1% and 1%
    fail:
      - when not between -5% and 5%

    Interval yang didefinisikan pada potongan kode di atas ditunjukkan pada gambar berikut:

    image

    Menetapkan identitas unik untuk suatu aturan

    Anda dapat menentukan identity untuk suatu aturan. Ini berfungsi sebagai pengenal unik untuk aturan tersebut dalam cakupan pemantauan Kualitas Data yang sama.

    • Jika Anda tidak menentukan identity saat membuat aturan, sistem secara otomatis menetapkan id untuk aturan tersebut.

    • Anda harus memastikan bahwa identity bersifat unik dalam aturan pemantauan Kualitas Data yang sama. Jika tidak, pembaruan dapat gagal atau secara keliru memperbarui aturan lain. Kami menyarankan menggunakan string yang mudah dibaca untuk memudahkan manajemen.

    • Untuk aturan dengan ambang batas fluktuasi (change...for...) dan aturan deteksi anomali (anomaly detection for ...), identity aturan digunakan untuk mengkueri riwayat pemeriksaan.

    • Saat sistem menerima permintaan untuk memperbarui konfigurasi pemantauan kualitas, sistem memproses permintaan tersebut sebagai berikut:

      • Pertama, sistem melakukan traversal terhadap setiap aturan dalam permintaan pembaruan. Sistem menggunakan id aturan untuk mencocokkan dan memperbarui aturan yang sudah ada dalam konfigurasi pemantauan kualitas.

      • Sistem menghapus aturan yang sudah ada dalam konfigurasi pemantauan kualitas yang tidak memiliki id yang cocok.

      • Sistem membuat aturan yang tersisa dari permintaan pembaruan sebagai aturan baru dalam konfigurasi pemantauan kualitas.

    Contoh berikut menunjukkan cara menentukan identity:

    rules:
  - assertion: row_count > 0
    name: Jumlah baris data lebih besar dari 0
    # Tentukan pengenal unik dalam cakupan pemantauan Kualitas Data.
    identity: table-not-empty

    Menentukan tingkat keparahan bisnis suatu aturan

    Anda dapat mengatur severity suatu aturan untuk menandai tingkat keparahan dampaknya terhadap bisnis Anda. Hal ini membantu dalam manajemen selanjutnya. Contohnya:

    rules:
  - assertion: row_count > 0
    severity: High

    Properti severity mendukung dua tingkat:

    • High

    • Normal (default)

    Menetapkan status aktif suatu aturan

    Anda dapat menentukan flag enabled untuk suatu aturan guna mengelola status aktifnya. Untuk aturan yang tidak ingin digunakan sementara tetapi tidak ingin dihapus, Anda dapat mengatur enabled ke false. Hal ini akan menonaktifkan aturan tersebut sementara, sehingga tidak akan dipicu selama eksekusi pemantauan.

    rules:
  - assertion: row_count > 0
    # Status aktif aturan. Nilai default adalah true.
    enabled: false

    Menetapkan pernyataan prasyarat

    Pada beberapa skenario bisnis, Anda mungkin perlu mengeksekusi pernyataan SET untuk menyesuaikan parameter sebelum mengeksekusi SQL guna menghitung metrik. Hal ini memastikan bahwa SQL perhitungan metrik dapat dijalankan dengan benar atau menjamin performa. Anda dapat menambahkan pengaturan settingConfig dalam aturan tersebut. Contohnya:

    rules:
  - assertion: row_count > 0
    # Tetapkan pernyataan SET prasyarat yang akan dieksekusi.
    settingConfig: SET odps.sql.udf.timeout=600s; SET odps.sql.python.version=cp27;

    Menetapkan sakelar untuk menyimpan data bermasalah

    Anda dapat mengaktifkan sakelar untuk menyimpan data bermasalah pada level aturan. Saat pemeriksaan aturan tidak lolos (dalam status warn atau fail), sistem secara otomatis menyaring data yang menyebabkan kegagalan dan menyimpannya ke tabel lain dalam database yang sama dengan tabel objek yang dipantau. Untuk mengaktifkan sakelar penyimpanan data bermasalah, gunakan konfigurasi berikut:

    rules:
  - assertion: duplicate_count(phone) = 0
    collectFailedRows: true

    Anda dapat mengatur collectFailedRows ke true untuk mengaktifkan penyimpanan data bermasalah. Untuk aturan SQL kustom, Anda juga harus menentukan failedRowsQuery untuk secara eksplisit mengonfigurasi pernyataan filter guna menyimpan data bermasalah:

    rules:
  - assertion: id_null_count = 0
    id_null_count:
      expression: id IS NULL
    collectFailedRows: true
    failedRowsQuery: SELECT * FROM tb_d_spec_demo WHERE dt = '$[yyyymmdd-1]' AND id IS NULL

    Selain aturan SQL kustom, hanya metrik berikut yang mendukung penyimpanan data bermasalah. Mengaktifkan collectFailedRows belum didukung untuk metrik lain saat ini:

    • missing_count

    • missing_percent

    • duplicate_count

    • duplicate_percent

    • distinct_count

    • distinct_percent

    Menetapkan nama dan deskripsi aturan

    Anda dapat menetapkan nama dan deskripsi untuk suatu aturan guna memudahkan manajemen.

    Sebagai contoh, Anda dapat menetapkan nama untuk seluruh konfigurasi pemantauan dan nama terpisah untuk setiap aturan. Nama-nama ini dapat digunakan dalam hasil pemeriksaan selanjutnya dan pada halaman UI untuk memudahkan manajemen.

    datasets:
  - type: Table
    tables:
      - tb_d_spec_demo
    filter: dt='$[yyyymmdd]' AND hh='$[hh24-1/24]'
    dataSource:
      name: odps_first
      envType: Dev
rules:
  - assertion: row_count > 0
    # Nama dan deskripsi aturan
    name: Jumlah baris data lebih besar dari 0
    description: Data keluaran tidak boleh kosong

    Menetapkan penyaringan data

    Menetapkan penyaringan data untuk suatu aturan

    Jika Anda hanya perlu menggunakan subset data untuk statistik metrik saat memeriksa suatu aturan, Anda dapat menambahkan pengaturan filter ke aturan tersebut. Sebagai contoh, untuk menghitung hanya data di mana bidang id tidak bernilai NULL:

    rules:
  - assertion: row_count > 0
    filter: id IS NOT NULL

    Menetapkan penyaringan data untuk pemantauan kualitas

    Anda juga dapat menambahkan pengaturan filter dalam Scan.Dataset. Dalam kasus ini, filter berlaku untuk semua aturan dalam konfigurasi pemantauan kualitas selama proses pemeriksaan.

    datasets:
  - type: Table
    tables:
      - tb_d_spec_demo
    filter: dt='$[yyyymmdd]' AND hh='$[hh24-1/24]'
    dataSource:
      name: odps_first
rules:
  - assertion: row_count > 0

    Pada potongan kode di atas, pengaturan filter ditambahkan ke dataset. Saat setiap aturan diperiksa, data terlebih dahulu disaring menggunakan filter ini sebelum pemeriksaan selanjutnya dilakukan.

    Catatan

    Pada contoh definisi filter, ekspresi waktu $[yyyymmdd-1] digunakan. Sistem mengganti ekspresi ini dalam filter dengan nilai yang dihitung berdasarkan parameter triggerTime dan offset waktu. Untuk informasi selengkapnya tentang metode referensi parameter yang didukung, lihat Konfigurasi penyaringan data.

    Lampiran

    Simbol perbandingan yang didukung

    • >

    • >=

    • <

    • <=

    • =

    • !=

    • between ... and ...

    Daftar jenis sumber data yang didukung

    Jenis sumber data berikut didukung:

    • maxcompute

    • hologres

    • emr

    • mysql

    • analyticdb_for_mysql

    • analyticdb_for_postgresql

    • cdh

    • starrocks

    Jenis metrik sistem bawaan yang didukung

    • avg

    • row_count

    • sum

    • min

    • max

    • distinct_count

    • distinct_percent

    • table_size

    • missing_count

    • missing_percent

    • duplicate_percent

    • duplicate_count

    • group_by

    • invalid_count

    • invalid_distinct_count

    Metode definisi rentang waktu

    DataWorks Data Quality mendukung beberapa metode untuk mendefinisikan rentang waktu. Format dasarnya adalah sebagai berikut:

    • n satuan waktu lalu: n (minute[s]|hour[s]|day[s]|week[s]|month[s]) ago, misalnya, n months ago, n days ago, atau n hours ago.

      • 1 day ago

      • 7 days ago

      • 1 month ago

      • 8 hours ago

      • 15 minutes ago

    • Rentang waktu relatif: last n (minute[s]|hour[s]|day[s]|week[s]|month[s]) , seperti last 15 minutes, last 7 days, dan last 1 month.

      • last 15 minutes

      • last 24 hours

        Catatan

        Dimulai dari 24 jam sebelum waktu saat ini dan berakhir pada waktu saat ini. Titik data dikumpulkan setiap jam.

      • last 7 days

      • last 1 month

    • 1/2/3/.../-3/-2/-1 of (current|last|n) (months|weeks) (ago)

      • Waktu yang sama pada tanggal 1 bulan ini: 1 of current month

      • Waktu yang sama pada hari terakhir bulan lalu: -1 of last month

      • Waktu yang sama pada hari Selasa tiga minggu lalu: 2 dari 3 minggu lalu