Mengoptimalkan tugas pemuatan

Anda dapat tetap berada dalam batas tugas pemuatan per tabel di BigQuery dengan mengelompokkan penulisan, melakukan streaming update yang sering, dan mempartisi tabel tujuan. Kuota modifikasi harian bersifat tetap dan tidak dapat ditingkatkan, sehingga menggunakan penulisan yang lebih sedikit dan lebih besar dengan percobaan ulang klien bawaan akan membantu mencegah error quotaExceeded.

Cara kerja kuota operasi tabel

Batas BigQuery untuk modifikasi tabel per tabel per hari per project bersifat tetap, terlepas dari apakah modifikasi menambahkan atau memperbarui data, atau memotong tabel. Batas ini mencakup total gabungan dari semua tugas pemuatan, tugas penyalinan, dan tugas kueri yang menambahkan atau menimpa tabel tujuan.

Tugas pemuatan memiliki tingkat pengisian ulang. Jika Anda melebihi batas operasi tabel atau tingkat pengisian ulangnya, tugas pemuatan akan gagal dengan error quotaExceeded. Batas level project untuk tugas pemuatan per hari akan diisi ulang dalam periode 24 jam berjalan. Saat tugas pemuatan selesai, kuota yang tersedia akan berkurang. Kuota kemudian akan diisi ulang secara bertahap selama 24 jam ke depan. Tugas pemuatan yang gagal tetap diperhitungkan dalam kuota per tabel dan per project. Untuk mengetahui informasi selengkapnya tentang batas tugas pemuatan, lihat Tugas pemuatan.

Untuk tabel berpartisi, batas terpisah untuk modifikasi tabel berpartisi berlaku, menggantikan batas tabel standar.

Agar tetap berada dalam batas operasi tabel harian, distribusikan operasi selama periode 24 jam. Misalnya, jika Anda melakukan 25 update, masing-masing dengan 60 operasi, Anda dapat menjalankan sekitar 60 operasi setiap 58 menit. Pendekatan ini membantu Anda memenuhi batas harian. Untuk memantau update tabel, lihat Tampilan INFORMATION_SCHEMA BigQuery.

Operasi tabel yang dikecualikan dari kuota

Memperbarui informasi tabel (metadata) dan menggunakan pernyataan DML tidak diperhitungkan dalam batas modifikasi tabel harian Anda. Pengecualian ini berlaku untuk tabel standar dan tabel berpartisi.

Project Anda dapat menjalankan pernyataan DML dalam jumlah yang tidak terbatas. Meskipun pernyataan DML sebelumnya diperhitungkan dalam modifikasi tabel harian dan tidak dibatasi meskipun mencapai batas, pernyataan tersebut tidak lagi diperhitungkan.

Penyisipan streaming juga mengubah tabel, tetapi kuota spesifiknya sendiri yang mengaturnya.

Strategi pemuatan untuk menghindari batas operasi tabel

Agar tetap berada dalam batas operasi tabel harian BigQuery, pertimbangkan praktik terbaik berikut:

  • Lakukan penulisan yang lebih sedikit dan lebih besar, bukan banyak penulisan kecil.
  • Minimalkan tugas penulisan terpisah ke tabel produksi akhir Anda setiap hari.

Untuk menggunakan praktik terbaik ini, lakukan pengelompokan atau streaming data Anda ke BigQuery. Pilihan metode pemuatan bergantung pada apakah Anda perlu memuat data dalam volume tinggi secara real-time, atau jika pemuatan real-time tidak menjadi masalah. Bagian berikut menjelaskan pemuatan batch dan streaming data secara mendetail, termasuk alat dan layanan yang dapat Anda gunakan untuk setiap metode.

Pemuatan batch

Agar tetap berada dalam batas pemuatan harian per project untuk BigQuery, kelompokkan data dalam jumlah besar dan muat dengan lebih sedikit tugas ke BigQuery. Bagian berikut menjelaskan beberapa metode yang dapat Anda gunakan untuk memuat data secara batch.

Memuat lebih banyak data untuk setiap tugas

Daripada mengirim data ke BigQuery setiap kali ada informasi baru, kumpulkan dan muat data ke BigQuery menggunakan satu tugas besar.

Misalnya, daripada menjalankan tugas pemuatan terpisah untuk setiap beberapa baris data, Anda dapat menunggu hingga mengumpulkan beberapa ribu baris data dalam satu file—misalnya, dalam file CSV atau JSON—lalu menjalankan satu tugas pemuatan untuk menambahkan semua data ke tabel. Tindakan ini dihitung sebagai satu operasi tabel, meskipun tugas tersebut berisi lebih banyak data. Anda dapat mengelompokkan file dengan menggunakan karakter pengganti bersama tugas pemuatan. Karakter pengganti memungkinkan Anda memilih batch file dalam direktori untuk memuat beberapa file dalam satu tugas pemuatan.

