FERC EQR Data Builds#
The FERC EQR ETL uses a very similar setup for running remote cloud builds as the Nightly Data Builds, however these builds do not currently run on an automated schedule, and must be started manually. Like the nightly builds, FERC EQR builds use a GitHub action to kick off a Google Batch job, which will execute the ETL using the same Docker container as the nightly builds.
Notable differences from nightly builds#
While the FERC EQR builds use much of the same infrastructure as nightly builds, there
are a few notable differences. First, the data distribution is all done in Python using
Dagster tooling. More information on how this works can be found in
pudl.dagster.assets.deploy.ferceqr together with the supporting resources in
pudl.dagster.resources and sensor in pudl.dagster.sensors. One other major
difference from the nightly builds is where data will be published. Due to the large
size of the FERC EQR dataset, we do not maintain multiple versions of the data in S3,
and instead have just one version, which will be overwritten each time a build is
executed successfully. This version can be found at s3://pudl.catalyst.coop/ferceqr.
Before anything is published, the deploy_ferceqr asset runs the dbt data
validations for the FERC EQR tables (see Data validation quickstart). If any
fail, nothing is deployed and the build is reported as failed. The
ferceqr_datapackage asset writes the Frictionless datapackage.json describing
the outputs, which is published next to the data at
s3://pudl.catalyst.coop/ferceqr/datapackage.json.
Each quarterly input archive is also verified against the md5 checksum recorded in the
FERC EQR metadata archived on Zenodo before it is extracted. Extracting every quarter
downloads ~100 GB, so reading from remote storage must be enabled explicitly with
PUDL_FERCEQR_ALLOW_DOWNLOADS=true, which the build workflow sets.
The EQR extraction and transformation are implemented in DuckDB rather than pandas, so unlike the nightly build this pipeline is limited more by CPU parallelism than by memory. Its Batch VM is sized accordingly, with proportionally more CPU and less RAM than the nightly build VM.