Migrasi Teradata ke BigQuery: Ringkasan
Dokumen ini membantu Anda memahami keputusan yang perlu diambil ketika menggunakan BigQuery Data Transfer Service untuk memigrasikan skema dan data dari Teradata ke BigQuery.
Memigrasikan skema dan data biasanya merupakan salah satu dari beberapa langkah yang diperlukan untuk memindahkan data warehouse dari platform yang berbeda ke BigQuery. Untuk deskripsi proses migrasi menyeluruh, lihat Ringkasan: Memigrasikan data warehouse ke BigQuery.
Anda juga dapat menggunakan batch terjemahan SQL untuk memigrasikan skrip SQL secara massal, atau terjemahan SQL interaktif untuk menerjemahkan kueri ad hoc singkat ini. Teradata SQL didukung sepenuhnya oleh kedua layanan terjemahan SQL.
Ringkasan
Anda dapat menggunakan BigQuery Data Transfer Service bersama agen migrasi khusus untuk menyalin skema dan data dari Teradata ke BigQuery. Agen migrasi yang terhubung ke data warehouse lokal berkomunikasi dengan BigQuery Data Transfer Service untuk menyalin tabel dari data warehouse Anda ke BigQuery.
Langkah-langkah berikut menjelaskan alur kerja untuk proses migrasi:
- Download agen migrasi.
- Konfigurasikan transfer di BigQuery Data Transfer Service
- Jalankan tugas transfer untuk menyalin skema tabel dan data dari data warehouse Anda ke BigQuery.
- Opsional. Pantau tugas transfer menggunakan konsol Google Cloud.
Konfigurasi tugas transfer
Anda dapat mengonfigurasi tugas transfer agar sesuai dengan kebutuhan Anda. Sebelum menyiapkan transfer data dari Teradata ke BigQuery, pertimbangkan opsi konfigurasi yang dijelaskan di bagian berikut dan tentukan setelan yang akan digunakan. Bergantung pada setelan yang dipilih, Anda mungkin perlu menyelesaikan beberapa prasyarat sebelum memulai tugas transfer.
Untuk sebagian besar sistem, terutama yang memiliki tabel besar, Anda bisa mendapatkan performa terbaik dengan mengikuti langkah-langkah berikut:
- Buat partisi tabel Teradata.
- Gunakan Teradata Parallel Transporter (TPT) untuk ekstraksi.
- Buat file skema kustom lalu konfigurasikan kolom pengelompokan dan partisi BigQuery target Anda.
Hal ini memungkinkan agen migrasi melakukan ekstraksi partisi demi partisi, yang paling efisien.
Metode ekstraksi
BigQuery Data Transfer Service mendukung dua metode ekstraksi untuk mentransfer data dari Teradata ke BigQuery:
Gunakan utilitas tbuild Teradata Parallel Transporter (TPT). Ini adalah pendekatan yang direkomendasikan. Menggunakan TPT biasanya menghasilkan ekstraksi data yang lebih cepat.
Dalam mode ini, agen migrasi mencoba menghitung batch ekstraksi menggunakan baris yang didistribusikan oleh partisi. Untuk setiap batch, agen akan memunculkan dan menjalankan skrip ekstraksi TPT, yang menghasilkan sekumpulan file yang dipisahkan tanda pipa. Kemudian, file tersebut diupload ke bucket Cloud Storage dan digunakan oleh tugas transfer. Setelah file diupload ke Cloud Storage, agen migrasi menghapusnya dari sistem file lokal.
Jika Anda menggunakan ekstraksi TPT tanpa kolom partisi, seluruh tabel Anda akan diekstrak. Saat Anda menggunakan ekstraksi TPT dengan kolom partisi, agen akan mengekstrak kumpulan partisi.
Dalam mode ini, agen migrasi tidak membatasi jumlah ruang yang digunakan oleh file yang diekstrak di sistem file lokal. Pastikan sistem file lokal memiliki ruang yang lebih besar daripada ukuran partisi terbesar atau tabel terbesar, tergantung apakah Anda menentukan kolom partisi atau tidak.
Ekstraksi menggunakan driver JDBC dengan koneksi FastExport. Jika ada batasan pada ruang penyimpanan lokal yang tersedia untuk file yang diekstrak, atau jika ada alasan Anda tidak dapat menggunakan TPT, gunakan metode ekstraksi.
Dalam mode ini, agen migrasi mengekstrak tabel ke dalam kumpulan file AVRO di sistem file lokal. Kemudian, file tersebut diupload ke bucket Cloud Storage dan digunakan oleh tugas transfer. Setelah file diupload ke Cloud Storage, agen migrasi akan menghapusnya dari sistem file lokal.
Dalam mode ini, Anda dapat membatasi jumlah ruang yang digunakan oleh file AVRO di sistem file lokal. Jika batas ini terlampaui, ekstraksi dijeda hingga ruang dikosongkan oleh agen migrasi dan menghapus file AVRO yang sudah ada.
Identifikasi skema
BigQuery Data Transfer Service menyediakan deteksi skema otomatis dan pemetaan jenis data selama transfer data dari Teradata ke BigQuery. Secara opsional, Anda dapat menentukan file skema kustom. Sebaiknya lakukan penyesuaian skema dalam situasi berikut:
Anda perlu mengambil informasi penting tentang tabel, seperti partisi, yang akan hilang dalam migrasi.
Misalnya, transfer inkremental harus memiliki file skema yang ditentukan sehingga data dari transfer berikutnya dapat dipartisi dengan benar saat dimuat ke BigQuery. Tanpa file skema yang ditentukan, setiap kali transfer berjalan, BigQuery Data Transfer Service secara otomatis menerapkan skema tabel menggunakan data sumber yang ditransfer, dan semua informasi tentang partisi, pengelompokan, kunci utama dan pelacakan perubahan hilang.
Anda perlu mengubah nama kolom atau jenis data selama transfer data.
File skema kustom
File skema kustom adalah file JSON yang mendeskripsikan objek database. Skema ini berisi kumpulan database, masing-masing berisi kumpulan tabel, yang masing-masing berisi kumpulan kolom singkat ini. Setiap objek memiliki kolom originalName yang menunjukkan nama objek di Teradata, dan kolom name yang menunjukkan nama target untuk objek di BigQuery.
Selain kolom, kolom juga memiliki kolom berikut:
- Kolom originalType yang menunjukkan jenis data kolom di Teradata
- Kolom type yang menunjukkan jenis data target untuk kolom di BigQuery.
Kolom usageType untuk mengambil informasi tentang cara kolom digunakan oleh sistem, seperti dalam pengelompokan atau partisi. Jenis penggunaan berikut ini didukung:
- CLUSTERING: Anda dapat menganotasi hingga empat kolom di setiap tabel target dengan jenis penggunaan ini. Urutan kolom untuk pengelompokan ditentukan berdasarkan urutan kemunculannya dalam skema kustom. Kolom yang Anda pilih harus memenuhi batasan untuk pengelompokan di BigQuery. Jika kolom
PARTITIONING
ditentukan untuk tabel yang sama, BigQuery akan menggunakan kolom tersebut untuk membuat tabel yang dikelompokkan. - COMMIT_TIMESTAMP: Anda hanya dapat menganotasi satu kolom di setiap tabel
target dengan jenis penggunaan ini. Gunakan usageType ini untuk mengidentifikasi kolom
stempel waktu update untuk update inkremental. Kolom ini
digunakan untuk mengekstrak baris yang dibuat/diperbarui sejak
transfer terakhir. Anda hanya dapat menggunakan jenis penggunaan ini dengan kolom yang memiliki jenis data
TIMESTAMP
atauDATE
. - DEFAULT: Anda dapat menganotasi beberapa kolom dalam satu tabel target dengan jenis penggunaan ini. usageType ini menunjukkan bahwa kolom tidak memiliki penggunaan khusus dalam sistem sumber. Ini adalah nilai defaultnya.
- PARTITIONING: Anda hanya dapat menganotasi satu kolom di setiap tabel target
dengan jenis penggunaan ini. Kolom ini digunakan dalam definisi tabel
yang dipartisi
untuk objek tabel yang berisi. Anda hanya dapat menggunakan
jenis penggunaan ini dengan kolom yang memiliki jenis data
TIMESTAMP
atauDATE
. - PRIMARY_KEY: Anda dapat menganotasi kolom di setiap tabel target dengan jenis penggunaan ini. Gunakan jenis penggunaan ini untuk mengidentifikasi hanya satu kolom sebagai
kunci utama atau dalam kasus kunci gabungan, gunakan jenis penggunaan yang sama
di beberapa kolom untuk mengidentifikasi entity unik tabel. Kolom
ini bekerja sama dengan
COMMIT_TIMESTAMP
untuk mengekstrak baris yang dibuat atau diperbarui sejak transfer terakhir dijalankan.
- CLUSTERING: Anda dapat menganotasi hingga empat kolom di setiap tabel target dengan jenis penggunaan ini. Urutan kolom untuk pengelompokan ditentukan berdasarkan urutan kemunculannya dalam skema kustom. Kolom yang Anda pilih harus memenuhi batasan untuk pengelompokan di BigQuery. Jika kolom
Anda dapat membuat file skema kustom secara manual, berdasarkan contoh ini, atau meminta agen migrasi membuatkannya untuk Anda saat menginisialisasi agen singkat ini.
Contoh
Pertimbangkan untuk memigrasikan tabel Teradata bernama orders
di database tpch
dengan definisi tabel berikut:
CREATE SET TABLE TPCH.orders ,FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO,
MAP = TD_MAP1
(
O_ORDERKEY INTEGER NOT NULL,
O_CUSTKEY INTEGER NOT NULL,
O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_TOTALPRICE DECIMAL(15,2) NOT NULL,
O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_SHIPPRIORITY INTEGER NOT NULL,
O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
UNIQUE PRIMARY INDEX ( O_ORDERKEY );
Saat bermigrasi ke BigQuery, misalkan Anda ingin mengonfigurasi skema dengan perubahan berikut:
- Ganti nama kolom
O_CUSTKEY
menjadiO_CUSTOMERKEY
. - Identifikasi
O_ORDERDATE
sebagai kolom partisi.
Skema kustom untuk mengonfigurasi setelan ini adalah sebagai berikut:
{
"databases": [
{
"name": "tpch",
"originalName": "e2e_db",
"tables": [
{
"name": "orders",
"originalName": "orders",
"columns": [
{
"name": "O_ORDERKEY",
"originalName": "O_ORDERKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_CUSTOMERKEY",
"originalName": "O_CUSTKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_ORDERSTATUS",
"originalName": "O_ORDERSTATUS",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 1
},
{
"name": "O_TOTALPRICE",
"originalName": "O_TOTALPRICE",
"type": "NUMERIC",
"originalType": "decimal",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 8
},
{
"name": "O_ORDERDATE",
"originalName": "O_ORDERDATE",
"type": "DATE",
"originalType": "date",
"usageType": [
"PARTITIONING"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_ORDERPRIORITY",
"originalName": "O_ORDERPRIORITY",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 15
},
{
"name": "O_CLERK",
"originalName": "O_CLERK",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 15
},
{
"name": "O_SHIPPRIORITY",
"originalName": "O_SHIPPRIORITY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_COMMENT",
"originalName": "O_COMMENT",
"type": "STRING",
"originalType": "varchar",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 79
}
]
}
]
}
]
}
Transfer sesuai permintaan atau Inkremental
Saat memigrasikan data dari instance database Teradata ke BigQuery, BigQuery Data Transfer Service mendukung transfer penuh (transfer sesuai permintaan) dan transfer berulang (transfer inkremental). Anda menetapkan transfer sebagai on demand atau inkremental dalam opsi penjadwalan saat menyiapkan transfer.
Transfer sesuai permintaan: Gunakan mode ini untuk melakukan migrasi snapshot lengkap skema dan data dari Teradata ke BigQuery.
Transfer terjadwal: Gunakan mode ini untuk melakukan snapshot lengkap dan memigrasikan data baru dan yang diubah (data inkremental) secara rutin dari Teradata ke BigQuery. Transfer inkremental memerlukan penyesuaian skema untuk menganotasi kolom dengan salah satu kasus penggunaan di bawah:
- Menambahkan anotasi pada kolom hanya dengan jenis penggunaan
COMMIT_TIMESTAMP
: Dalam transfer ini, baris baru atau yang diubah di Teradata ditambahkan ke data di BigQuery. Baris yang diperbarui di tabel BigQuery mungkin berpotensi memiliki baris duplikat dengan nilai lama dan baru. - Anotasikan kolom dengan jenis penggunaan
COMMIT_TIMESTAMP
danPRIMARY_KEY
: Dalam transfer ini, baris baru ditambahkan dan baris yang diubah diperbarui ke baris yang sesuai di BigQuery. Kolom yang ditentukan diPRIMARY_KEY
digunakan untuk mempertahankan keunikan data di BigQuery. - Kolom
PRIMARY_KEY
yang ditentukan dalam skema tidak harus berupaPRIMARY_KEY
dalam tabel Teradata. Kolom ini dapat berupa kolom apa pun, tetapi harus berisi data unik.
- Menambahkan anotasi pada kolom hanya dengan jenis penggunaan
Transfer inkremental
Dalam transfer inkremental, transfer pertama selalu membuat snapshot tabel di BigQuery. Semua transfer inkremental berikutnya akan mematuhi anotasi yang ditentukan dalam file skema kustom yang dijelaskan di bawah.
Untuk setiap operasi transfer, stempel waktu dari proses transfer disimpan. Untuk setiap proses transfer berikutnya, agen menerima stempel waktu dari proses transfer sebelumnya (T1) dan stempel waktu saat transfer saat ini dimulai (T2).
Untuk transfer setelah dijalankan pertama kali, agen migrasi akan mengekstrak data menggunakan logika per tabel berikut:
- Jika objek tabel dalam file skema tidak memiliki kolom dengan
jenis penggunaan
COMMIT_TIMESTAMP
, tabel akan dilewati. - Jika tabel memiliki kolom dengan jenis penggunaan
COMMIT_TIMESTAMP
, semua baris dengan stempel waktu antara T1 dan T2 akan diekstrak dan ditambahkan ke tabel yang ada di BigQuery. - Jika tabel memiliki kolom dengan jenis penggunaan
COMMIT_TIMESTAMP
dan kolom dengan jenis penggunaanPRIMARY_KEY
, semua baris dengan stempel waktu antara T1 dan T2 akan diekstrak. Setiap baris baru akan ditambahkan dan baris yang diubah akan diperbarui di tabel yang ada di BigQuery.
Berikut adalah contoh file skema untuk transfer inkremental.
Skema dengan COMMIT_TIMESTAMP
saja
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"DEFAULT"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Skema dengan COMMIT_TIMESTAMP
dan satu kolom (ID) sebagai PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Skema dengan COMMIT_TIMESTAMP
dan kunci Gabungan (ID + Nama) sebagai PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "Name",
"originalName": "Name",
"type": "STRING",
"originalType": "character",
"originalColumnLength": 30,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": false
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Tabel berikut menjelaskan cara agen migrasi menangani operasi bahasa definisi data (DDL) dan bahasa manipulasi data (DML) dalam transfer inkremental.
Operasi teradata | Jenis | Dukungan teradata ke BigQuery |
---|---|---|
CREATE |
DDL | Snapshot lengkap baru untuk tabel dibuat di BigQuery. |
DROP |
DDL | Tidak didukung |
ALTER (RENAME ) |
DDL | Snapshot lengkap baru untuk tabel yang telah diganti namanya dibuat di BigQuery. Snapshot sebelumnya tidak dihapus dari BigQuery}. Pengguna tidak akan diberi tahu tentang tabel yang telah diganti namanya. |
INSERT |
DML | Baris baru ditambahkan ke tabel BigQuery. |
UPDATE |
DML | Baris ditambahkan ke tabel BigQuery sebagai hal baru, mirip dengan operasi INSERT jika hanya COMMIT_TIMESTAMP yang digunakan.
Baris diperbarui, mirip dengan operasi UPDATE jika
COMMIT_TIMESTAMP dan PRIMARY_KEY digunakan. |
MERGE |
DML | Tidak didukung. Lihat sebagai gantinya INSERT , UPDATE ,
dan DELETE . |
DELETE |
DML | Tidak didukung |
Pertimbangan lokasi
Bucket Cloud Storage Anda harus berada di region atau multi-region yang kompatibel dengan region atau multi-region dari set data tujuan di BigQuery.
- Jika set data BigQuery Anda berada di multi-region, bucket Cloud Storage yang berisi data yang ditransfer harus berada di multi-region yang sama atau di lokasi yang terdapat dalam multi-region. Misalnya, jika set data BigQuery Anda berada di multi-region `UE`, bucket Cloud Storage dapat berada di region Belgia `europe-west1`, yang berada di dalam Uni Eropa.
- Jika set data Anda berada di suatu region, bucket Cloud Storage Anda harus berada di region yang sama. Misalnya, jika set data Anda berada di region Tokyo `asia-northeast1`, bucket Cloud Storage Anda tidak boleh berada di multi-region `ASIA`.
Untuk mengetahui informasi mendetail tentang transfer dan region, lihat Lokasi dan transfer set data.
Harga
Transfer data dengan BigQuery tidak dikenakan biaya. Namun, biaya dapat dikenakan di luar Google dengan menggunakan layanan ini, seperti biaya transfer data keluar platform.
- Ekstraksi, upload ke bucket Cloud Storage, dan pemuatan data ke BigQuery tidak dikenai biaya.
- Data tidak dihapus secara otomatis dari bucket Cloud Storage setelah diupload ke BigQuery. Sebaiknya hapus data dari bucket Cloud Storage untuk menghindari biaya penyimpanan tambahan. Lihat Harga Cloud Storage.
- Kuota & batas BigQuery Standar untuk tugas pemuatan berlaku.
- Kuota & batas DML BigQuery Standar untuk pembaruan dan penyisipan proses transfer inkremental akan berlaku.
- Setelah data ditransfer ke BigQuery, harga standar penyimpanan dan komputasi BigQuery berlaku.
- Lihat Halaman harga transfer kami untuk mengetahui detailnya.
Batasan
- Transfer satu kali dan sesuai permintaan didukung sepenuhnya. Transfer inkremental masih dalam versi Beta. Operasi DDL/DML dalam transfer inkremental didukung sebagian.
- Selama transfer data, data diekstrak ke direktori di sistem file
lokal. Pastikan ada ruang kosong yang memadai.
- Saat menggunakan mode ekstraksi FastExport, Anda dapat menetapkan ruang penyimpanan maksimum yang akan digunakan, dan batas yang diberlakukan secara ketat oleh agen migrasi. Tetapkan setelan
max-local-storage
di file konfigurasi agen migrasi saat menyiapkan transfer dari Teradata ke BigQuery. - Saat menggunakan metode ekstraksi TPT, pastikan sistem file memiliki ruang kosong yang cukup — lebih besar dari partisi tabel terbesar dalam instance Teradata.
- Saat menggunakan mode ekstraksi FastExport, Anda dapat menetapkan ruang penyimpanan maksimum yang akan digunakan, dan batas yang diberlakukan secara ketat oleh agen migrasi. Tetapkan setelan
- BigQuery Data Transfer Service mengonversi skema secara otomatis (jika Anda tidak memberikan file skema kustom) dan mentransfer data Teradata ke BigQuery. Data dipetakan dari Teradata ke jenis BigQuery.
- File tidak otomatis dihapus dari bucket Cloud Storage setelah dimuat ke BigQuery. Pertimbangkan untuk menghapus data dari bucket Cloud Storage setelah memuatnya ke BigQuery, untuk menghindari biaya penyimpanan tambahan. Lihat Harga
- Kecepatan ekstraksi dibatasi oleh koneksi JDBC Anda.
- Data yang diekstrak dari Teradata tidak dienkripsi. Lakukan langkah yang sesuai untuk membatasi akses ke file yang diekstrak di sistem file lokal, dan pastikan bucket Cloud Storage diamankan dengan benar.
- Resource database lainnya, seperti prosedur yang disimpan, kueri tersimpan, tampilan, dan fungsi yang ditentukan pengguna tidak ditransfer dan tidak berada dalam cakupan layanan ini singkat ini.
- Transfer inkremental tidak mendukung penghapusan permanen. Transfer inkremental tidak menyinkronkan baris yang dihapus di Teradata dengan BigQuery.
Langkah selanjutnya
- Dapatkan petunjuk langkah demi langkah untuk Memigrasikan Teradata ke BigQuery.
- Coba migrasi uji coba Teradata ke BigQuery.