הקצאת משאבים

בדף הזה מוסבר איך להקצות משאבים לצינורות.

מידע על הקצאת משאבים ב-Orchestration Pipelines

צינורות עיבוד נתונים של Orchestration משתמשים בגישה של תשתית כקוד (IaC) כדי לנהלGoogle Cloud משאבים שמשמשים את צינורות עיבוד הנתונים, מה שמספק את היתרונות הבאים:

  • ניהול גרסאות. השינויים בתשתית מתועדים ב-Git.
  • אפשרות לחזור על הפעולה. אפשר ליצור מחדש סביבות באופן מהימן.
  • שיתוף פעולה. חברי הצוות יכולים לבדוק את הגדרות התשתית ולתרום להן.
  • פעולות אוטומטיות. משתלב בצינורות עיבוד נתונים של CI/CD.
  • אופציונליות ודו-קיום. מסגרת הקצאת המשאבים היא אופציונלית. אם אתם כבר משתמשים ב-Terraform או בשיטות אחרות של IaC (תשתית כקוד) כדי להקצות משאבים, אתם יכולים להמשיך לעשות זאת. אתם יכולים לנהל קבוצת משנה של משאבים שרלוונטיים לצינור עיבוד נתונים או לאפליקציה ספציפיים, ואולי הם יתקיימו במקביל למשאבים שמנוהלים על ידי כלים אחרים.

ב-Orchestration Pipelines, יכול להיות לפרויקט סביבת פריסה אחת או יותר. ההגדרה של כל סביבת פריסה מגדירה איך צינורות ומשאבים ששייכים לסביבה הזו נפרסים. לדוגמה, אפשר להגדיר סביבת פריסה אחת לפיתוח וסביבה אחרת לייצור.

דוגמה להגדרת סביבת פריסה. המשאבים שהוקצו מוגדרים במיפוי resources.

environments:
  dev:
    project: example-dev-project
    region: us-central1
    variables:
      dataset_name: marketing_analytics_dev
    secrets:
      dts_api_key: "projects/example-dev-project/secrets/dev-dts-key/versions/latest"
    resources:
      - type: dataproc.cluster
        name: example-static-cluster-resource
        definition:
          clusterName: example-static-cluster

כשפורסים את הפייפליין, Orchestration Pipelines משתמש במודל בלי שמירת מצב של 'יצירה או עדכון' כדי להקצות משאבים שהגדרתם:

  • אם משאב מוגדר אבל לא קיים, Orchestration Pipelines יוצר אותו.

  • אם המשאב קיים:

    • (ברירת מחדל) עדכון ההגדרה של המשאב כך שתתאים להגדרה.

    • אם מגדירים את ההתנהגות הזו בהגדרות של המשאב, Orchestration Pipelines יכולים להתעלם משינויים או ליצור מחדש משאב.

  • אם מוחקים את ההגדרה של משאב מההגדרה, המשאב לא יימחק. הגישה הזו נותנת עדיפות לבטיחות ומונעת אובדן נתונים מקרי.

  • אם משנים שם של משאב קיים, Orchestration Pipelines יוצר משאב חדש עם השם החדש ושומר את המשאב המקורי.

השוואה בין משאבים שהוקצו לבין פרופילי משאבים

פרופילי משאבים הם קובצי תבניות שמכילים את ההגדרה של משאבGoogle Cloud אחד או יותר. הם שונים ממשאבים שהוקצו, ואפשר להשתמש בהם יחד עם משאבים שהוקצו:

  • עם משאבים שהוקצו: במקום להגדיר את אותה הגדרת משאבים בשורה בכל סביבת פיתוח ב-deployment.yaml, אפשר להגדיר אותה פעם אחת בפרופיל ואז להפנות אליה. משאבים שהוקצו תומכים במגוון רחב של סוגי משאבים שאפשר להגדיר בפרופילים של משאבים.

  • עם פעולות בצינור: אפשר להשתמש בפרופילים של משאבים בפעולות שבהן המשאבים מוקצים למשך הפעולה. אם משתמשים בפרופיל משאב במקום לציין את הגדרת המשאב בשורה, אפשר להפריד את הגדרת המשאב מפעולת צינור עיבוד הנתונים ולעשות שימוש חוזר בהגדרה אחת לכמה פעולות של צינור עיבוד הנתונים. פעולות של צינור עיבוד נתונים תומכות בפרופילים של משאבים רק עבור משאבים של Managed Service for Apache Spark, למשל כשמבצעים פעולות של צינור עיבוד נתונים באשכול זמני.

הצגת סוגי המשאבים הזמינים

סוגי משאבים

אפשר גם לראות את כל המשאבים הזמינים ב-CLI של gcloud באמצעות הפקודה הבאה:

gcloud beta orchestration-pipelines resource-types list

הוספת משאב חדש

