הפעלת משימת Dataflow בקונטיינר בהתאמה אישית

הפעלת משימות Dataflow בקונטיינרים בהתאמה אישית מאפשרת לכם להתאים אישית את סביבת זמן הריצה של ה-worker ולהתקין מראש יחסי תלות של צד שלישי. הגישה הזו עוזרת להבטיח שהצינורות יעבדו באופן עקבי בכל עומסי העבודה.

הוראות ליצירת קובץ אימג' מפורטות במאמר יצירת קובצי אימג' בהתאמה אישית של קונטיינרים ל-Dataflow. כדי למנוע שגיאות שנובעות מיחסי תלות לא תואמים כשמפעילים את הצינור, צריך להשתמש בגרסת Apache Beam SDK ובגרסת שפה שתואמות ל-SDK בקובץ האימג' של הקונטיינר בהתאמה אישית.

בדיקה מקומית

לפני שמריצים את צינור עיבוד הנתונים ב-Dataflow, כדאי לבדוק את קובץ האימג' של הקונטיינר באופן מקומי, כדי לבצע בדיקות וניפוי באגים במהירות רבה יותר.

למידע נוסף על שימוש ספציפי ב-Apache Beam, קראו את המדריך של Apache Beam בנושא הרצת צינורות עיבוד נתונים עם קובצי אימג' של קונטיינרים בהתאמה אישית.

בדיקה בסיסית באמצעות PortableRunner

כדי לוודא שאפשר לשלוף קובצי אימג' של קונטיינרים מרוחקים ולהריץ צינור עיבוד נתונים בסיסי, משתמשים ב-Apache Beam PortableRunner. כשמשתמשים ב-PortableRunner, שליחת המשימה מתרחשת בסביבה המקומית, וההרצה של DoFn מתרחשת בסביבת Docker.

כשמשתמשים במעבדי GPU, יכול להיות שלקונטיינר של Docker לא תהיה גישה למעבדי ה-GPU. כדי לבדוק את הקונטיינר עם יחידות GPU, משתמשים ב-direct runner ופועלים לפי השלבים לבדיקת קובץ אימג' של קונטיינר במכונה וירטואלית עצמאית עם יחידות GPU, שמפורטים בקטע ניפוי באגים באמצעות מכונה וירטואלית עצמאית בדף "שימוש ביחידות GPU".

הקוד הבא מריץ צינור עיבוד נתונים לדוגמה:

Java

mvn compile exec:java -Dexec.mainClass=com.example.package.MyClassWithMain \
    -Dexec.args="--runner=PortableRunner \
    --jobEndpoint=REGION \
    --defaultEnvironmentType=DOCKER \
    --defaultEnvironmentConfig=IMAGE_URI \
    --inputFile=INPUT_FILE \
    --output=OUTPUT_FILE"

Python

python path/to/my/pipeline.py \
  --runner=PortableRunner \
  --job_endpoint=REGION \
  --environment_type=DOCKER \
  --environment_config=IMAGE_URI \
  --input=INPUT_FILE \
  --output=OUTPUT_FILE

המשך

go path/to/my/pipeline.go \
  --runner=PortableRunner \
  --job_endpoint=REGION \
  --environment_type=DOCKER \
  --environment_config=IMAGE_URI \
  --input=INPUT_FILE \
  --output=OUTPUT_FILE

מחליפים את מה שכתוב בשדות הבאים:

• ‫REGION: האזור של שירות המשימות שבו רוצים להשתמש, בפורמט של כתובת ויציאה. לדוגמה: localhost:3000. משתמשים ב-embed כדי להריץ שירות משימות בתהליך.
• ‫IMAGE_URI: ה-URI של קובץ האימג' של הקונטיינר בהתאמה אישית.
• ‫INPUT_FILE: קובץ קלט שאפשר לקרוא כקובץ טקסט. הקובץ הזה צריך להיות נגיש ל-SDK harness
  של קובץ האימג' של הקונטיינר, או שהוא צריך להיות קובץ מרוחק או קובץ שנטען מראש בקובץ האימג' של הקונטיינר.
• ‫OUTPUT_FILE: הנתיב שבו הפלט ייכתב. הנתיב הזה הוא נתיב מרוחק או נתיב מקומי בקונטיינר.

כשהתהליך מסתיים, בודקים ביומני המסוף שהתהליך הסתיים בהצלחה ושהמערכת משתמשת בתמונה המרוחקת שצוינה על ידי IMAGE_URI.

אחרי הרצת הצינור, הקבצים שנשמרו בקונטיינר לא נמצאים במערכת הקבצים המקומית, והקונטיינר נעצר. אפשר להעתיק קבצים ממערכת הקבצים של הקונטיינר שהופסק באמצעות docker cp.

לחלופין:

• לספק פלט למערכת קבצים מרוחקת כמו Cloud Storage. יכול להיות שתצטרכו להגדיר ידנית את הגישה למטרות בדיקה, כולל לקובצי פרטי כניסה או לApplication Default Credentials.
• כדי לנפות באגים במהירות, מוסיפים רישום ביומן זמני.

