העברת נתונים מ-HBase ל-Bigtable במצב אופליין

בדף הזה מתוארים השיקולים והתהליכים להעברת נתונים מאשכול Apache HBase למכונה של Bigtable ב-Cloud de Confiance by S3NS.

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

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

שיקולים לפני ההעברה

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

ביצועים

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

עיצוב סכימה של Bigtable

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

אימות והרשאה

לפני שמתכננים את בקרת הגישה ל-Bigtable, כדאי לבדוק את תהליכי האימות וההרשאה הקיימים ב-HBase.

ב-Bigtable משתמשים במנגנוני האימות הרגילים של Cloud de Confianceובממשק לניהול זהויות והרשאות גישה (IAM) כדי לספק בקרת גישה, כך שאתם ממירים את ההרשאות הקיימות ב-HBase ל-IAM. אתם יכולים למפות את קבוצות Hadoop הקיימות שמספקות מנגנוני בקרת גישה ל-HBase לחשבונות שירות שונים.

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

דרישה לגבי זמן השבתה

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

העברת HBase ל-Bigtable

כדי להעביר את הנתונים מ-HBase ל-Bigtable, מייצאים ל-Cloud Storage תמונת מצב של HBase לכל טבלה, ואז מייבאים את הנתונים ל-Bigtable. השלבים האלה מיועדים לאשכול HBase יחיד, והם מתוארים בפירוט בכמה מהקטעים הבאים.

  1. מפסיקים לשלוח פעולות כתיבה לאשכול HBase.
  2. יוצרים תמונות מצב של הטבלאות באשכול HBase.
  3. מייצאים את קובצי הסנאפשוט ל-Cloud Storage.
  4. מחשבים את ערכי ה-hash ומייצאים אותם ל-Cloud Storage.
  5. יוצרים טבלאות יעד ב-Bigtable.
  6. מייבאים את נתוני HBase מ-Cloud Storage ל-Bigtable.
  7. מאמתים את הנתונים שיובאו.
  8. המסלול כותב ל-Bigtable.

