Pengantar transfer Blob Storage
BigQuery Data Transfer Service untuk Azure Blob Storage memungkinkan Anda menjadwalkan dan mengelola tugas pemuatan berulang secara otomatis dari Azure Blob Storage dan Azure Data Lake Storage Gen2 ke BigQuery.
Format file yang didukung
BigQuery Data Transfer Service saat ini mendukung pemuatan data dari Blob Storage dalam format berikut:
- Nilai yang dipisahkan koma (CSV)
- JSON (dibatasi baris baru)
- Avro
- Parquet
- ORC
Jenis kompresi yang didukung
BigQuery Data Transfer Service untuk Blob Storage mendukung pemuatan data terkompresi. Jenis kompresi yang didukung oleh BigQuery Data Transfer Service sama dengan jenis kompresi yang didukung oleh tugas pemuatan BigQuery. Untuk informasi selengkapnya, lihat Memuat data yang dikompresi dan tidak dikompresi.
Prasyarat transfer
Untuk memuat data dari sumber data Blob Storage, kumpulkan hal-hal berikut terlebih dahulu:
- Nama akun Blob Storage, nama container, dan jalur data (opsional) untuk data sumber. Kolom jalur data bersifat opsional; digunakan untuk mencocokkan awalan objek dan ekstensi file yang umum. Jika jalur data dihilangkan, semua file dalam container akan ditransfer.
- Token tanda tangan akses bersama (SAS) Azure yang memberikan akses baca ke sumber data Anda. Untuk mengetahui detail tentang cara membuat token SAS, lihat Tanda tangan akses bersama (SAS).
Parameterisasi runtime transfer
Jalur data dan tabel tujuan Blob Storage dapat diparameterisasi, sehingga Anda dapat memuat data dari container yang diatur berdasarkan tanggal. Parameter yang digunakan oleh transfer Blob Storage sama dengan yang digunakan oleh transfer Cloud Storage. Untuk mengetahui detailnya, lihat Parameter runtime dalam transfer.
Penyerapan data untuk transfer Azure Blob
Anda dapat menentukan cara data dimuat ke BigQuery dengan memilih Preferensi Tulis dalam konfigurasi transfer saat menyiapkan transfer Azure Blob.
Ada dua jenis preferensi tulis yang tersedia, transfer inkremental dan transfer terpotong.Transfer inkremental
Konfigurasi transfer dengan preferensi tulis APPEND
atau WRITE_APPEND
,
yang juga disebut transfer inkremental, secara bertahap menambahkan data baru
setelah transfer sebelumnya yang berhasil ke tabel tujuan
BigQuery. Saat konfigurasi transfer berjalan dengan preferensi tulis APPEND
,
BigQuery Data Transfer Service
akan memfilter file yang telah diubah setelah
proses transfer sebelumnya yang berhasil. Untuk menentukan kapan file diubah, BigQuery Data Transfer Service akan mencari properti "waktu terakhir diubah"
dalam metadata file. Misalnya, BigQuery Data Transfer Service melihat properti stempel waktu updated
dalam file Cloud Storage. Jika
BigQuery Data Transfer Service menemukan file dengan "waktu terakhir diubah" yang muncul
setelah stempel waktu transfer terakhir yang berhasil,
BigQuery Data Transfer Service akan mentransfer file tersebut dalam transfer inkremental.
Untuk mendemonstrasikan cara kerja transfer inkremental, perhatikan contoh transfer
Cloud Storage berikut. Pengguna membuat file dalam
bucket Cloud Storage pada waktu 2023-07-01T00:00Z bernama file_1
. Stempel waktu
updated
untuk file_1
adalah
waktu file dibuat. Pengguna kemudian
membuat transfer inkremental dari bucket Cloud Storage,
yang dijadwalkan untuk dijalankan satu kali setiap hari pada pukul 03.00Z, mulai dari 2023-07-01T03:00Z.
- Pada 2023-07-01T03:00Z, proses transfer pertama dimulai. Karena ini adalah transfer pertama
yang dijalankan untuk konfigurasi ini, BigQuery Data Transfer Service mencoba
memuat semua file yang cocok dengan URI sumber ke dalam tabel
BigQuery tujuan. Proses transfer berhasil dan
BigQuery Data Transfer Service berhasil memuat
file_1
ke tabel BigQuery tujuan. - Proses transfer berikutnya, pada 2023-07-02T03:00Z, tidak mendeteksi file dengan
properti stempel waktu
updated
lebih besar daripada proses transfer terakhir yang berhasil (2023-07-01T03:00Z). Proses transfer berhasil tanpa memuat data tambahan ke tabel BigQuery tujuan.
Contoh sebelumnya menunjukkan cara BigQuery Data Transfer Service melihat
properti stempel waktu updated
dari file sumber untuk menentukan apakah ada perubahan
yang dilakukan pada file sumber, dan untuk mentransfer perubahan tersebut jika ada yang terdeteksi.
Dengan mengikuti contoh yang sama, misalkan pengguna kemudian membuat file lain di
bucket Cloud Storage pada 2023-07-03T00:00Z, bernama file_2
. Stempel waktu
updated
untuk file_2
adalah
waktu file dibuat.
- Proses transfer berikutnya, pada 2023-07-03T03:00Z, mendeteksi bahwa
file_2
memiliki stempel waktuupdated
lebih besar daripada proses transfer terakhir yang berhasil (2023-07-01T03:00Z). Misalkan saat proses transfer dimulai, transfer tersebut gagal karena error sementara. Dalam skenario ini,file_2
tidak dimuat ke dalam tabel BigQuery tujuan. Stempel waktu dari proses transfer terakhir yang berhasil tetap berada pada 2023-07-01T03:00Z. - Proses transfer berikutnya, pada 2023-07-04T03:00Z, mendeteksi bahwa
file_2
memiliki stempel waktuupdated
lebih besar daripada proses transfer terakhir yang berhasil (2023-07-01T03:00Z). Kali ini, proses transfer selesai tanpa masalah, sehingga berhasil memuatfile_2
ke tabel BigQuery tujuan. - Proses transfer berikutnya, pada 2023-07-05T03:00Z, tidak mendeteksi file dengan
stempel waktu
updated
lebih besar dari proses transfer terakhir yang berhasil (2023-07-04T03:00Z). Proses transfer berhasil tanpa memuat data tambahan ke tabel BigQuery tujuan.
Contoh sebelumnya menunjukkan bahwa saat transfer gagal, tidak ada file yang ditransfer ke tabel tujuan BigQuery. Setiap perubahan file akan ditransfer pada proses transfer berikutnya yang berhasil. Setiap transfer yang berhasil setelah transfer yang gagal tidak akan menyebabkan data duplikat. Jika transfer gagal, Anda juga dapat memilih untuk memicu transfer secara manual di luar waktu yang dijadwalkan secara berkala.
Transfer terpotong
Konfigurasi transfer dengan preferensi tulis MIRROR
atau WRITE_TRUNCATE
,
yang juga disebut transfer terpotong, akan menimpa data di
tabel tujuan BigQuery selama setiap proses transfer dengan data
dari semua file yang cocok dengan URI sumber. MIRROR
menimpa salinan baru
data di tabel tujuan. Jika tabel tujuan menggunakan dekorator
partisi, proses transfer hanya akan menimpa data di partisi yang ditentukan. Tabel
tujuan dengan dekorator partisi memiliki format
my_table${run_date}
—misalnya, my_table$20230809
.
Mengulangi transfer inkremental atau transfer terpotong yang sama dalam satu hari tidak akan menyebabkan data duplikat. Namun, jika Anda menjalankan beberapa konfigurasi transfer berbeda yang memengaruhi tabel tujuan BigQuery yang sama, hal ini dapat menyebabkan BigQuery Data Transfer Service menduplikasi data.
Dukungan karakter pengganti untuk jalur data Blob Storage
Anda dapat memilih data sumber yang dipisahkan menjadi beberapa file dengan menentukan
satu atau beberapa karakter pengganti tanda bintang (*
) di jalur data.
Meskipun lebih dari satu karakter pengganti dapat digunakan di jalur data, pengoptimalan tertentu dapat dilakukan jika hanya satu karakter pengganti yang digunakan:
- Ada batas yang lebih tinggi untuk jumlah maksimum file per transfer yang dijalankan.
- Karakter pengganti akan menjangkau batas direktori. Misalnya, jalur data
my-folder/*.csv
akan cocok dengan filemy-folder/my-subfolder/my-file.csv
.
Contoh jalur data Blob Storage
Berikut adalah contoh jalur data yang valid untuk transfer
Blob Storage. Perhatikan bahwa jalur data tidak diawali dengan /
.
Contoh: File tunggal
Untuk memuat satu file dari Blob Storage ke BigQuery, tentukan nama file Blob Storage:
my-folder/my-file.csv
Contoh: Semua file
Untuk memuat semua file dari container Blob Storage ke BigQuery, tetapkan jalur data ke satu karakter pengganti:
*
Contoh: File dengan awalan umum
Untuk memuat semua file dari Blob Storage yang memiliki awalan umum, tentukan awalan umum dengan atau tanpa karakter pengganti:
my-folder/
atau
my-folder/*
Contoh: File dengan jalur yang serupa
Untuk memuat semua file dari Blob Storage dengan jalur serupa, tentukan awalan dan akhiran umum:
my-folder/*.csv
Jika Anda hanya menggunakan satu karakter pengganti, karakter ini akan mencakup berbagai direktori. Dalam contoh ini,
setiap file CSV di my-folder
dipilih, begitu juga setiap file CSV di setiap
subfolder my-folder
.
Contoh: Karakter pengganti di akhir jalur
Pertimbangkan jalur data berikut:
logs/*
Semua file berikut dipilih:
logs/logs.csv
logs/system/logs.csv
logs/some-application/system_logs.log
logs/logs_2019_12_12.csv
Contoh: Karakter pengganti di awal jalur
Pertimbangkan jalur data berikut:
*logs.csv
Semua file berikut dipilih:
logs.csv
system/logs.csv
some-application/logs.csv
Dan tidak ada file berikut yang dipilih:
metadata.csv
system/users.csv
some-application/output.csv
Contoh: Beberapa karakter pengganti
Dengan menggunakan beberapa karakter pengganti, Anda mendapatkan lebih banyak kontrol atas pemilihan file, dengan mengorbankan batas yang lebih rendah. Saat Anda menggunakan beberapa karakter pengganti, setiap karakter pengganti hanya mencakup satu subdirektori.
Pertimbangkan jalur data berikut:
*/*.csv
Kedua file berikut dipilih:
my-folder1/my-file1.csv
my-other-folder2/my-file2.csv
Dan tidak satu pun file berikut yang dipilih:
my-folder1/my-subfolder/my-file3.csv
my-other-folder2/my-subfolder/my-file4.csv
Tanda tangan akses bersama (SAS)
Token Azure SAS digunakan untuk mengakses data Blob Storage atas nama Anda. Gunakan langkah-langkah berikut untuk membuat token SAS untuk transfer Anda:
- Buat atau gunakan pengguna Blob Storage yang ada untuk mengakses akun penyimpanan untuk container Blob Storage Anda.
Buat token SAS di level akun penyimpanan. Untuk membuat token SAS menggunakan Portal Azure, lakukan langkah berikut:
- Untuk Layanan yang diizinkan, pilih Blob.
- Untuk Jenis resource yang diizinkan, pilih Container dan Object.
- Untuk Izin yang diperbolehkan, pilih Read dan List.
- Waktu habis masa berlaku default untuk token SAS adalah 8 jam. Tetapkan waktu habis masa berlaku yang sesuai untuk jadwal transfer Anda.
- Jangan tentukan alamat IP apa pun di kolom Alamat IP yang diizinkan.
- Untuk Protokol yang diizinkan, pilih Khusus HTTPS.
Setelah token SAS dibuat, catat nilai token SAS yang ditampilkan. Anda memerlukan nilai ini saat mengonfigurasi transfer.
Pembatasan IP
Jika membatasi akses ke resource Azure menggunakan firewall Azure Storage, Anda harus menambahkan rentang IP yang digunakan oleh pekerja BigQuery Data Transfer Service ke daftar IP yang diizinkan.
Untuk menambahkan rentang IP sebagai IP yang diizinkan ke firewall Azure Storage, baca bagian Pembatasan IP.
Pertimbangan konsistensi
Perlu waktu sekitar 10 menit agar file tersedia di BigQuery Data Transfer Service setelah ditambahkan ke container Blob Storage.
Praktik terbaik untuk mengontrol biaya keluar
Transfer dari Blob Storage dapat gagal jika tabel tujuan tidak dikonfigurasi dengan benar. Kemungkinan penyebab konfigurasi yang tidak tepat meliputi hal berikut:
- Tabel tujuan tidak ada.
- Skema tabel tidak ditetapkan.
- Skema tabel tidak kompatibel dengan data yang ditransfer.
Untuk menghindari biaya keluar Blob Storage tambahan, uji transfer terlebih dahulu dengan subset file yang kecil tetapi representatif. Pastikan pengujian ini kecil dalam ukuran data dan jumlah file.
Penting juga untuk diperhatikan bahwa pencocokan awalan untuk jalur data terjadi sebelum file ditransfer dari Blob Storage, tetapi pencocokan karakter pengganti terjadi dalam Google Cloud. Perbedaan ini dapat meningkatkan biaya keluar Blob Storage untuk file yang ditransfer ke Google Cloud, tetapi tidak dimuat ke BigQuery.
Sebagai contoh, pertimbangkan jalur data ini:
folder/*/subfolder/*.csv
Kedua file berikut ditransfer ke Google Cloud, karena memiliki awalan folder/
:
folder/any/subfolder/file1.csv
folder/file2.csv
Namun, hanya file folder/any/subfolder/file1.csv
yang akan dimuat ke BigQuery, karena cocok dengan jalur data lengkap.
Harga
Untuk mengetahui informasi selengkapnya, lihat Harga BigQuery Data Transfer Service.
Anda juga dapat dikenai biaya di luar Google dengan menggunakan layanan ini. Untuk mengetahui informasi selengkapnya, baca Harga Blob Storage.
Kuota dan batas
BigQuery Data Transfer Service menggunakan tugas pemuatan untuk memuat data Blob Storage ke BigQuery. Semua kuota dan batas BigQuery pada tugas pemuatan berlaku untuk transfer Blob Storage berulang, dengan pertimbangan tambahan berikut:
Batas | Default |
---|---|
Ukuran maksimum per operasi transfer tugas pemuatan | 15 TB |
Jumlah maksimum file per transfer yang dijalankan jika jalur data Blob Storage berisi 0 atau 1 karakter pengganti | 10.000.000 file |
Jumlah maksimum file per transfer yang dijalankan jika jalur data Blob Storage memiliki 2 karakter pengganti atau lebih | 10.000 file |
Langkah selanjutnya
- Pelajari lebih lanjut cara menyiapkan transfer Blob Storage.
- Pelajari parameter runtime dalam transfer lebih lanjut.
- Pelajari BigQuery Data Transfer Service lebih lanjut.