New to Kestra?
Use blueprints to kickstart your first workflows.
Run a SQL assertion query on Huawei Cloud DLI, alert Slack when a data quality rule is violated, and log the result.
DLI (Data Lake Insight) is Huawei's serverless Spark SQL engine over OBS and federated sources - the Huawei Cloud equivalent of Amazon Athena. Nothing in DLI itself turns a failed data quality rule into a notification: you either query the console by hand or you don't know until a downstream job breaks. This blueprint runs a single SQL assertion on a schedule, compares its result to a threshold, and alerts the moment the rule is violated.
This blueprint was created by Mohit Jeswani.
run_assertion (io.kestra.plugin.huawei.dli.Query) submits assertion_sql as a DLI SQL
job on queue and fetches the single result row directly via fetchType: FETCH_ONE.
Read-only, as long as assertion_sql is a SELECT.evaluate (io.kestra.plugin.core.output.OutputValues) reads violation_count from the
result row and compares it to max_violation_count. A DLI job status other than
FINISHED is treated as CRITICAL, the same as a violation.route (io.kestra.plugin.core.flow.If):summary logs the count and severity, closing the governance cycle.errors alerts Slack if the flow itself fails outright, for example an expired AK/SK.assertion_sql at a different rule and reuse the same flow
for null-key checks, duplicate-row checks, referential integrity checks, or any other
count-shaped assertion.dli.Query used for a
read-only assertion, distinct from the plugin's own documented STORE/export-to-OBS use case.DLI runs the SQL; it does not decide a cadence, compare the result to a threshold, or notify
anyone. Kestra keeps assertion_sql and max_violation_count as flow inputs instead of a
hardcoded script, turns the single-row result into a Slack page with severity attached, and
keeps a full execution history of every check, compliant or not.
default queue cannot fetch results via the preview API this blueprint relies on).This flow calls the Huawei Cloud DLI API directly over HTTPS; there is no official local DLI
emulator, so run_assertion cannot be exercised against a local Docker container. Validate
assertion_sql directly in the DLI console's SQL editor first, then point this blueprint at it.
HUAWEI_AK: the IAM access key used by run_assertion. In Kestra OSS, provide it as the
base64-encoded environment variable SECRET_HUAWEI_AK.HUAWEI_SK: the IAM secret key paired with HUAWEI_AK. In Kestra OSS, provide it as the
base64-encoded environment variable SECRET_HUAWEI_SK.SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the
base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.| Input | Default | Purpose |
|---|---|---|
region |
eu-west-101 |
Huawei Cloud region used to sign DLI requests |
database |
<your-dli-database> |
DLI currentdb for the assertion query |
queue |
<your-dli-queue> |
Dedicated DLI SQL queue, required for FETCH_ONE |
assertion_sql |
a null-check example | SELECT returning one row aliased violation_count |
max_violation_count |
0 |
violation_count above this triggers the alert |
{{ outputs.run_assertion.row.violation_count }}: the raw value returned by the assertion.{{ outputs.run_assertion.status }}: FINISHED, FAILED, or CANCELLED.{{ outputs.evaluate.values.severity }}: OK, DATA_QUALITY_VIOLATION, or CRITICAL.assertion_sql must alias its single output column violation_count exactly; this blueprint
reads that column name directly rather than taking "whatever the first column is", so a typo
in the alias surfaces as a null comparison, not a clear error.fetchType: FETCH_ONE is not supported on DLI's shared default queue - queue must name a
dedicated DLI SQL queue, or the task fails fast with DLI's own documented limitation.assertion_sql to be read-only. DLI will execute DDL/DML just as readily as
a SELECT; nothing here stops an assertion query that was accidentally written as an UPDATE.FETCH_ONE only ever reads
the first row, but relevant if you adapt this blueprint's run_assertion task to use
fetchType: FETCH instead for a multi-row assertion.HUAWEI_AK, HUAWEI_SK and SLACK_WEBHOOK_URL secrets.assertion_sql in the DLI console against a real table, confirming it returns one
row with a violation_count column.database and queue to match, then run the flow and confirm summary logs a count.max_violation_count below the real count to confirm alert fires.hourly trigger once the threshold reflects your actual data quality bar.assertion_sql values with io.kestra.plugin.core.flow.Loop to run
several data quality rules against the same database in one scheduled run.alert task for a Huawei Cloud SMN Publish task to page through Huawei's own
notification service instead.fetchType to STORE and read the exported OBS file in a downstream task when a
violation needs the actual offending rows, not just the count.