שימוש ב-Direct Runner

כדי לבצע בדיקה מקומית מעמיקה יותר של קובץ האימג' של הקונטיינר ושל צינור עיבוד הנתונים, השתמשו ב-Direct Runner של Apache Beam.

אתם יכולים לאמת את צינור עיבוד הנתונים בנפרד מהקונטיינר, על ידי בדיקה בסביבה מקומית שתואמת לקובץ האימג' של הקונטיינר, או על ידי הפעלת צינור עיבוד הנתונים בקונטיינר פועל.

Java

docker run -it --entrypoint "/bin/bash" IMAGE_URI
...
# On docker container:
root@4f041a451ef3:/#  mvn compile exec:java -Dexec.mainClass=com.example.package.MyClassWithMain ...

Python

docker run -it --entrypoint "/bin/bash" IMAGE_URI
...
# On docker container:
root@4f041a451ef3:/#  python path/to/my/pipeline.py ...

המשך

docker run -it --entrypoint "/bin/bash" IMAGE_URI
...
# On docker container:
root@4f041a451ef3:/#  go path/to/my/pipeline.go ...

מחליפים את IMAGE_URI ב-URI של קובץ האימג' של הקונטיינר בהתאמה אישית.

בדוגמאות האלה, ההנחה היא שכל קובצי הצינור, כולל הצינור עצמו, נמצאים בקונטיינר בהתאמה אישית, הועלו ממערכת קבצים מקומית או שהם מרוחקים ונגישים ל-Apache Beam ולקונטיינר. לדוגמה, כדי להשתמש ב-Maven‏ (mvn) להרצת הדוגמה הקודמת ב-Java, צריך להעביר את Maven ואת יחסי התלות שלו לקונטיינר. למידע נוסף, קראו את המאמרים Storage ו-docker run במסמכי התיעוד של Docker.

מטרת הבדיקה ב-Direct Runner היא לבדוק את צינור עיבוד הנתונים בסביבת הקונטיינר בהתאמה אישית, ולא לבדוק את הפעלת הקונטיינר עם ברירת המחדל של ENTRYPOINT. משנים את ENTRYPOINT (לדוגמה, docker run --entrypoint ...) כדי להריץ ישירות את צינור עיבוד הנתונים או כדי לאפשר הרצה ידנית של פקודות בקונטיינר.

אם אתם מסתמכים על הגדרה ספציפית שמבוססת על הפעלת הקונטיינר ב-Compute Engine, אתם יכולים להפעיל את הקונטיינר ישירות במכונה וירטואלית של Compute Engine. איך משתמשים בקונטיינרים ב-Compute Engine?

הפעלת המשימה ב-Dataflow

כשמפעילים את צינור עיבוד הנתונים של Apache Beam ב-Dataflow, צריך לציין את הנתיב לקובץ האימג' של הקונטיינר. אל תשתמשו בתג :latest עם תמונות בהתאמה אישית. תייגו את הגרסאות שלכם עם תאריך או מזהה ייחודי. אם משהו משתבש, השימוש בסוג הזה של תג יכול לאפשר להחזיר את הפעלת צינור עיבוד הנתונים להגדרה קודמת שידועה כפועלת, ולבדוק את השינויים.

Java

משתמשים ב---sdkContainerImage כדי לציין קובץ אימג' של קונטיינר SDK לסביבת זמן הריצה של Java.

כדי להפעיל את Portable Runner, משתמשים בניסוי הבא בהתאם לגרסת ה-SDK:

• ‫Apache Beam SDK בגרסה 2.74 ואילך: --experiments=enable_portable_runner.
• ‫Apache Beam SDK בגרסה 2.73 או גרסה קודמת: --experiments=use_runner_v2.

Python

אם משתמשים ב-SDK בגרסה 2.30.0 ואילך, משתמשים באפשרות צינור העיבוד הנתונים --sdk_container_image כדי לציין קובץ אימג' של קונטיינר SDK.

בגרסאות קודמות של ה-SDK, משתמשים באפשרות הצינור --worker_harness_container_image כדי לציין את המיקום של קובץ האימג' של הקונטיינר שבו רוצים להשתמש עבור רתמת ה-worker.

אפשר להשתמש בקונטיינרים בהתאמה אישית רק ב-Dataflow Portable Runner. אם אתם מפעילים צינור עיבוד נתונים באצווה ב-Python, הגדירו את דגל הניסוי בהתאם לגרסת ה-SDK:

• ‫Apache Beam SDK בגרסה 2.74 ואילך: --experiments=enable_portable_runner.
• ‫Apache Beam SDK בגרסה 2.73 או גרסאות קודמות: --experiments=use_runner_v2.

אם אתם מפעילים צינור עיבוד נתונים בסטרימינג ב-Python, אין צורך לציין את הניסוי כי צינורות עיבוד נתונים בסטרימינג ב-Python משתמשים ב-Portable Runner כברירת מחדל.

המשך

אם משתמשים ב-SDK בגרסה 2.40.0 ואילך, משתמשים באפשרות צינור העיבוד --sdk_container_image כדי לציין קובץ אימג' של קונטיינר SDK.

