Pengantar transfer Blob Storage

Dengan BigQuery Data Transfer Service untuk Azure Blob Storage, Anda dapat 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 waktu updated 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 waktu updated lebih besar daripada proses transfer terakhir yang berhasil (2023-07-01T03:00Z). Kali ini, proses transfer selesai tanpa masalah, sehingga berhasil memuat file_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.

Peringatan: BigQuery Data Transfer Service bergantung pada properti "waktu terakhir diubah" di setiap file sumber untuk menentukan file yang akan ditransfer, seperti yang terlihat dalam contoh transfer inkremental. Mengubah properti ini dapat menyebabkan transfer melewati file tertentu, atau memuat file yang sama beberapa kali. Properti ini dapat memiliki nama yang berbeda di setiap sistem penyimpanan yang didukung oleh BigQuery Data Transfer Service. Misalnya, objek Cloud Storage memanggil properti ini updated.

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 file my-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:

1. Buat atau gunakan pengguna Blob Storage yang ada untuk mengakses akun penyimpanan untuk container Blob Storage Anda.

2. Buat token SAS di level akun penyimpanan. Untuk membuat token SAS menggunakan Portal Azure, lakukan langkah berikut:

   1. Untuk Layanan yang diizinkan, pilih Blob.
   2. Untuk Jenis resource yang diizinkan, pilih Container dan Object.
   3. Untuk Izin yang diperbolehkan, pilih Read dan List.
   4. Waktu habis masa berlaku default untuk token SAS adalah 8 jam. Tetapkan waktu habis masa berlaku yang sesuai untuk jadwal transfer Anda.
   5. Jangan tentukan alamat IP apa pun di kolom Alamat IP yang diizinkan.
   6. Untuk Protokol yang diizinkan, pilih Khusus HTTPS.

   

3. 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.

Penting: Untuk mengurangi kemungkinan hilangnya data, jadwalkan transfer Blob Storage Anda agar dilakukan setidaknya 10 menit setelah file ditambahkan ke container.

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 berikutnya

• Pelajari lebih lanjut cara menyiapkan transfer Blob Storage.
• Pelajari parameter runtime dalam transfer lebih lanjut.
• Pelajari BigQuery Data Transfer Service lebih lanjut.