Bruk av egendefinerte Python-funksjoner i Databricks produksjon

Å bruke Databricks gjør livet til en dataingeniør betydelig enklere. Men når du følger beste praksis for å bygge et 'enterprise' skalert datasystem, vil du uunngåelig støte på et spesifikt, komplekst problem. Denne artikkelen beskriver en løsning på problemet.

Her er de beste praksisene som gir opphav til problemet vi fokuserer på:

1. Separate miljøer og arbeidsområder for Dev og Prod.

2. Bruk Python-funksjoner for DRY (Don't Repeat Yourself) kode.

3. Automatiser byggepipelinen fra Dev til Prod.

4. Behold samme kode/notebooks på tvers av alle miljøer.

5. Hvis du bruker Databricks, bruk en Live-mappe i Workspace i stedet for i Repos for å kjøre notebooks - i det minste i produksjon.

De fire første punktene er egentlig en no-brainer. Det femte derimot, kan trenge en utdyping.

Bruk av Workspace i stedet for Repos i produksjon

Repos-området i Databricks er flott for utvikling. Det lar deg enkelt bytte mellom repo-grener. Men denne fleksibiliteten kan være en ulempe i produksjon. Hvis en mappe er satt til feil gren, kan feil notebook-versjon bli lansert. Samtidig finnes det ingen enkel måte å utløse en pull i repo-mapper etter at en pull request er fullført. Det er ett massivt problem i prod-miljøet.

Så, hva er løsningen? Den mest vanlige er å bruke en build pipeline, eksempelvis i Azure DevOps, for å kopiere filer fra main/master-branchen til en Live-mappe i både dev og prod-miljøer. Dette sikrer at du alltid har de nyeste notebooks og koden på et pålitelig sted.

Bruke funksjoner i en Databricks-repo

Når du jobber i en repo-mappe, kan det gjøres veldig enkelt å lage, importere og bruke prosjektfunksjoner. Det skyldes at:

· En __init__.py-fil i funksjon-mappen signaliserer til Python at mappen er en funksjon-pakke.

· Databricks legger automatisk til grunnstien til repo-mappen i sys.path, så funksjon-mappen enkelt kan importeres.

Dette fungerer imidlertid ikke sømløst med Live-mappen i Workspace-miljøet. Databricks legger ikke automatisk til grunnstien i sys.path her - kanskje fordi det er mindre opplagt hvor grunnstien er sammenlignet med i Repos-området. Den offisielle melding fra Databricks er at man ikke bør endre sys.path. Men hva er alternativet?

Distribuering av funksjoner til Databricks workspace

Det finnes heldigvis en løsning: Bygg og distribuer en Python Wheel-pakke ved hjelp av en build pipeline. Nedenfor er hvordan det kan gjøres med en project_functions-mappe i grunnstien til repoet ved bruk av Azure DevOps:

- checkout: databricks_repo
  fetchDepth: 0
  displayName: 'Checkout Databricks Repository'
- script: curl -V && curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh
  displayName: 'Install Databricks CLI and Dependencies'
- script: |
    echo "from setuptools import setup, find_packages" > setup.py
    echo "" >> setup.py
    echo "setup(" >> setup.py
    echo "    name='project_functions'," >> setup.py
    echo "    version='0.1'," >> setup.py
    echo "    packages=['project_functions']," >> setup.py
    echo "    package_dir={'project_functions': 'project_functions'}," >> setup.py
    echo "    package_data={'project_functions': ['*.py']}," >> setup.py
    echo ")" >> setup.py
  displayName: 'Generate setup.py'
- script: |
    echo "recursive-include project_functions *.py" > MANIFEST.in
  displayName: 'Generate MANIFEST.in'
- script: |
    python setup.py bdist_wheel
  displayName: 'Package Python Code as Wheel'
- script: |
    databricks fs cp "dist/project_functions-0.1-py3-none-any.whl" "dbfs:/Volumes/packages/default/project_functions/project_functions-0.1-py3-none-any.whl" --overwrite
    databricks fs mkdirs "dbfs:/packages/default/project_functions/"
    databricks fs cp "dist/project_functions-0.1-py3-none-any.whl" "dbfs:/packages/default/project_functions/project_functions-0.1-py3-none-any.whl" --overwrite
  displayName: 'Move Wheel Package to DBFS Volume'
 

Når du har flyttet pakken, er det enkelt å installere den i Databricks. Naviger til din cluster, klikk på "Libraries," deretter "Install new," og bruk stien der du flyttet pakken (se databricks fs cp-linjene). Merk at vi kopierte den til to forskjellige steder, da delte klynger trenger en 'volume path', mens individuelle klynger trenger en 'dbfs path'. Ikke spør hvorfor!

Du trenger ikke engang bekymre deg for om løsningen vil overstyre project_function-mappen i dev, hvis du bruker den samme klynge for testing. Databricks prioriterer de nyeste funksjonsendringene i mappene over de i pakken din.

Og det er alt! Du kan nå importere funksjoner i dit skinnende beste praksis-prosjekt i Databricks.