לפני שמתחילים

  1. יוצרים קטגוריה של Cloud Storage כדי לאחסן את קובצי ה-snapshot. יוצרים את הקטגוריה באותו מיקום שבו מתכננים להריץ את משימת Dataflow.

  2. יוצרים מכונה של Bigtable כדי לאחסן את הטבלאות החדשות.

  3. מזהים את אשכול Hadoop שמייצאים. אתם יכולים להריץ את המשימות של ההעברה ישירות באשכול HBase או באשכול Hadoop נפרד, שיש לו קישוריות רשת ל-Namenode ול-Datanodes של אשכול HBase.

  4. מתקינים ומגדירים את חיבור ל-Cloud Storage בכל צומת באשכול Hadoop, וגם במארח שממנו מתחילה המשימה. לשלבי התקנה מפורטים, ראו התקנת חיבור ל-Cloud Storage.

  5. פותחים מעטפת פקודה במארח שיכול להתחבר לאשכול HBase ולפרויקט Bigtable. כאן תבצעו את השלבים הבאים.

  6. כדי להוריד את הכלי לתרגום סכימות:

    wget BIGTABLE_HBASE_TOOLS_URL
    

    מחליפים את BIGTABLE_HBASE_TOOLS_URL בכתובת ה-URL של הגרסה האחרונה של JAR with dependencies שזמינה במאגר Maven של הכלי. שם הקובץ דומה ל-https://repo1.maven.org/maven2/com/google/cloud/bigtable/bigtable-hbase-1.x-tools/2.20.2/bigtable-hbase-1.x-tools-2.20.2-jar-with-dependencies.jar.

    כדי למצוא את כתובת ה-URL או להוריד את קובץ ה-JAR באופן ידני:

    1. למאגר
    2. לוחצים על מספר הגרסה העדכנית ביותר.
    3. מזהים את JAR with dependencies file (בדרך כלל בחלק העליון).
    4. לוחצים לחיצה ימנית ומעתיקים את כתובת ה-URL, או לוחצים כדי להוריד את הקובץ.
  7. איך מורידים את כלי הייבוא:

    wget BIGTABLE_BEAM_IMPORT_URL
    

    מחליפים את BIGTABLE_BEAM_IMPORT_URL בכתובת ה-URL של הגרסה האחרונה של shaded JAR שזמינה במאגר Maven של הכלי. שם הקובץ דומה ל-https://repo1.maven.org/maven2/com/google/cloud/bigtable/bigtable-beam-import/2.20.2/bigtable-beam-import-2.20.2-shaded.jar.

    כדי למצוא את כתובת ה-URL או להוריד את קובץ ה-JAR באופן ידני:

    1. למאגר
    2. לוחצים על מספר הגרסה העדכנית ביותר.
    3. לוחצים על הורדות.
    4. מעבירים את העכבר מעל shaded.jar.
    5. לוחצים לחיצה ימנית ומעתיקים את כתובת ה-URL, או לוחצים כדי להוריד את הקובץ.
  8. מגדירים את משתני הסביבה הבאים:

    #Google Cloud
    
    export PROJECT_ID=PROJECT_ID
    export INSTANCE_ID=INSTANCE_ID
    export REGION=REGION
    export CLUSTER_NUM_NODES=CLUSTER_NUM_NODES
    
    #JAR files
    
    export TRANSLATE_JAR=TRANSLATE_JAR
    export IMPORT_JAR=IMPORT_JAR
    
    #Cloud Storage
    
    export BUCKET_NAME="gs://BUCKET_NAME"
    export MIGRATION_DESTINATION_DIRECTORY="$BUCKET_NAME/hbase-migration-snap"
    
    #HBase
    
    export ZOOKEEPER_QUORUM=ZOOKEPER_QUORUM
    export ZOOKEEPER_PORT=2181
    export ZOOKEEPER_QUORUM_AND_PORT="$ZOOKEEPER_QUORUM:$ZOOKEEPER_PORT"
    export MIGRATION_SOURCE_DIRECTORY=MIGRATION_SOURCE_DIRECTORY
    

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

    • ‫PROJECT_ID: הפרויקט ב- Cloud de Confiance שבו נמצא המכונה
    • ‫INSTANCE_ID: המזהה של מכונת Bigtable שאליה מייבאים את הנתונים
    • ‫REGION: אזור שמכיל את אחד מהאשכולות במכונה של Bigtable. לדוגמה: northamerica-northeast2
    • ‫CLUSTER_NUM_NODES: מספר הצמתים במכונה של Bigtable
    • ‫TRANSLATE_JAR: השם ומספר הגרסה של קובץ ה-JAR של bigtable hbase tools שהורדתם מ-Maven. הערך דומה ל-bigtable-hbase-1.x-tools-2.20.2-jar-with-dependencies.jar.
    • ‫IMPORT_JAR: השם ומספר הגרסה של קובץ ה-JAR של bigtable-beam-import שהורדתם מ-Maven. הערך דומה ל-bigtable-beam-import-2.20.2-shaded.jar.
    • ‫BUCKET_NAME: השם של הקטגוריה ב-Cloud Storage שבה אתם שומרים את קובצי ה-snapshot
    • ‫ZOOKEEPER_QUORUM: המארח של zookeeper שאליו הכלי יתחבר, בפורמט host1.myownpersonaldomain.com
    • ‫MIGRATION_SOURCE_DIRECTORY: הספרייה במארח HBase שמכילה את הנתונים שרוצים להעביר, בפורמט hdfs://host1.myownpersonaldomain.com:8020/hbase
  9. (אופציונלי) כדי לוודא שהמשתנים הוגדרו בצורה נכונה, מריצים את הפקודה printenv כדי להציג את כל משתני הסביבה.

הפסקת השליחה של פעולות כתיבה ל-HBase

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

צילום תמונות מצב של טבלאות HBase

כשאשכול HBase מפסיק להטמיע נתונים, יוצרים תמונת מצב של כל טבלה שרוצים להעביר ל-Bigtable.

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

מריצים את הפקודה הבאה לכל טבלה, ומשתמשים בשם ייחודי לכל קובץ snapshot:

echo "snapshot 'TABLE_NAME', 'SNAPSHOT_NAME'" | hbase shell -n

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

  • ‫TABLE_NAME: שם הטבלה ב-HBase שממנה מייצאים את הנתונים.
  • ‫SNAPSHOT_NAME: השם של קובץ ה-snapshot החדש

ייצוא של קובצי ה-snapshot של HBase ל-Cloud Storage

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

לכל קובץ snapshot שרוצים לייצא, מריצים את הפקודה הבאה:

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \
-Dhbase.zookeeper.quorum=$ZOOKEEPER_QUORUM_AND_PORT -snapshot SNAPSHOT_NAME \
    -copy-from $MIGRATION_SOURCE_DIRECTORY \
    -copy-to $MIGRATION_DESTINATION_DIRECTORY/data