בגרסאות קודמות של ה-SDK, משתמשים באפשרות הצינור --worker_harness_container_image כדי לציין את המיקום של קובץ האימג' של הקונטיינר שבו רוצים להשתמש עבור רתמת ה-worker.

אפשר להשתמש בקונטיינרים בהתאמה אישית בכל הגרסאות של Go SDK, כי כברירת מחדל הן משתמשות ב-Dataflow Portable Runner.

בדוגמה הבאה מוסבר איך להפעיל את הדוגמה של WordCount באצווה עם קונטיינר בהתאמה אישית.

Java

הערה: אם אתם משתמשים ב-Apache Beam SDK מגרסה 2.74 ואילך, השתמשו בדגל המעודכן --experiments=enable_portable_runner כדי להפעיל את Portable Runner.

mvn -Pdataflow-runner compile exec:java \
    -Dexec.mainClass=org.apache.beam.examples.WordCount \
    -Dexec.args="--runner=DataflowRunner \
                 --inputFile=INPUT_FILE \
                 --output=OUTPUT_FILE \
                 --project=PROJECT_ID \
                 --region=REGION \
                 --gcpTempLocation=TEMP_LOCATION \
                 --diskSizeGb=DISK_SIZE_GB \
                 --experiments=use_runner_v2 \
                 --sdkContainerImage=IMAGE_URI"

Python

הערה: אם אתם משתמשים ב-Apache Beam SDK מגרסה 2.74 ואילך, השתמשו בדגל המעודכן --experiments=enable_portable_runner כדי להפעיל את Portable Runner.

שימוש ב-Apache Beam SDK ל-Python בגרסה 2.30.0 ואילך:

python -m apache_beam.examples.wordcount \
  --input=INPUT_FILE \
  --output=OUTPUT_FILE \
  --project=PROJECT_ID \
  --region=REGION \
  --temp_location=TEMP_LOCATION \
  --runner=DataflowRunner \
  --disk_size_gb=DISK_SIZE_GB \
  --experiments=use_runner_v2 \
  --sdk_container_image=IMAGE_URI

המשך

wordcount --input gs://dataflow-samples/shakespeare/kinglear.txt \
          --output gs://<your-gcs-bucket>/counts \
          --runner dataflow \
          --project your-gcp-project \
          --region your-gcp-region \
          --temp_location gs://<your-gcs-bucket>/tmp/ \
          --staging_location gs://<your-gcs-bucket>/binaries/ \
          --sdk_container_image=IMAGE_URI

מחליפים את מה שכתוב בשדות הבאים:

• ‫INPUT_FILE: נתיב הקלט של Cloud Storage שנקרא על ידי Dataflow בזמן הרצת הדוגמה.
• ‫OUTPUT_FILE: נתיב הפלט של Cloud Storage שצינור עיבוד הנתונים לדוגמה כותב אליו. הקובץ הזה מכיל את ספירת המילים.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud.
• ‫REGION: האזור שבו פורסים את משימת Dataflow.
• ‫TEMP_LOCATION: הנתיב ב-Cloud Storage שבו Dataflow יאחסן קובצי משימות זמניים שנוצרו במהלך הרצת צינור עיבוד הנתונים.
• ‫DISK_SIZE_GB: אופציונלי. אם הקונטיינר גדול, כדאי להגדיל את גודל דיסק האתחול שמוגדר כברירת מחדל כדי למנוע מחסור במקום בדיסק.
• ‫IMAGE_URI: ה-URI של קובץ האימג' של הקונטיינר בהתאמה אישית של ה-SDK. תמיד צריך להשתמש ב-SHA או בתג של מאגר עם גרסה. אל תשתמשו בתג :latest או בתג שניתן לשינוי.

סטרימינג של קובצי אימג' של קונטיינרים

כדי לשפר את זמן האחזור של ההפעלה וההתאמה לעומס (autoscaling) של צינור עיבוד הנתונים ב-Dataflow, אפשר להפעיל סטרימינג של קובצי אימג'. התכונה הזו שימושית אם הקונטיינר בהתאמה אישית מכיל תוכן מיותר, או אם לא משתמשים בכל התוכן שלו בכל שלב. לדוגמה, יכול להיות שהקונטיינר יכיל תוכן מקרי, כמו קוד ספרייה מבוסס-מעבד (CPU) להסקת מסקנות מבוססת-GPU. באופן דומה, יכול להיות שיש לכם קונטיינר שמריץ פייפליינים של ML עם כמה מודלים, שמשתמשים רק במודל אחד בכל שלב, כך שאין צורך בכל התוכן שלו בבת אחת. הפעלת סטרימינג של תמונות תעזור לשפר את זמן האחזור במקרים כאלה.

Java

--dataflowServiceOptions=enable_image_streaming

Python

--dataflow_service_options=enable_image_streaming

המשך

--dataflow_service_options=enable_image_streaming

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

כדי ליהנות מהיתרונות של סטרימינג של קובצי אימג', צריך להפעיל את Container File System API.