קריאה מ-Bigtable אל Dataflow

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

כדי ליצור צינורות עיבוד נתונים בהתאמה אישית, אתם יכולים להשתמש ב-מחבר הקלט/פלט של Bigtable ב-Apache Beam. למשימות נפוצות כמו ייצוא טבלאות ל-Cloud Storage, אתם יכולים גם להשתמש בתבניות Dataflow ש-Google מספקת כדי לפרוס צינורות עיבוד נתונים מוכנים מראש בלי לכתוב קוד בהתאמה אישית.

מקביליות

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

החיוב הוא על מספר הצמתים באשכולות של המכונה. למחירון של Bigtable

ביצועים

בטבלה הבאה מוצגים מדדי הביצועים של פעולות קריאה ב-Bigtable. עומסי העבודה הופעלו ב-worker אחד של e2-standard2, באמצעות Apache Beam SDK 2.48.0 ל-Java. הם לא השתמשו ב-Portable Runner.

‫100 מיליון רשומות | 1KB | עמודה אחת תפוקה (בייטים) תפוקה (רכיבים)
קריאה ‫180MB לשנייה ‫170,000 רכיבים לשנייה

המדדים האלה מבוססים על צינורות עיבוד נתונים פשוטים של אצווה. הם נועדו להשוות בין הביצועים של מחברי קלט/פלט, ולא בהכרח מייצגים צינורות עיבוד נתונים בעולם האמיתי. הביצועים של צינור עיבוד הנתונים ב-Dataflow הם מורכבים, והם פונקציה של סוג ה-VM, הנתונים שעוברים עיבוד, הביצועים של מקורות וכיורים חיצוניים וקוד המשתמש. המדדים מבוססים על הפעלת Java SDK, והם לא מייצגים את מאפייני הביצועים של ערכות SDK בשפות אחרות. מידע נוסף זמין במאמר ביצועי קלט/פלט של Beam.

שיטות מומלצות

  • בצינורות עיבוד נתונים חדשים, השתמשו במחבר BigtableIO ולא ב-CloudBigtableIO.

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

  • עוקבים אחרי הצמתים של Bigtable. אם אתם נתקלים בצווארי בקבוק בביצועים, בדקו אם משאבים כמו ניצול המעבד (CPU) מוגבלים ב-Bigtable. מידע נוסף על מעקב

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

  • כדאי להפעיל את ההתאמה האוטומטית לעומס (autoscaling) ב-Bigtable, או לשנות את הגודל של אשכול Bigtable כך שיתאים לגודל של משימות Dataflow.

  • כדאי להגדיר את maxNumWorkers במשימת Dataflow כדי להגביל את העומס על אשכול Bigtable.

  • אם מתבצע עיבוד משמעותי של רכיב Bigtable לפני ערבוב, יכול להיות שתוקצב הזמן הקצוב לתפוגה של הקריאות ל-Bigtable. במקרה כזה, אפשר להפעיל את withMaxBufferElementCount כדי להוסיף רכיבים למאגר הנתונים הזמני. השיטה הזו ממירה את פעולת הקריאה מסטרימינג לדפים, וכך נמנעת הבעיה.

  • אם אתם משתמשים באשכול Bigtable אחד גם לצינורות עיבוד נתונים בסטרימינג וגם לצינורות עיבוד נתונים באצווה, והביצועים בצד של Bigtable יורדים, כדאי להגדיר רפליקציה באשכול. לאחר מכן, מפרידים בין הפייפליינים של ה-batch והפייפליין הזורם, כדי שהם יקראו מרפליקות שונות. מידע נוסף מופיע במאמר סקירה כללית על רפליקציה.

המאמרים הבאים