Contoh berikut menunjukkan cara menggunakan karakter pengganti dengan perintah bq load atau kueri LOAD DATA SQL.

bq

Contoh berikut menunjukkan perintah bq load untuk memuat data CSV dari Cloud Storage ke tabel BigQuery bernama my_target_table. Untuk memilih lebih dari satu nama file sumber, gunakan karakter pengganti dengan perintah. Flag AUTODETECT secara otomatis menentukan skema tabel Anda dari data sumber di Cloud Storage, dan dapat mendukung karakter pengganti (*) untuk memuat beberapa file yang sesuai dengan pola penamaan tertentu ke dalam tabel BigQuery.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

Ganti kode berikut:

  • PROJECT_ID: ID project Google Cloud Anda.
  • DATASET_NAME: nama set data BigQuery tempat Anda ingin memuat data.
  • TABLE_NAME: nama tabel BigQuery tempat Anda ingin memuat data.
  • BUCKET_NAME: nama bucket Cloud Storage Anda yang berisi file sumber.
  • OBJECT_PATH_WILDCARD: jalur ke file CSV Anda di bucket Cloud Storage. Sertakan karakter pengganti (*) untuk mencocokkan beberapa file. Misalnya, string gs://my-bucket/path/to/data/my_prefix_*.csv menggunakan karakter pengganti * untuk memuat semua file di gs://my-bucket/path/to/data/ yang diawali dengan my_prefix_ dan diakhiri dengan .csv.

Untuk informasi selengkapnya, lihat referensi berikut:

SQL

Contoh berikut menunjukkan cara menggunakan kueri LOAD DATA SQL untuk memuat data CSV dari bucket Cloud Storage ke tabel BigQuery. Untuk memilih lebih dari satu nama file sumber, gunakan karakter pengganti dengan perintah.

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

Ganti kode berikut:

  • DATASET_NAME: nama set data BigQuery tempat Anda ingin memuat data.
  • TABLE_NAME: nama tabel BigQuery tempat Anda ingin memuat data.
  • SOURCE_FORMAT menetapkan jenis file sumber Anda, misalnya, CSV atau JSON. Dalam contoh ini, gunakan CSV.
  • BUCKET_NAME: nama bucket Cloud Storage Anda yang berisi file sumber.
  • OBJECT_PATH_WILDCARD: jalur ke file CSV Anda di bucket Cloud Storage. Sertakan karakter pengganti (*) untuk mencocokkan beberapa file. Misalnya, string gs://my-bucket/path/to/data/my_prefix_*.csv menggunakan karakter pengganti * untuk memuat semua file di gs://my-bucket/path/to/data/ yang diawali dengan my_prefix_ dan diakhiri dengan .csv.

Untuk mengetahui informasi selengkapnya, lihat Pernyataan pemuatan di GoogleSQL.

Pemuatan batch menggunakan BigQuery Storage Write API (gRPC)

Untuk memuat data batch ke BigQuery, salah satu opsinya adalah menggunakan Storage Write API (gRPC) langsung dari aplikasi Anda dengan Library Klien Google API.

Storage Write API (gRPC) mengoptimalkan pemuatan data agar tetap berada dalam batas tabel. Untuk streaming real-time bervolume tinggi, gunakan aliran data PENDING, bukan aliran data COMMITTED. Saat Anda menggunakan aliran data PENDING, API akan menyimpan data untuk sementara hingga Anda meng-commit aliran data.

Untuk contoh lengkap pemuatan data dalam batch menggunakan Storage Write API, lihat Memuat data dalam batch menggunakan Storage Write API.

Pemuatan batch menggunakan Dataflow

Jika Anda ingin melakukan streaming, mentransformasi, dan menulis data ke BigQuery menggunakan pipeline data, Anda dapat menggunakan Dataflow. Pipeline data yang Anda buat membaca dari sumber yang didukung seperti Pub/Sub atau Apache Kafka. Anda juga dapat membuat pipeline Dataflow menggunakan konektor BigQueryIO, yang menggunakan Storage Write API (gRPC) untuk streaming data berperforma tinggi dan semantik tepat satu kali.

Untuk mengetahui informasi tentang cara menggunakan Dataflow untuk memuat data secara batch ke BigQuery, lihat Menulis dari Dataflow ke BigQuery.

Streaming data

Untuk memuat data dalam volume tinggi dengan update yang sering, sebaiknya lakukan streaming data ke BigQuery. Dengan streaming data, data baru terus ditulis dari aplikasi klien Anda ke BigQuery, sebuah strategi yang menghindari tercapainya batas untuk menjalankan terlalu banyak tugas pemuatan. Bagian berikut menjelaskan beberapa metode untuk menstreaming data Anda ke BigQuery.

