העברת סכימה ונתונים מ-Apache Hive
במאמר הזה מוסבר איך להעביר את הנתונים, הגדרות האבטחה וצינורות הנתונים מ-Apache Hive ל-BigQuery.
אפשר גם להשתמש בתרגום SQL באצווה כדי להעביר את סקריפטים של SQL בכמות גדולה, או בתרגום SQL אינטראקטיבי כדי לתרגם שאילתות אד-הוק. שני שירותי התרגום של SQL תומכים באופן מלא ב-Apache HiveQL.
הכנות להעברה
בקטעים הבאים מוסבר איך לאסוף מידע על נתונים סטטיסטיים של טבלאות, מטא-נתונים והגדרות אבטחה, כדי לעזור לכם להעביר את מחסן הנתונים מ-Apache Hive ל-BigQuery.
איסוף מידע על טבלת המקור
איסוף מידע על טבלאות Hive של המקור, כמו מספר השורות, מספר העמודות, סוגי הנתונים של העמודות, הגודל, פורמט הקלט של הנתונים והמיקום. המידע הזה שימושי בתהליך ההעברה וגם כדי לאמת את העברת הנתונים. אם יש לכם טבלת Hive בשם employees במסד נתונים בשם corp, משתמשים בפקודות הבאות כדי לאסוף מידע על הטבלה:
# Find the number of rows in the table hive> SELECT COUNT(*) FROM corp.employees; # Output all the columns and their data types hive> DESCRIBE corp.employees; # Output the input format and location of the table hive> SHOW CREATE TABLE corp.employees; Output: … STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat' LOCATION 'hdfs://demo_cluster/user/hive/warehouse/corp/employees' TBLPROPERTIES ( … # Get the total size of the table data in bytes shell> hdfs dfs -du -s TABLE_LOCATION
המרה של פורמט טבלת המקור
אי אפשר להטמיע ישירות ב-BigQuery חלק מהפורמטים שנתמכים ב-Hive.
Hive תומך באחסון נתונים בפורמטים הבאים:
- קובץ טקסט
- קובץ RC
- קובץ רצף
- קובץ Avro
- קובץ ORC
- קובץ Parquet
BigQuery תומך בטעינת נתונים מ-Cloud Storage בכל אחת מהפורמטים הבאים של קבצים:
- CSV
- JSON (מופרד בתו שורה חדשה)
- Avro
- ORC
- Parquet
אפשר לטעון קובצי נתונים בפורמטים Avro, ORC ו-Parquet ישירות ל-BigQuery, בלי צורך בקובצי סכימה. אם יש לכם קובצי טקסט שלא בפורמט CSV או JSON (מופרדים בשורות חדשות), אתם יכולים להעתיק את הנתונים לטבלת Hive בפורמט Avro, או להמיר את סכימת הטבלה לסכימת JSON של BigQuery כדי לספק אותה בזמן ההטמעה.
איסוף הגדרות בקרת הגישה של Hive
ל-Hive ול-BigQuery יש מנגנונים שונים לבקרת גישה. איסוף כל הגדרות בקרת הגישה של Hive, כמו תפקידים, קבוצות, חברים והרשאות שניתנו להם. תכנון מודל אבטחה ב-BigQuery ברמת מערך הנתונים והטמעה של רשימת בקרת גישה (ACL) מדויקת. לדוגמה, אפשר למפות משתמש ב-Hive לחשבון Google, וקבוצה ב-HDFS לקבוצת Google. אפשר להגדיר גישה ברמת מערך הנתונים. משתמשים בפקודות הבאות כדי לאסוף את הגדרות בקרת הגישה ב-Hive:
# List all the users > hdfs dfs -ls /user/ | cut -d/ -f3 # Show all the groups that a specific user belongs to > hdfs groups user_name # List all the roles hive> SHOW ROLES; # Show all the roles assigned to a specific group hive> SHOW ROLE GRANT GROUP group_name # Show all the grants for a specific role hive> SHOW GRANT ROLE role_name; # Show all the grants for a specific role on a specific object hive> SHOW GRANT ROLE role_name on object_type object_name;
ב-Hive, אפשר לגשת ישירות לקובצי HDFS שמאחורי הטבלאות אם יש לכם את ההרשאות הנדרשות. בטבלאות סטנדרטיות ב-BigQuery, אחרי שהנתונים נטענים לטבלה, הם מאוחסנים ב-BigQuery. אפשר לקרוא נתונים באמצעות BigQuery Storage Read API, אבל כל האבטחה ברמת IAM, השורה והעמודה עדיין נאכפת. אם אתם משתמשים בטבלאות חיצוניות של BigQuery כדי לשלוח שאילתות לנתונים ב-Cloud Storage, הגישה ל-Cloud Storage נשלטת גם על ידי IAM.
אתם יכולים ליצור טבלת BigLake שתאפשר לכם להשתמש במחברים כדי לשלוח שאילתות לנתונים באמצעות Apache Spark, Trino או Hive. BigQuery Storage API אוכף מדיניות ניהול ברמת השורה והעמודה לכל טבלאות BigLake ב-Cloud Storage או ב-BigQuery.
העברת נתונים
העברת נתוני Hive מאשכול מקור מקומי או מאשכול מקור אחר מבוסס-ענן ל-BigQuery מתבצעת בשני שלבים:
- העתקת נתונים מאשכול מקור אל Cloud Storage
- טעינת נתונים מ-Cloud Storage ל-BigQuery
בקטעים הבאים מוסבר איך להעביר נתוני Hive, לאמת את הנתונים שהועברו ולטפל בהעברה של נתונים שמוזנים באופן רציף. הדוגמאות נכתבו עבור טבלאות שאינן ACID.
חלוקת נתונים בעמודה
ב-Hive, הנתונים בטבלאות מחולקות מאוחסנים במבנה של ספריות.
כל מחיצה בטבלה משויכת לערך מסוים של עמודת המחיצה. קובצי הנתונים עצמם לא מכילים נתונים של עמודות החלוקה. משתמשים בפקודה SHOW PARTITIONS כדי להציג את המחיצות השונות בטבלה עם מחיצות.
בדוגמה הבאה אפשר לראות שטבלת המקור ב-Hive מחולקת למחיצות לפי העמודות joining_date ו-department. קבצי הנתונים שמתחת לטבלה הזו לא מכילים נתונים שקשורים לשתי העמודות האלה.
hive> SHOW PARTITIONS corp.employees_partitioned joining_date="2018-10-01"/department="HR" joining_date="2018-10-01"/department="Analyst" joining_date="2018-11-01"/department="HR"
אחת הדרכים להעתיק את העמודות האלה היא להמיר את הטבלה המחולקת למחיצות לטבלה לא מחולקת למחיצות לפני הטעינה ל-BigQuery:
- יוצרים טבלה לא מחולקת עם סכימה דומה לטבלה המחולקת.
- טוענים נתונים לטבלה שלא חולקה למחיצות מתוך טבלת המקור שחולקה למחיצות.
- מעתיקים את קובצי הנתונים האלה אל Cloud Storage מתחת לטבלה הלא מחולקת למחיצות שנמצאת בשלב ההכנה.
- טוענים את הנתונים ל-BigQuery באמצעות הפקודה
bq loadומציינים את שם העמודה של המחיצה מסוגTIMESTAMPאוDATE, אם יש כזו, כארגומנטtime_partitioning_field.
העתקת נתונים ל-Cloud Storage
השלב הראשון בהעברת נתונים הוא העתקת הנתונים אל Cloud Storage. אפשר להשתמש ב-Hadoop DistCp כדי להעתיק נתונים מהאשכול המקומי או מאשכול בענן אחר אל Cloud Storage. אחסון הנתונים בקטגוריה באותו אזור או באותו אזור מרובה כמו מערך הנתונים שבו רוצים לאחסן את הנתונים ב-BigQuery. לדוגמה, אם רוצים להשתמש במערך נתונים קיים ב-BigQuery בתור היעד שנמצא באזור טוקיו, צריך לבחור קטגוריה אזורית ב-Cloud Storage בטוקיו כדי להכיל את הנתונים.
אחרי שבוחרים את המיקום של קטגוריית Cloud Storage, אפשר להשתמש בפקודה הבאה כדי להציג רשימה של כל קובצי הנתונים שנמצאים במיקום של טבלת employees Hive:
> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0
מעתיקים את כל הקבצים הקודמים ל-Cloud Storage:
> hadoop distcp hdfs://demo_cluster/user/hive/warehouse/corp/employees gs://hive_data/corp/employees
חשוב לזכור שאתם מחויבים על אחסון הנתונים ב-Cloud Storage בהתאם לתמחור של אחסון הנתונים.
יכול להיות שיש ספריות זמניות שמכילות קבצים זמניים שנוצרו עבור משימות של שאילתות. לפני שמריצים את הפקודה bq load, צריך לוודא שמוחקים את כל הספריות האלה.
טעינת נתונים
BigQuery תומך בטעינת נתונים באצווה בפורמטים רבים מ-Cloud Storage. לפני שיוצרים עבודת טעינה, צריך לוודא שמערך הנתונים ב-BigQuery שאליו רוצים לטעון את הנתונים קיים.
הפקודה הבאה מציגה את הנתונים שהועתקו מ-Hive לטבלה שאינה ACID:
> gcloud storage ls gs://hive_data/corp/employees/ gs://hive-migration/corp/employees/ gs://hive-migration/corp/employees/000000_0 gs://hive-migration/corp/employees/000001_0 gs://hive-migration/corp/employees/000002_0
כדי לטעון את נתוני Hive ל-BigQuery, משתמשים בפקודה bq load.
אפשר להשתמש בתו כללי לחיפוש * בכתובת ה-URL כדי לטעון נתונים מכמה קבצים שיש להם קידומת אובייקט משותפת. לדוגמה, משתמשים בפקודה הבאה כדי לטעון את כל הקבצים עם הקידומת gs://hive_data/corp/employees/:
bq load --source_format=AVRO corp.employees gs://hive_data/corp/employees/*
יכול להיות שיעבור הרבה זמן עד שהעבודות יסתיימו, לכן אפשר להריץ אותן באופן אסינכרוני על ידי הגדרת הדגל --sync לערך False. הפעלת הפקודה bq load
מפיקה את מזהה המשימה של משימת הטעינה שנוצרה, כך שאפשר להשתמש בפקודה הזו כדי לבדוק את סטטוס המשימה.
הנתונים האלה כוללים פרטים כמו סוג העבודה, מצב העבודה והמשתמש שהפעיל את העבודה.
בודקים את הסטטוס של כל עבודת טעינה באמצעות מזהה העבודה המתאים, ומחפשים עבודות שנכשלו עם שגיאות. במקרה של כשל, BigQuery משתמש בגישת 'הכול או כלום' בזמן טעינת נתונים לטבלה. אפשר לנסות לפתור את השגיאות וליצור מחדש בבטחה משימת טעינה נוספת. מידע נוסף מופיע במאמר בנושא פתרון שגיאות.
צריך לוודא שיש מספיק מכסה לטבלה ולפרויקט לטעינת נתונים. אם חורגים מהמכסה, עבודת הטעינה נכשלת ומופיעה השגיאה quotaExceeded.
שימו לב שלא מחויבים על פעולת טעינה של נתונים מ-Cloud Storage ל-BigQuery. אחרי שהנתונים נטענים ל-BigQuery, הם כפופים לתמחור האחסון של BigQuery. אחרי שמשימות הטעינה מסתיימות בהצלחה, אפשר למחוק את הקבצים שנותרו ב-Cloud Storage כדי להימנע מחיובים על אחסון נתונים מיותרים.
אימות
אחרי טעינת הנתונים בהצלחה, אפשר לבדוק את הנתונים שהועברו על ידי השוואה בין מספר השורות בטבלאות של Hive לבין הטבלאות של BigQuery. אפשר להציג את פרטי הטבלה כדי לקבל פרטים על טבלאות BigQuery, כמו מספר השורות, מספר העמודות, שדות החלוקה למחיצות או שדות האשכולות. כדי לבצע אימות נוסף, כדאי לנסות את הכלי לאימות נתונים.
הוספה רציפה
אם אתם מבצעים הטמעה רציפה של נתונים בטבלת Hive, כדאי לבצע העברה ראשונית ואז להעביר ל-BigQuery רק את השינויים המצטברים בנתונים. מקובל ליצור סקריפטים שפועלים שוב ושוב כדי למצוא ולטעון נתונים חדשים. יש הרבה דרכים לעשות את זה, ובקטעים הבאים מתוארת גישה אפשרית אחת.
אפשר לעקוב אחרי התקדמות ההעברה בטבלת מסד נתונים של Cloud SQL, שנקראת טבלת מעקב בקטעים הבאים. במהלך ההרצה הראשונה של ההעברה, המערכת מאחסנת את ההתקדמות בטבלת המעקב. במהלך ההרצות הבאות של ההעברה, אפשר להשתמש במידע מטבלת המעקב כדי לזהות אם נבלעו נתונים נוספים שאפשר להעביר ל-BigQuery.
בוחרים עמודת מזהה מסוג INT64, TIMESTAMP או DATE כדי להבחין בין הנתונים המצטברים. זה נקרא עמודה מצטברת.
הטבלה הבאה היא דוגמה לטבלה ללא חלוקה למחיצות שמשתמשת בסוג TIMESTAMP לעמודה המצטברת שלה:
+-----------------------------+-----------+-----------+-----------+-----------+ | timestamp_identifier | column_2 | column_3 | column_4 | column_5 | +-----------------------------+-----------+-----------+-----------+-----------+ | 2018-10-10 21\:56\:41 | | | | | | 2018-10-11 03\:13\:25 | | | | | | 2018-10-11 08\:25\:32 | | | | | | 2018-10-12 05\:02\:16 | | | | | | 2018-10-12 15\:21\:45 | | | | | +-----------------------------+-----------+-----------+-----------+-----------+
הטבלה הבאה היא דוגמה לטבלה עם חלוקה למחיצות בעמודה מסוג DATEpartition_column. יש לה עמודה מצטברת מסוג מספר שלם int_identifier
בכל מחיצה.
+---------------------+---------------------+----------+----------+-----------+ | partition_column | int_identifier | column_3 | column_4 | column_5 | +---------------------+---------------------+----------+----------+-----------+ | 2018-10-01 | 1 | | | | | 2018-10-01 | 2 | | | | | ... | ... | | | | | 2018-10-01 | 1000 | | | | | 2018-11-01 | 1 | | | | | 2018-11-01 | 2 | | | | | ... | ... | | | | | 2018-11-01 | 2000 | | | | +---------------------+---------------------+----------+----------+-----------+
בקטעים הבאים מוסבר איך להעביר נתונים מ-Hive בהתאם לשאלה אם הם מחולקים למחיצות או לא, ולשאלה אם יש להם עמודות מצטברות או לא.
טבלה לא מחולקת למחיצות ללא עמודות מצטברות
בהנחה שאין דחיסות קבצים ב-Hive, Hive יוצר קבצים חדשים של נתונים כשמבצעים הטמעה של נתונים חדשים. במהלך ההרצה הראשונה, המערכת מאחסנת את רשימת הקבצים בטבלת המעקב ומשלימה את ההעברה הראשונית של טבלת Hive על ידי העתקת הקבצים האלה ל-Cloud Storage וטעינתם ל-BigQuery.
> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees Found 3 items hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0
אחרי המיגרציה הראשונית, חלק מהנתונים מוזנים ל-Hive. אתם צריכים להעביר רק את הנתונים המצטברים האלה ל-BigQuery. בהרצות ההעברה הבאות, מפרטים שוב את קובצי הנתונים ומשווים אותם למידע מטבלת המעקב כדי לזהות קובצי נתונים חדשים שלא הועברו.
> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees Found 5 items hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000003_0 hdfs://demo_cluster/user/hive/warehouse/corp/employees/000004_0
בדוגמה הזו, שני קבצים חדשים מופיעים במיקום של הטבלה. מעבירים את הנתונים על ידי העתקת קובצי הנתונים החדשים ל-Cloud Storage וטעינתם לטבלה ב-BigQuery הקיימת.
טבלה לא מחולקת עם עמודות מצטברות
במקרה כזה, אפשר להשתמש בערך המקסימלי של עמודות מצטברות כדי לקבוע אם נוספו נתונים חדשים. במהלך ההעברה הראשונית, מריצים שאילתה בטבלת Hive כדי לאחזר את הערך המקסימלי של העמודה המצטברת ולשמור אותו בטבלת המעקב:
hive> SELECT MAX(timestamp_identifier) FROM corp.employees; 2018-12-31 22:15:04
בהרצות הבאות של ההעברה, חוזרים על אותה שאילתה כדי לאחזר את הערך המקסימלי הנוכחי של העמודה המצטברת ולהשוות אותו לערך המקסימלי הקודם מטבלת המעקב, כדי לבדוק אם קיימים נתונים מצטברים:
hive> SELECT MAX(timestamp_identifier) FROM corp.employees; 2019-01-04 07:21:16
אם הערך המקסימלי הנוכחי גדול מהערך המקסימלי הקודם, זה מצביע על כך שנתונים מצטברים נבלעו בטבלת Hive, כמו בדוגמה. כדי להעביר את הנתונים המצטברים, יוצרים טבלת ביניים וטוענים לתוכה רק את הנתונים המצטברים.
hive> CREATE TABLE stage_employees LIKE corp.employees; hive> INSERT INTO TABLE stage_employees SELECT * FROM corp.employees WHERE timestamp_identifier>"2018-12-31 22:15:04" and timestamp_identifier<="2019-01-04 07:21:16"
מעבירים את טבלת הביניים על ידי הצגת קובצי הנתונים ב-HDFS, העתקתם ל-Cloud Storage וטעינתם לטבלה ב-BigQuery הקיימת.
טבלה מחולקת למחיצות ללא עמודות מצטברות
הטמעה של נתונים בטבלה עם חלוקה למחיצות עשויה ליצור מחיצות חדשות, לצרף נתונים מצטברים למחיצות קיימות או לבצע את שתי הפעולות. במקרה כזה, תוכלו לזהות את המחיצות שעודכנו, אבל לא תוכלו לזהות בקלות אילו נתונים נוספו למחיצות הקיימות, כי אין עמודה מצטברת שתאפשר לכם להבחין בין הנתונים. אפשרות נוספת היא ליצור ולתחזק תמונות מצב של HDFS, אבל יצירת תמונות מצב עלולה לפגוע בביצועים של Hive, ולכן בדרך כלל היא מושבתת.
במהלך העברת הטבלה בפעם הראשונה, מריצים את הפקודה SHOW PARTITIONS ומאחסנים את המידע על המחיצות השונות בטבלת המעקב.
hive> SHOW PARTITIONS corp.employees partition_column=2018-10-01 partition_column=2018-11-01
בפלט הבא אפשר לראות שלטבלה employees יש שני מחיצות. בטבלה הבאה מוצגת גרסה פשוטה של טבלת המעקב, כדי להראות איך אפשר לאחסן את המידע הזה.
| partition_information | file_path | gcs_copy_status | gcs_file_path | bq_job_id | ... |
|---|---|---|---|---|---|
| partition_column =2018-10-01 | |||||
| partition_column =2018-11-01 |
בהפעלות הבאות של ההעברה, מריצים שוב את הפקודה SHOW PARTITIONS כדי להציג רשימה של כל המחיצות ולהשוות אותן לפרטי המחיצות מטבלת המעקב, כדי לבדוק אם יש מחיצות חדשות שלא הועברו.
hive> SHOW PARTITIONS corp.employees partition_column=2018-10-01 partition_column=2018-11-01 partition_column=2018-12-01 partition_column=2019-01-01
אם מזוהות מחיצות חדשות כמו בדוגמה, יוצרים טבלת ביניים ומטעינים לתוכה רק את המחיצות החדשות מטבלת המקור. מעבירים את טבלת הביניים על ידי העתקת הקבצים ל-Cloud Storage וטעינתם לטבלה ב-BigQuery הקיימת.
טבלה מחולקת למחיצות עם עמודות מצטברות
בתרחיש הזה, טבלת Hive מחולקת למחיצות, ובכל מחיצה יש עמודה מצטברת. הנתונים שמוזנים באופן רציף גדלים בהתאם לערך של העמודה הזו. כאן יש לכם אפשרות להעביר את המחיצות החדשות כמו שמתואר בסעיף הקודם, וגם להעביר נתונים מצטברים שנקלטו במחיצות הקיימות.
כשמעבירים את הטבלה בפעם הראשונה, צריך לאחסן את הערכים המינימליים והמקסימליים של העמודה המצטברת בכל מחיצה, יחד עם המידע על מחיצות הטבלה בטבלת המעקב.
hive> SHOW PARTITIONS corp.employees partition_column=2018-10-01 partition_column=2018-11-01 hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01"; 1 1000 hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-11-01"; 1 2000
בפלט הבא אפשר לראות שלטבלת העובדים יש שתי מחיצות, ומוצגים הערכים המינימליים והמקסימליים של העמודה המצטברת בכל מחיצה. בטבלה הבאה מוצגת גרסה פשוטה של טבלת המעקב, כדי להראות איך אפשר לאחסן את המידע הזה.
| partition_information | inc_col_min | inc_col_max | file_path | gcs_copy_status | ... |
|---|---|---|---|---|---|
| partition_column =2018-10-01 | 1 | 1000 | |||
| partition_column =2018-11-01 | 1 | 2000 |
בריצות הבאות, מריצים את אותן שאילתות כדי לאחזר את הערך המקסימלי הנוכחי בכל מחיצה ולהשוות אותו לערך המקסימלי הקודם מטבלת המעקב.
hive> SHOW PARTITIONS corp.employees partition_column=2018-10-01 partition_column=2018-11-01 partition_column=2018-12-01 partition_column=2019-01-01 hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";
בדוגמה, זוהו שתי מחיצות חדשות וחלק מהנתונים המצטברים הועברו למחיצה הקיימת partition_column=2018-10-01.
אם יש נתונים מצטברים, יוצרים טבלת ביניים, טוענים רק את הנתונים המצטברים לטבלת הביניים, מעתיקים את הנתונים ל-Cloud Storage וטוענים את הנתונים לטבלת BigQuery הקיימת.
הגדרות אבטחה
ב-BigQuery נעשה שימוש ב-IAM כדי לנהל את הגישה למשאבים. תפקידים מוגדרים מראש ב-BigQuery מאפשרים גישה פרטנית לשירות ספציפי, ומיועדים לתמיכה בתרחישי שימוש נפוצים ובדפוסי בקרת גישה. אתם יכולים להשתמש בתפקידים בהתאמה אישית כדי לספק גישה פרטנית עוד יותר על ידי התאמה אישית של קבוצת הרשאות.
אמצעי בקרת הגישה בטבלאות ובמערכי נתונים מציינים את הפעולות שמותר למשתמשים, לקבוצות ולחשבונות שירות לבצע בטבלאות, בתצוגות ובמערכי נתונים. תצוגות מורשות מאפשרות לכם לשתף תוצאות של שאילתות עם משתמשים וקבוצות מסוימים בלי לתת להם גישה לנתוני המקור הבסיסיים. באמצעות אבטחה ברמת השורה ואבטחה ברמת העמודה, אתם יכולים להגביל את הגישה של משתמשים לשורות או לעמודות מסוימות בטבלה. הסתרת נתונים מאפשרת להסתיר באופן סלקטיבי נתונים בעמודות עבור קבוצות של משתמשים, תוך שמירה על הגישה לעמודה.
כשמחילים אמצעי בקרה על הגישה, אפשר להעניק גישה למשתמשים ולקבוצות הבאים:
- משתמש לפי אימייל: מאפשר גישה לחשבון Google פרטי למערך הנתונים
- קיבוץ לפי אימייל: נותן לכל החברים בקבוצה ב-Google גישה למערך הנתונים
- דומיין: מאפשר לכל המשתמשים והקבוצות בדומיין Google גישה למערך הנתונים
- כל המשתמשים שעברו אימות: מאפשרת לכל בעלי חשבון Google גישה למערך הנתונים (הופכת את מערך הנתונים לציבורי)
- בעלי הפרויקט: מעניק לכל בעלי הפרויקט גישה למערך הנתונים
- צפייה בפרויקט: נותנת לכל הצופים בפרויקט גישה למערך הנתונים
- עריכה בפרויקט: נותנת לכל מי שיש לו הרשאת עריכה בפרויקט גישה למערך הנתונים
- תצוגה מורשית: מאפשרת גישה לתצוגה של מערך הנתונים
שינויים בצינורות נתונים
בקטעים הבאים מוסבר איך לשנות את צינורות הנתונים כשמבצעים מיגרציה מ-Hive ל-BigQuery.
Sqoop
אם צינור העיבוד הקיים משתמש ב-Sqoop כדי לייבא נתונים ל-HDFS או ל-Hive לצורך עיבוד, צריך לשנות את העבודה כדי לייבא נתונים ל-Cloud Storage.
אם אתם מייבאים נתונים ל-HDFS, אתם יכולים לבחור באחת מהאפשרויות הבאות:
- מעתיקים את קובצי הפלט של Sqoop ל-Cloud Storage באמצעות Hadoop DistCp.
- להוציא את הקבצים ישירות ל-Cloud Storage באמצעות מחבר Cloud Storage. מחבר Cloud Storage הוא ספריית Java בקוד פתוח שמאפשרת להריץ משימות של Apache Hadoop או של Apache Spark ישירות על נתונים ב-Cloud Storage. מידע נוסף זמין במאמר בנושא התקנת המחבר של Cloud Storage.
אם רוצים ש-Sqoop ייבא נתונים ל-Hive שפועל ב-Cloud de Confiance, צריך להפנות אותו ישירות לטבלת Hive ולהשתמש ב-Cloud Storage כמחסן הנתונים של Hive במקום ב-HDFS. כדי לעשות זאת, מגדירים את המאפיין hive.metastore.warehouse.dir לקטגוריה של Cloud Storage.
אפשר להריץ את משימת Sqoop בלי לנהל אשכול Hadoop באמצעות Managed Service for Apache Spark כדי לשלוח משימות Sqoop לייבוא נתונים ל-BigQuery.
Apache Spark SQL ו-HiveQL
כלי התרגום של SQL באצווה או כלי התרגום האינטראקטיבי של SQL יכולים לתרגם באופן אוטומטי את Apache Spark SQL או HiveQL ל-GoogleSQL.
אם לא רוצים להעביר את Apache Spark SQL או HiveQL ל-BigQuery, אפשר להשתמש ב-Managed Service for Apache Spark או במחבר BigQuery עם Apache Spark.
Hive ETL
אם יש משימות ETL קיימות ב-Hive, אפשר לשנות אותן בדרכים הבאות כדי להעביר אותן מ-Hive:
- ממירים את עבודת ה-ETL של Hive לעבודה של BigQuery באמצעות כלי התרגום של SQL באצווה.
- אפשר להשתמש ב-Apache Spark כדי לקרוא מ-BigQuery ולכתוב ל-BigQuery באמצעות מחבר BigQuery. אתם יכולים להשתמש ב-Managed Service for Apache Spark כדי להריץ את משימות Apache Spark בצורה חסכונית בעזרת אשכולות זמניים.
- לשכתב את צינורות עיבוד הנתונים באמצעות Apache Beam SDK ולהריץ אותם ב-Dataflow.
- משתמשים ב-Apache Beam SQL כדי לשכתב את צינורות עיבוד הנתונים.
כדי לנהל את צינור ה-ETL, אפשר להשתמש ב-Managed Service for Apache Airflow (Apache Airflow) וב-Managed Service for Apache Spark Workflow Templates. Managed Service for Apache Airflow מספק כלי להמרת תהליכי עבודה של Oozie לתהליכי עבודה של Managed Service for Apache Airflow.
Dataflow
אם אתם רוצים להעביר את צינור ה-ETL של Hive לשירותי ענן מנוהלים, כדאי לכתוב את צינורות הנתונים באמצעות Apache Beam SDK ולהריץ אותם ב-Dataflow.
Dataflow הוא שירות מנוהל להפעלת צינורות עיבוד נתונים. הוא מריץ תוכניות שנכתבו באמצעות מסגרת הקוד הפתוח Apache Beam. Apache Beam הוא מודל תכנות מאוחד שמאפשר לפתח צינורות עיבוד נתונים באצווה וצינורות עיבוד נתונים של סטרימינג.
אם צינורות עיבוד הנתונים שלכם הם צינורות סטנדרטיים להעברת נתונים, אתם יכולים להשתמש בתבניות Dataflow כדי ליצור במהירות צינורות Dataflow בלי לכתוב קוד. אפשר לעיין בתבנית הזו שסופקה על ידי Google, שמאפשרת לקרוא קובצי טקסט מ-Cloud Storage, להחיל טרנספורמציות ולכתוב את התוצאות בטבלה ב-BigQuery.
כדי לפשט עוד יותר את עיבוד הנתונים, אפשר גם לנסות את Beam SQL, שמאפשר לעבד נתונים באמצעות הצהרות שדומות ל-SQL.