כדי להוסיף משאב חדש שהוקצה להגדרות של סביבת הפריסה, מוסיפים את ההגדרה שלו באופן הבא:

  1. בהגדרה של סביבת הפריסה, מוסיפים פריט חדש לרשימה environments.DEVELOPMENT_ENVIRONMENT.resources.

  2. מציינים את המקשים הבאים:

    • ‫type: סוג המשאב Google Cloud שרוצים להקצות. דוגמאות: bigquery.dataset, dataform.repository. אפשר לראות את סוגי המשאבים הזמינים באמצעות פקודה ב-CLI של gcloud.

    • ‫name: שם לוגי למשאב בקובץ deployment.yaml.

    • ‫parent: מציין משאב אב לסוגי משאבים שנדרש להם משאב אב. מזינים את name של משאב ההורה כערך.

    • ‫updateAction: מציין איזו פעולה צריך לבצע כשמזוהה שינוי בהגדרות של המשאב:

      • (ברירת מחדל) patch: עדכון המאפיינים של המשאב שהשתנו.

        פעולת העדכון משנה רק את המאפיינים שצוינו בהגדרות (YAML) של המשאב, ומשאירה את שאר המאפיינים הקיימים ללא שינוי. לדוגמה, אפשר להשתמש בהתנהגות הזו כדי לנהל רק מאפיינים שחשובים להרצת צינורות, ולהגדיר מאפיינים אחרים באופן ידני.

        אם השינויים משפיעים על שדות שלא ניתן לשנות או על משאב שלא ניתן לשנות, הפריסה נכשלת. במקרים כאלה, מומלץ לשנות את ההגדרה כך שתשנה רק שדות שניתנים לשינוי. אם זה לא אפשרי, אפשר לשנות את פעולת העדכון ל-recreate.

      • ‫skip: התעלמות מהשינויים ואי עדכון של הגדרות המשאב.

        מומלץ להשתמש באפשרות הזו כשרוצים לנהל את קיום המשאב אבל לבצע את השינויים והעדכונים בהגדרות באמצעים אחרים, למשל באופן ידני.

      • ‫recreate: אם מזוהים שינויים, המשאב הקיים נמחק ונוצר משאב חדש על סמך ההגדרה הנוכחית של המשאב.

        מומלץ להשתמש באפשרות הזו למשאבים שהם בלתי ניתנים לשינוי לחלוטין, או כשמבצעים שינויים בשדות שלא ניתן לעדכן במקום.

    • ‫definition: המפרט של המשאב, כמיפוי שמשקף את מבנה ההגדרה של המשאב ב-API של המשאב.

    • (אופציונלי) metadata: מטא-נתונים ספציפיים ל-Orchestration Pipelines. חלק מסוגי המשאבים משתמשים בשדות מטא-נתונים כדי להגדיר את המשאב ב-Google Cloud . לדוגמה, אפשר להשתמש בשדה metadata.location כדי ליצור משאבים אזוריים.

  3. מאמתים ופורסים את צינור עיבוד הנתונים. Orchestration Pipelines יקצו את המשאב החדש כשהפייפליין ייפרס.

דוגמה: משאבים שפועלים לאורך זמן

בדוגמה הזו מוצג תהליך של הוספת משאב שפועל לאורך זמן, במקרה הזה, אשכול סטטי של Managed Service for Apache Spark. אחרי ההקצאה, אפשר להשתמש בו בפעולות של צינורות. מומלץ להשתמש בגישה הכללית הזו כשמשתמשים במשאבים קבועים בצינורות העברת הנתונים.

בדוגמה הבאה מוסיפים אשכול סטטי של Managed Service for Apache Spark בשם example-static-cluster לסביבת הפריסה dev. ההגדרה של המשאב מסופקת על סמך Dataproc API.

environments:
  dev:
    project: "example-project"
    region: "us-central1"
    # A runner environment for executing pipeline actions
    composer_environment: "example-runner-environment"

    resources:
      - type: dataproc.cluster
        name: example-static-cluster
        updateAction: patch
        definition:
          config:
            masterConfig:
              numInstances: 1
              machineTypeUri: n1-standard-4
            workerConfig:
              numInstances: 3
              machineTypeUri: n1-standard-4

אפשר להשתמש באשכול הזה בפעולות של צינור עיבוד הנתונים כרגיל. אין הבדל בשימוש בהשוואה, למשל, לאשכול שנוצר באופן ידני.

modelVersion: "1.0"
pipelineId: "example-dataproc-pipeline"
...
actions:
  - pyspark:
      name: "run-pyspark-with-pyfiles-on-existing-cluster"
      engine:
        dataprocOnGce:
          existingCluster:
            clusterName: "example-static-cluster"
            location: {{ region }}
            projectId: {{ project }}
      mainFilePath: "scripts/my_spark_job_with_pyfiles.py"
      pyFiles:
        - "scripts/lib1.py"

