ETL jobs for Firefox Telemetry
Перейти к файлу
kik-kik fc08b48b8b
Merge pull request #403 from mozilla/bug/1914369/remove-GRAPHICS_SANITY_TEST-from-graphics-dashboard-code
bug(1914369): remove GRAPHICS_SANITY_TEST* related code from graphics dashboard due to related deprecation in gecko-dev
2024-09-09 20:43:47 +02:00
.circleci bubmped up docker image used for ci steps 2023-07-11 12:17:25 +02:00
bin Port bhr collection from databricks (#356) 2020-12-17 18:01:18 -05:00
docs sphinx and m2r extension changed to m2r2 due to no support 2022-01-11 17:50:13 +01:00
mozetl Set content encoding for gcs objects (#402) 2024-09-06 10:58:16 +02:00
scheduling Bug 1589118 - Remove tab spinner job (#344) 2019-10-30 10:12:50 -04:00
tests Update dependencies to fix ci (#354) 2020-12-16 11:51:45 -05:00
.gitignore Added tests around taar-lite 2018-04-09 09:42:40 -07:00
CODE_OF_CONDUCT.md Add Mozilla Code of Conduct file (#325) 2019-04-10 12:19:19 -04:00
LICENSE Build boilerplate from cookiecutter-python-etl 2017-03-15 15:14:05 -04:00
MANIFEST.in Fixes #22 - Add static files to setup.py 2017-05-04 17:22:40 -04:00
README.md Change default branch to main (#355) 2020-12-17 11:26:35 -05:00
setup.py DENG-1025: gfx_telemetry r/w to GCS instead of S3 2023-08-10 10:39:03 -04:00
tox.ini because nothing ever is easy in life 2022-01-11 17:56:23 +01:00

README.md

Firefox Telemetry Python ETL

CircleCI codecov

This repository is a collection of ETL jobs for Firefox Telemetry.

Benefits

Jobs committed to python_mozetl can be scheduled via airflow or ATMO. We provide a testing suite and code review, which makes your job more maintainable. Centralizing our jobs in one repository allows for code reuse and easier collaboration.

There are a host of benefits to moving your analysis out of a Jupyter notebook and into a python package. For more on this see the writeup at cookiecutter-python-etl.

Tests

Dependencies

First install the necessary runtime dependencies -- snappy and the java runtime environment. These are used for the pyspark package. In ubuntu:

$ sudo apt-get install libsnappy-dev openjdk-8-jre-headless

Calling the test runner

Run tests by calling tox in the root directory.

Arguments to pytest can be passed through tox using --.

tox -- -k test_main.py # runs tests only in the test_main module

Tests are configured in tox.ini

Manual Execution

ATMO

The first method of manual execution is the mozetl-submit.sh script located in bin. This script is used with the EMRSparkOperator in telemetry-airflow to schedule execution of mozetl jobs. It may be used with ATMO to manually test jobs.

In an SSH session with an ATMO cluster, grab a copy of the script:

$ wget https://raw.githubusercontent.com/mozilla/python_mozetl/main/bin/mozetl-submit.sh

Push your code to your own fork, where the job has been added to mozetl.cli. Then run it.

$ ./mozetl-submit.sh \
    -p https://github.com/<USERNAME>/python_mozetl.git \
    -b <BRANCHNAME> \
    <COMMAND> \
        --first-argument foo \
        --second-argument bar

See comments in bin/mozetl-submit.sh for more details.

Databricks

Jobs may also be executed on Databricks. They are scheduled via the MozDatabricksSubmitRunOperator in telemetry-airflow.

This script runs on your local machine and submits the job to a remote spark executor. First, generate an API token in the User Settings page in Databricks. Then run the script.

python bin/mozetl-databricks.py \
    --git-path https://github.com/<USERNAME>/python_mozetl.git \
    --git-branch <BRANCHNAME> \
    --token <TOKEN>  \
    <COMMAND> \
        --first-argument foo \
        --second-argument bar

Run python bin/mozetl-databricks.py --help for more options, including increasing the number of workers and using python 3. Refer to this pull request for more examples.

It is also possible to use this script for external mozetl-compatible modules by setting the --git-path and --module-name options appropriately. See this pull request for more information about building a mozetl-compatible repository that can be scheduled on Databricks.

Scheduling

You can schedule your job on either ATMO or airflow.

Scheduling a job on ATMO is easy and does not require review, but is less maintainable. Use ATMO to schedule jobs you are still prototyping or jobs that have a limited lifespan.

Jobs scheduled on Airflow will be more robust.

  • Airflow will automatically retry your job in the event of a failure.
  • You can also alert other members of your team when jobs fail, while ATMO will only send an email to the job owner.
  • If your job depends on other datasets, you can identify these dependencies in Airflow. This is useful if an upstream job fails.

ATMO

To schedule a job on ATMO, take a look at the load_and_run notebook. This notebook clones and installs the python_mozetl package. You can then run your job from the notebook.

Airflow

To schedule a job on Airflow, you'll need to add a new Operator to the DAGs and provide a shell script for running your job. Take a look at this example shell script. and this example Operator for templates.

Early Stage ETL Jobs

We usually require tests before accepting new ETL jobs. If you're still prototyping your job, but you'd like to move your code out of a Jupyter notebook take a look at cookiecutter-python-etl.

This tool will initialize a new repository with all of the necessary boilerplate for testing and packaging. In fact, this project was created with cookiecutter-python-etl.