מחליפים את SNAPSHOT_NAME בשם של קובץ ה-snapshot שרוצים לייצא.

חישוב וייצוא של גיבובים (hashes)

בשלב הבא, יוצרים גיבובים (hashes) שישמשו לאימות אחרי שההעברה תסתיים. ‫HashTable הוא כלי אימות ש-HBase מספקת, שמחשב גיבובים לטווחי שורות ומייצא אותם לקבצים. אפשר להריץ משימת sync-table בטבלת היעד כדי להתאים את הגיבובים ולוודא את תקינות הנתונים שהועברו.

מריצים את הפקודה הבאה לכל טבלה שייצאתם:

hbase org.apache.hadoop.hbase.mapreduce.HashTable --batchsize=32000 --numhashfiles=20 \
TABLE_NAME $MIGRATION_DESTINATION_DIRECTORY/hashtable/TABLE_NAME

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

  • ‫TABLE_NAME: השם של טבלת HBase שיצרתם לה קובץ snapshot וייצאתם אותה

יצירת טבלאות יעד

השלב הבא הוא ליצור טבלת יעד במכונה של Bigtable לכל קובץ snapshot שייצאתם. משתמשים בחשבון עם הרשאת bigtable.tables.create למכונה.

במדריך הזה משתמשים בכלי לתרגום סכימות של Bigtable, שיוצר את הטבלה באופן אוטומטי. עם זאת, אם אתם לא רוצים שהסכימה של Bigtable תתאים בדיוק לסכימה של HBase, אתם יכולים ליצור טבלה באמצעות כלי שורת הפקודה cbt או מסוף Cloud de Confiance .

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

לכל טבלה שרוצים לייבא, מריצים את הפקודה הבאה כדי להעתיק את הסכימה מ-HBase ל-Bigtable.

java \
 -Dgoogle.bigtable.project.id=$PROJECT_ID \
 -Dgoogle.bigtable.instance.id=$INSTANCE_ID \
 -Dgoogle.bigtable.table.filter=TABLE_NAME \
 -Dhbase.zookeeper.quorum=$ZOOKEEPER_QUORUM \
 -Dhbase.zookeeper.property.clientPort=$ZOOKEEPER_PORT \
 -jar $TRANSLATE_JAR

מחליפים את TABLE_NAME בשם של טבלת HBase שאתם מייבאים. הכלי Schema Translation משתמש בשם הזה לטבלת Bigtable החדשה.

אפשר גם להחליף את TABLE_NAME בביטוי רגולרי, כמו ".*", שכולל את כל הטבלאות שרוצים ליצור, ואז להריץ את הפקודה פעם אחת בלבד.

ייבוא נתוני HBase ל-Bigtable באמצעות Dataflow

אחרי שיש לכם טבלה שמוכנה להעברת הנתונים, אתם יכולים לייבא ולאמת את הנתונים.

טבלאות לא דחוסות

אם טבלאות HBase לא דחוסות, מריצים את הפקודה הבאה לכל טבלה שרוצים להעביר:

java -jar $IMPORT_JAR importsnapshot \
    --runner=DataflowRunner \
    --project=$PROJECT_ID \
    --bigtableInstanceId=$INSTANCE_ID \
    --bigtableTableId=TABLE_NAME \
    --hbaseSnapshotSourceDir=$MIGRATION_DESTINATION_DIRECTORY/data \
    --snapshotName=SNAPSHOT_NAME \
    --stagingLocation=$MIGRATION_DESTINATION_DIRECTORY/staging \
    --tempLocation=$MIGRATION_DESTINATION_DIRECTORY/temp \
    --maxNumWorkers=$(expr 3 \* $CLUSTER_NUM_NODES) \
    --region=$REGION

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

  • ‫TABLE_NAME: שם הטבלה ב-HBase שאתם מייבאים. הכלי Schema Translation משתמש בשם הזה לטבלת Bigtable החדשה. אין תמיכה בשמות חדשים של טבלאות.
  • ‫SNAPSHOT_NAME: השם שהקציתם לתמונת המצב של הטבלה שאתם מייבאים

אחרי שמריצים את הפקודה, הכלי משחזר את קובץ ה-snapshot של HBase לקטגוריה של Cloud Storage, ואז מתחיל את משימת הייבוא. תהליך השחזור של קובץ ה-snapshot עשוי להימשך כמה דקות, בהתאם לגודל הקובץ.