דוגמה: תהליך אוטומטי של בנייה ושחרור ב-Dataform

בדוגמה הזו מוצג תהליך אוטומטי של בנייה ושחרור ב-Dataform. בתרחיש לדוגמה:

  1. מאגר Dataform מקושר למאגר GitHub באמצעות Developer Connect.

  2. אתם דוחפים שינויים למאגר ב-GitHub.

  3. אחרי שהשינויים מועברים, פורסים את צינור הנתונים.

  4. ‫Dataform שולף את הקוד ממאגר GitHub, יוצר תוצאת קומפילציה ומכין אותו להרצה.

  5. לאחר מכן משתמשים בהגדרת תהליך עבודה כדי להריץ תהליכי עבודה עם הגרסה הזו שקומפלה באופן אוטומטי.

בדוגמת הקוד הבאה מוגדר מאגר Dataform, הגדרת גרסה והגדרת תהליך עבודה עבורו בסביבת הפריסה dev:

  • השורה gitCommitish: "{{ COMMIT_SHA }}" מקשרת את הגדרת הגרסה ל-commit הספציפי ב-Git שנפרס. ‫COMMIT_SHA הוא משתנה שמומר ל-SHA של הקומיט של חבילת צינור הנתונים שנפרסה.
  • המפתח codeCompilationConfig.pipelineConfig.path מצביע על תיקיית משנה שמכילה נכסי צינור. כך אפשר לשמור כמה צינורות של Dataform במאגר אחד.

  • הגדרת releaseCompilationResult ל-auto בהגדרה של releaseConfig גורמת ל-Orchestration Pipelines להפעיל קומפילציה של Dataform אחרי שמשאב releaseConfig נוצר או מתעדכן עם gitCommitish החדש:

    1. המסגרת קודם מבצעת פעולת upsert (עדכון או יצירה) של משאב releaseConfig כדי להפנות אל הקומיט שצוין.
    2. לאחר מכן, בגלל ההגדרה auto, המערכת קוראת ל-Dataform API כדי ליצור תוצאת קומפילציה חדשה על סמך הקוד באותו קומיט.
    3. הערך releaseConfig מתעדכן שוב כך שיצביע על מזהה תוצאת הקומפילציה החדש שנוצר, והגרסה הזו הופכת לגרסה הפעילה.
environments:
  dev:
    project: example-project
    region: us-central1
    composer_environment: example-runner-environment
    artifact_storage:
      bucket: example-bucket
      path_prefix: initialized-artifact-bucket
    pipelines:
      - source: initialized-pipeline.yaml
      - source: dataform_local_pipeline.yaml
      - source: dataform_service_pipeline.yaml
    resources:
      - name: {{ repository_name }}
        type: dataform.repository
        definition:
          labels:
            bigquery-deployment: preview
      - type: dataform.repository.releaseConfig
        name: subfolder-release
        parent: {{ repository_name }}
        definition:
          gitCommitish: {{ COMMIT_SHA }}
          releaseCompilationResult: auto
          codeCompilationConfig:
            pipelineConfig:
              pipelineType: DATAFORM
              path: weather_dataform
      - type: dataform.repository.workflowConfig
        name: {{ workflow_config_name }}
        parent: {{ repository_name }}
        definition:
          releaseConfig: subfolder-release
          invocationConfig:
            serviceAccount: {{ service_account }}
    variables:
      service_account: example-account@example-project.iam.gserviceaccount.com
      network_uri: projects/example-project/global/networks/default
      subnetwork_uri: projects/example-project/regions/us-central1/subnetworks/default
      region: us-central1
      repository_name: weather-aggregation-repo
      workflow_config_name: updated-subfolder-workflow

דוגמה לפעולה בצינור עיבוד נתונים שמריצה תהליך עבודה עם הגדרת תהליך העבודה שנוצרה:

modelVersion: '1.0'
pipelineId: dataform_service_pipeline
description: Updated run Dataform pipeline via Dataform Service
runner: airflow
owner: data-eng-team

defaults:
  projectId: {{ project }}
  location: {{ region }}
  executionConfig:
    retries: 1

actions:
  - pipeline:
      name: run_dataform_service
      framework:
        dataform:
          dataformService:
            location: {{ region }}
            projectId: {{ project }}
            repositoryId: {{ repository_name }}
            workflowInvocation:
              workflowConfig: projects/{{ project }}/locations/{{ region }}/repositories/{{
                repository_name }}/workflowConfigs/{{ workflow_config_name }}
  - python:
      name: fibonacci_python
      mainFilePath: scripts/fibonacci.py
      pythonCallable: fibonacciTen
      engine:
        local: {}
  - sql:
      name: dummy_bq_query
      engine:
        bigquery:
          location: {{ region }}
      query:
        inline: 'SELECT COUNT(*) FROM `{{ project }}.weather_data.sensor_readings`'
tags:
  - job:datacloud:vscode