כדי לקרוא נתונים מ-Bigtable ל-Dataflow, משתמשים במחבר Bigtable I/O של Apache Beam.
מקביליות
המקביליות נשלטת על ידי מספר הצמתים באשכול Bigtable. כל צומת מנהל טווח מפתחות אחד או יותר, אבל טווחי מפתחות יכולים לעבור בין צמתים כחלק מאיזון העומסים. מידע נוסף זמין במאמר בנושא קריאות וביצועים במסמכי התיעוד של Bigtable.
החיוב מתבצע לפי מספר הצמתים באשכולות של המופע. במחירון של Bigtable תוכלו לעיין ברשימת התעריפים.
ביצועים
בטבלה הבאה מוצגים מדדי ביצועים לפעולות קריאה של Bigtable. עומסי העבודה הופעלו על e2-standard2 עובד אחד, באמצעות Apache Beam SDK 2.48.0 ל-Java. הם לא השתמשו ב-Runner v2.
| 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 סיפקה.