Page MenuHomePhabricator

Personal Dashboard health metrics events Iceberg table
Closed, ResolvedPublic3 Estimated Story Points

Description

The Personal Dashboard health metrics dashboard in Superset regularly times out and produces ghost queries which negatively affect Superset and Presto availability and performance (cf. T418542: Ghost queries overload Presto cluster).

One of such queries:

SELECT count(DISTINCT "user_id") AS "distinct visitors"
FROM
  (SELECT CAST(FROM_ISO8601_TIMESTAMP(meta.dt) AS DATE) AS dt,
          mediawiki.database AS wiki,
          agent.client_platform_family AS platform,
          performer.name AS user_id
   FROM event.product_metrics_web_base
   WHERE action = 'pageview'
     AND instrument_name = 'personal-dashboard-health-metrics'
     AND YEAR = 2026
     AND MONTH >= 2
     AND mediawiki.database IN ('enwiki',
                                'trwiki',
                                'thwiki',
                                'simplewiki',
                                'idwiki')
     AND meta.dt >= '2026-04-29T00:00:00'
     AND meta.dt <= '2026-06-11T14:35:48') AS "virtual_table"
WHERE "dt" >= DATE '2026-04-29'
  AND "dt" < DATE '2026-06-11'
LIMIT 50000

The product_metrics_web_base table is so massive now with all the instruments & experiments sending data to it and since it's not timestamp-partitioned (being a Hive table rather than an Iceberg table). This metric's calculation should probably be offloaded into a pipeline.

As an immediately remediation, @MNeisler has unpublished the dashboard and asked the stakeholders not to open it until it's been optimized.

Ideally we would have T417176: Enable Refine event tables to Iceberg but in the meantime let's siphon instrument_name = 'personal-dashboard-health-metrics' events into a timestamp-partitioned Iceberg table wmf_product.personal_dashboard_event_v1 like we're currently siphoning all experiment data out of web base table into wmf_experiments.experiment_event_v1 (which powers GrowthBook's analysis of TK experiments) (work was done in T414105)

A smaller subset of web_base that is timestamp-partitioned will be faster and less demanding to query in Superset. Once the queries powering the dashboard are modified to source from the new table, the dashboard can be re-published and stakeholders will be able to use it again. This solution will also buy time for T428987: Update Personal Dashboard Superset metric calculations to use dbt model.

Acceptance criteria

  • An hourly updated wmf_product.personal_dashboard_v1 Iceberg table, partitioned on timestamp, limited to 90 days of data

Details

Related Changes in GitLab:
TitleReferenceAuthorSource BranchDest Branch
Add personal_dashboard_hourly DAGrepos/data-engineering/airflow-dags!2300bearlogapersonal-dashboard-eventmain
personal_dashboard_event table queriesrepos/product-analytics/data-pipelines!53bearlogapersonal-dashboard-eventmain
Customize query in GitLab

Event Timeline

mpopov triaged this task as High priority.Fri, Jun 12, 7:57 PM
mpopov moved this task from Next 2 weeks to Doing on the Product-Analytics (Kanban) board.
mpopov set the point value for this task to 3.
$ sudo -u analytics-product kerberos-run-command analytics-product spark3-sql \
 -f create_personal_dashboard_event_table_iceberg.hql \
 --database wmf_product \
 -d location=/wmf/data/wmf_product/personal_dashboard_event_v1

@MNeisler: wmf_product.personal_dashboard_event_v1 now backfilling from 2026-03-15

(The table's schema is the same as product_metrics_web_base, sans experiment column since that will never be needed.)

You can check in on its progress in https://airflow-analytics-product.wikimedia.org/dags/personal_dashboard_hourly/grid

When you modify the queries remember to switch from presto_analytics_hive to presto_analytics_iceberg.

You should in theory be able to use the following:

-- templating to apply time range filters directly to dataset
{% if from_dttm is not none %}
AND timestamp >= from_iso8601_timestamp('{{ from_dttm }}')
{% endif %}
{% if to_dttm is not none %}
AND timestamp <= from_iso8601_timestamp('{{ to_dttm }}')
{% endif %}

Backfill rate is about 8 minutes for 1 day of data. The backfill is 90 days, which will take approx. 12 hours to backfill at this rate. The table should be fully up-to-date by Monday morning.

Thanks @mpopov!

I've updated the queries to use the new wmf_product.personal_dashboard_event_v1 dataset and applied the timestamp column optimizations suggested in T429051#12015515.

The dashboard is loading much faster now (<30 seconds) so it should keep Superset happy for the time being. I've republished and will let stakeholders know that it's safe to view again.

For a longer-term solution, I’ve created T428987 to offload these calculations to a pipeline, which we hope to prioritize for Q1.