כשמייבאים, חשוב לזכור את הטיפים הבאים:

  • כדי לשפר את הביצועים של טעינת הנתונים, חשוב להגדיר את maxNumWorkers. הערך הזה עוזר לוודא שלמשימת הייבוא יש מספיק כוח מחשוב כדי להשלים את המשימה בפרק זמן סביר, אבל לא יותר מדי כוח מחשוב שיעמיס על המכונה של Bigtable.
    • אם אתם לא משתמשים במכונה של Bigtable גם לעומס עבודה אחר, הכפילו ב-3 את מספר הצמתים במכונה של Bigtable, והשתמשו במספר הזה בתור maxNumWorkers.
    • אם אתם משתמשים במכונה לעומס עבודה אחר בזמן שאתם מייבאים את נתוני HBase, צריך להקטין את הערך של maxNumWorkers בהתאם.
  • שימוש בסוג ברירת המחדל של ה-worker.
  • במהלך הייבוא, כדאי לעקוב אחרי השימוש במעבד (CPU) של המכונה ב-Bigtable. אם ניצול המעבד (CPU) במכונה של Bigtable גבוה מדי, יכול להיות שתצטרכו להוסיף עוד צמתים. יכול להיות שיעברו עד 20 דקות עד שהאשכול יספק את יתרון הביצועים של צמתים נוספים.

למידע נוסף על מעקב אחרי מכונות Bigtable, קראו את המאמר מעקב.

טבלאות דחוסות ב-Snappy

אם אתם מייבאים טבלאות דחוסות ב-Snappy, אתם צריכים להשתמש בקובץ אימג' של קונטיינר בהתאמה אישית בצינור עיבוד הנתונים של Dataflow. קובץ האימג' של הקונטיינר בהתאמה אישית שמשמש לייבוא נתונים דחוסים ל-Bigtable, מספק תמיכה בספריית הדחיסה המקורית של Hadoop. כדי להשתמש ב-Dataflow Runner v2, צריך להתקין את Apache Beam SDK בגרסה 2.30.0 ואילך, ואת ספריית הלקוח של HBase ל-Java בגרסה 2.3.0 ואילך.

כדי לייבא טבלאות דחוסות ב-Snappy, מריצים את אותה פקודה שמריצים לטבלאות לא דחוסות, אבל מוסיפים את האפשרות הבאה:

    --enableSnappy=true

אימות הנתונים שיובאו ב-Bigtable

כדי לאמת את הנתונים שיובאו, צריך להריץ את המשימה sync-table. המשימה ב-sync-table מחשבת גיבובים (hashes) לטווחי שורות ב-Bigtable, ואז מתאימה אותם לפלט של HashTable שחישבתם קודם.

כדי להריץ את המשימה sync-table, מריצים את הפקודה הבאה במעטפת הפקודות:

java -jar $IMPORT_JAR sync-table  \
    --runner=dataflow \
    --project=$PROJECT_ID \
    --bigtableInstanceId=$INSTANCE_ID \
    --bigtableTableId=TABLE_NAME \
    --outputPrefix=$MIGRATION_DESTINATION_DIRECTORY/sync-table/output-TABLE_NAME-$(date +"%s") \
    --stagingLocation=$MIGRATION_DESTINATION_DIRECTORY/sync-table/staging \
    --hashTableOutputDir=$MIGRATION_DESTINATION_DIRECTORY/hashtable/TABLE_NAME \
    --tempLocation=$MIGRATION_DESTINATION_DIRECTORY/sync-table/dataflow-test/temp \
    --region=$REGION

מחליפים את TABLE_NAME בשם של טבלת HBase שאתם מייבאים.

כשהמשימה של sync-table מסתיימת, פותחים את הדף Dataflow Job details ובודקים את הקטע Custom counters של המשימה. אם כל הנתונים יובאו בהצלחה, הערך של ranges_matched יהיה מספר כלשהו והערך של ranges_not_matched יהיה 0.

מונים בהתאמה אישית ב-Dataflow

אם הערך של ranges_not_matched הוא לא אפס, פותחים את הדף Logs, בוחרים באפשרות Worker Logs ומסננים לפי Mismatch on range. הפלט של היומנים האלה בפורמט קריא למכונה מאוחסן ב-Cloud Storage ביעד הפלט שאתם יוצרים באפשרות outputPrefix של sync-table.

יומני ה-worker של Dataflow

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

ניתוב פעולות כתיבה ל-Bigtable

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

בסיום ההעברה, אתם יכולים למחוק את קובצי ה-snapshot במכונה של HBase.

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