כדי לקרוא נתונים מ-Bigtable ל-Dataflow, משתמשים במחבר Bigtable I/O של Apache Beam.
מקביליות
המקביליות נשלטת על ידי מספר הצמתים באשכול Bigtable. כל צומת מנהל טווח מפתחות אחד או יותר, אבל טווחי מפתחות יכולים לעבור בין צמתים כחלק מאיזון העומסים. מידע נוסף זמין במאמר בנושא קריאות וביצועים במסמכי התיעוד של Bigtable.
החיוב מתבצע לפי מספר הצמתים באשכולות של המופע. במחירון של Bigtable תוכלו לעיין ברשימת התעריפים.
ביצועים
בטבלה הבאה מוצגים מדדי ביצועים לפעולות קריאה של Bigtable. עומסי העבודה הופעלו על e2-standard2 עובד אחד, באמצעות Apache Beam SDK 2.48.0 ל-Java. הם לא השתמשו ב-Portable Runner.
| 100 מיליון רשומות | 1KB | עמודה אחת | תפוקה (בייטים) | תפוקה (אלמנטים) |
|---|---|---|
| קריאה | 180 MBps | 170,000 רכיבים בשנייה |
המדדים האלה מבוססים על צינורות פשוטים של עיבוד נתונים באצווה. הם נועדו להשוות בין הביצועים של מחברי קלט/פלט, ולא בהכרח מייצגים צינורות נתונים בעולם האמיתי. הביצועים של צינורות Dataflow הם מורכבים, והם תלויים בסוג המכונה הווירטואלית, בנתונים שעוברים עיבוד, בביצועים של מקורות ויעדים חיצוניים ובקוד המשתמש. המדדים מבוססים על הפעלת Java SDK, והם לא מייצגים את מאפייני הביצועים של ערכות SDK בשפות אחרות. מידע נוסף זמין במאמר בנושא ביצועים של Beam IO.
שיטות מומלצות
בצינורות חדשים, משתמשים במחבר
BigtableIOולא במחברCloudBigtableIO.ליצור פרופילים נפרדים של אפליקציות לכל סוג של צינור עיבוד נתונים. פרופילים של אפליקציות מאפשרים לקבל מדדים טובים יותר להבחנה בין תנועת גולשים בצינורות שונים, גם לצורך תמיכה וגם לצורך מעקב אחר השימוש.
מעקב אחרי צמתי Bigtable. אם אתם נתקלים בצווארי בקבוק בביצועים, כדאי לבדוק אם יש מגבלות על משאבים כמו ניצול המעבד (CPU) ב-Bigtable. מידע נוסף זמין במאמר בנושא מעקב.
באופן כללי, ערכי הזמן הקצוב לתפוגה שמוגדרים כברירת מחדל מתאימים לרוב צינורות עיבוד הנתונים. אם נראה שצינור הנתונים של הסטרימינג נתקע בזמן קריאה מ-Bigtable, נסו להתקשר אל
withAttemptTimeoutכדי לשנות את הזמן הקצוב לתפוגה של הניסיון.מומלץ להפעיל שינוי גודל אוטומטי ב-Bigtable, או לשנות את הגודל של אשכול Bigtable כדי להתאים אותו לגודל של משימות Dataflow.
כדאי להגדיר את
maxNumWorkersבמשימת Dataflow כדי להגביל את העומס על אשכול Bigtable.אם מתבצע עיבוד משמעותי של רכיב Bigtable לפני ערבוב, יכול להיות שייווצר פסק זמן בקריאות ל-Bigtable. במקרה כזה, אפשר להתקשר אל
withMaxBufferElementCountכדי להוסיף מאגר זמני לרכיבים. השיטה הזו ממירה את פעולת הקריאה מסטרימינג להחלפה לדפים, וכך נמנעת הבעיה.אם אתם משתמשים באותו אשכול Bigtable גם לצינורות של סטרימינג וגם לצינורות של עיבוד באצווה, והביצועים בצד של Bigtable יורדים, כדאי להגדיר שכפול באשכול. לאחר מכן מפרידים בין צינורות העיבוד של הפריטים המרובים ושל הנתונים בזמן אמת, כך שהם יקראו מתוך רפליקות שונות. מידע נוסף זמין במאמר סקירה כללית על רפליקציה.
המאמרים הבאים
- קוראים את מסמכי התיעוד בנושא מחבר Bigtable I/O.
- כאן אפשר לעיין ברשימת התבניות ש-Google סיפקה.