Page MenuHomePhabricator

SPIKE: understand our options for a data retention policy for the data pipeline
Open, Stalled, Needs TriagePublic

Description

We need to periodically remove data stored in HDFS and PVC by data_reload_dag pipeline.

A pattern adopted is airflow-dag is to use a daily companion dag that drops data older than a certain threshold (based on the dataset partitions).

An example for wdqs v1 is available at https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags/-/blob/main/search/dags/drop_old_data_daily.py?ref_type=heads#L92.

However, this dag relies on data deletion helper function from the refinery repo that we found out are not compatible with the partition scheme used in WDQS hdfs datasets.
For details: T431438: discovery.wikibase_rdf_subgraphs (/wmf/data/discovery/wikidata/rdf_subgraphs) is using 34Tb and is not properly cleaned up

We need to review existing approaches and validate if they would work for our use case, and if not find alternatives.

Things to explore:

  • Adapting the existing cleanup to work with our non-Iceberg tables
  • Writing our own data cleanup (probably not advisable)
  • Upgrading our tables to Iceberg (probably hard because of the necessary spark version bumps)
  • ...

AC

  • Recommendation for data retention plan
  • phab filed to track it

Event Timeline

trueg changed the task status from Open to Stalled.Sep 2 2026, 2:33 PM
lerickson renamed this task from [NEEDS GROOMING] implement a data retention policy for the data pipeline to SPIKE: understand our options for a data retention policy for the data pipeline.Wed, Sep 16, 2:11 PM
lerickson updated the task description. (Show Details)

IMO best approach would be to use an Iceberg table, and make it as easy as DELETE FROM ... WHERE ... to purge data.
I don't think you'd need to upgrade you job spark version in order to benefir from using an iceberg table, but in case, you could also upgrade your code to use spark 3.5 and Iceberg 1.6.
This setup is already present on the cluster (replace spark3-submit by spark35-submit) for you to test, and this is also already used in production (see https://github.com/wikimedia/analytics-refinery-source/tree/master/refinery-job-35 for our dedicated module).
Let me know if I'm not making sense :)