Melakukan streaming data menggunakan Storage Write API (gRPC)

Gunakan Storage Write API (gRPC) untuk melakukan streaming data secara real time ke BigQuery dengan latensi minimal. Storage Write API (gRPC) menyediakan protokol streaming yang efisien dengan fungsi lanjutan seperti semantik pengiriman tepat satu kali, deteksi update skema, dan upsert Change Data Capture (CDC) streaming. Selain itu, Anda dapat menyerap hingga 2 TiB per bulan tanpa biaya.

Untuk mengetahui informasi tentang cara menggunakan Storage Write API (gRPC), lihat Melakukan streaming data menggunakan Storage Write API.

Melakukan streaming data menggunakan Dataflow

Gunakan Dataflow untuk membuat pipeline data yang membaca dari sumber yang didukung, misalnya, Pub/Sub atau Apache Kafka. Pipeline ini kemudian mengubah dan menulis data ke BigQuery sebagai tujuan. Anda dapat membuat pipeline Dataflow menggunakan konektor BigQueryIO, yang menggunakan Storage Write API (gRPC).

Untuk mengetahui informasi tentang cara menggunakan Dataflow untuk melakukan streaming data ke BigQuery, lihat Menulis dari Dataflow ke BigQuery.

Praktik terbaik untuk mengelola tabel yang akan dimuat

Selain memuat data secara batch atau streaming ke BigQuery, kelola tabel Anda dengan cara berikut untuk mengoptimalkannya untuk penyerapan data.

Menggunakan tabel berpartisi

Partisi tabel adalah teknik yang efektif untuk mengelola tabel besar di BigQuery, terutama saat Anda perlu sering melakukan operasi pemuatan data. Anda dapat meningkatkan performa dan efektivitas biaya tabel secara signifikan dengan membagi tabel menjadi segmen yang lebih kecil dan lebih mudah dikelola berdasarkan tanggal, stempel waktu, atau bilangan bulat.

Keuntungan utama partisi untuk pemuatan data adalah kuota operasi tabel harian untuk BigQuery berlaku di tingkat partisi, bukan di tingkat tabel. Untuk tabel berpartisi, batas terpisah yang lebih tinggi berlaku untuk modifikasi partisi, yang menggantikan batas tabel standar. Batas untuk tabel berpartisi secara signifikan meningkatkan jumlah tugas pemuatan yang dapat Anda jalankan per hari tanpa mencapai batas kuota.

Strategi yang umum dan sangat efektif adalah memuat data harian Anda secara batch. Misalnya, Anda dapat mengumpulkan semua data harian untuk 2025-09-18 dalam tabel staging sementara. Kemudian, di penghujung hari, Anda menjalankan satu tugas untuk memuat data ini ke dalam partisi tertentu untuk hari ini di tabel produksi utama Anda. Karena BigQuery hanya berinteraksi dengan data untuk satu partisi, pendekatan ini membuat data Anda tetap teratur dan membuat operasi pemuatan Anda lebih cepat dan lebih murah.

Meskipun pembuatan partisi sangat direkomendasikan untuk tabel yang besar dan terus bertambah, sebaiknya hindari jika partisi Anda akan selalu berukuran kurang dari 10 GB. Untuk mengetahui informasi selengkapnya, lihat Kapan harus menggunakan partisi.

Untuk mempelajari lebih lanjut berbagai metode partisi yang tersedia, seperti partisi satuan waktu dan rentang bilangan bulat, lihat Jenis tabel berpartisi.

Memanfaatkan backoff eksponensial, pemotongan, dan jitter bawaan

Backoff eksponensial dan percobaan ulang bawaan adalah metode penanganan error yang membantu aplikasi Anda pulih dengan lancar saat operasi gagal sementara. Kegagalan tersebut dapat mencakup error pembatasan kapasitas (rateLimitExceeded) atau masalah jaringan singkat (unavailable).

Dalam sistem yang andal, worker yang mengambil tugas dari antrean sisi klien juga menggunakan backoff eksponensial dan percobaan ulang. Mereka melakukannya saat memanggil BigQuery, yang menciptakan dua tingkat perlindungan.

Misalnya, library google-cloud-bigquery-storage resmi untuk Python menyertakan logika percobaan ulang bawaan dengan backoff eksponensial. Logika ini menangani error gRPC sementara, misalnya, UNAVAILABLE. Pada umumnya, Anda tidak perlu menulis sendiri kode percobaan ulang ini. Panggilan client.append_rows() menangani percobaan ulang ini secara otomatis.

Penanganan bawaan ini adalah manfaat signifikan dari penggunaan library klien resmi. Anda hanya perlu menangani error yang tidak dapat dicoba lagi, misalnya, INVALID_ARGUMENT, yang berarti ada ketidakcocokan skema.