Pengantar pemuatan data

Dokumen ini berisi ringkasan tentang pemuatan data ke BigQuery.

Ringkasan

Ada beberapa cara untuk menyerap data ke BigQuery:

  • Pemuatan batch set kumpulan data.
  • Streaming rekaman individual atau batch catatan.
  • Gunakan kueri untuk membuat data baru dan menambahkan atau menimpa hasilnya ke tabel.
  • Menggunakan aplikasi atau layanan pihak ketiga.

Pemuatan batch

Dengan pemuatan batch, muat data sumber ke tabel BigQuery dalam satu operasi batch. Misalnya, sumber data dapat berupa file CSV, database eksternal, atau sekumpulan file log. Tugas ekstrak, transformasi, dan pemuatan tradisional (ETL) termasuk dalam kategori ini.

Opsi untuk pemuatan batch di BigQuery mencakup hal berikut:

  • Tugas pemuatan. Muat data dari Cloud Storage atau dari file lokal dengan membuat tugas pemuatan. Data tersebut dapat berupa format Avro, CSV, JSON, ORC, atau Parquet.
  • SQL. Pernyataan SQL LOAD DATA memuat data dari satu atau beberapa file ke tabel baru atau yang sudah ada. Anda dapat menggunakan pernyataan LOAD DATA untuk memuat file Avro, CSV, JSON, ORC, atau Parquet.
  • BigQuery Data Transfer Service. Gunakan BigQuery Data Transfer Service untuk mengotomatiskan data pemuatan dari aplikasi Software as a Service (SaaS) Google atau dari aplikasi dan layanan pihak ketiga.
  • BigQuery Storage Write API. Storage Write API memungkinkan Anda memproses batch data dalam jumlah besar secara bebas dan meng-commitnya dalam satu operasi atomik. Jika operasi commit gagal, Anda dapat mencoba kembali operasi tersebut dengan aman. Tidak seperti tugas pemuatan BigQuery, Storage Write API tidak memerlukan staging data ke penyimpanan menengah seperti Cloud Storage.
  • Layanan terkelola lainnya. Menggunakan layanan terkelola lainnya untuk mengekspor data dari penyimpanan data eksternal dan mengimpornya ke BigQuery. Misalnya, Anda dapat memuat data dari ekspor Firestore.

Saat memilih metode pemuatan batch, sebagian besar pola berbasis file harus menggunakan tugas pemuatan atau pernyataan SQL LOAD DATA untuk memuat data secara batch. Layanan lain umumnya harus menggunakan BigQuery Data Transfer Service atau mengekspor data dari layanan Google.

Pemuatan batch dapat dilakukan sebagai operasi satu kali atau pada jadwal berulang. Misalnya, Anda dapat melakukan hal berikut:

  • Anda dapat menjalankan transfer BigQuery Data Transfer Service sesuai jadwal.
  • Anda dapat menggunakan layanan orkestrasi seperti Cloud Composer untuk menjadwalkan tugas pemuatan.
  • Anda dapat menggunakan cron job untuk memuat data sesuai jadwal.

Streaming

Dengan streaming, Anda terus mengirim batch data yang lebih kecil secara real time, sehingga data tersedia untuk dibuat kueri saat data tersebut tiba. Opsi untuk streaming di BigQuery meliputi hal berikut:

  • Storage Write API. Storage Write API mendukung penyerapan streaming throughput tinggi dengan semantik pengiriman tepat satu kali.
  • Dataflow. Gunakan Dataflow dengan Apache Beam SDK untuk menyiapkan pipeline streaming yang menulis ke BigQuery. Untuk mengetahui informasi selengkapnya, lihat konektor I/O BigQuery dalam dokumentasi Apache Beam dan tutorial Streaming dari Pub/Sub ke BigQuery.
  • Datastream. Datastream menggunakan fungsi pengambilan data perubahan BigQuery dan Storage Write API untuk mereplikasi update skema dan data dari database operasional langsung ke BigQuery. Ikuti quickstart ini untuk mengetahui contoh replikasi dari database Cloud SQL untuk PostgreSQL ke BigQuery.
  • BigQuery Connector untuk SAP. BigQuery Connector untuk SAP memungkinkan replikasi data SAP yang mendekati real-time langsung ke BigQuery. Untuk mendapatkan informasi lebih lanjut, baca panduan perencanaan BigQuery Connector untuk SAP.
  • Pub/Sub. Pub/Sub adalah layanan pesan yang dapat Anda gunakan untuk mengoordinasikan analisis streaming dan pipeline integrasi data. Anda dapat menggunakan langganan BigQuery untuk menulis pesan langsung ke tabel BigQuery yang sudah ada.

Data yang dihasilkan

Anda dapat menggunakan SQL untuk menghasilkan data dan menyimpan hasilnya di BigQuery. Opsi untuk menghasilkan data meliputi:

  • Gunakan pernyataan bahasa pengolahan data (DML) untuk melakukan penyisipan massal ke dalam tabel yang sudah ada atau menyimpan hasil kueri dalam tabel baru.

  • Gunakan pernyataan CREATE TABLE ... AS untuk membuat tabel baru dari hasil kueri.

  • Jalankan kueri dan simpan hasilnya ke dalam tabel. Anda dapat menambahkan hasilnya ke tabel yang ada atau menulis ke tabel baru. Untuk mengetahui informasi selengkapnya, lihat Menulis hasil kueri.

Aplikasi pihak ketiga

Beberapa aplikasi dan layanan pihak ketiga menyediakan konektor yang dapat menyerap data ke dalam BigQuery. Detail tentang cara mengonfigurasi dan mengelola pipeline penyerapan bergantung pada aplikasi. Misalnya, untuk memuat data dari sumber eksternal ke penyimpanan BigQuery, Anda dapat menggunakan Informatica Data Loader atau Fivetran Data Pipelines. Untuk mengetahui informasi selengkapnya, baca Memuat data menggunakan aplikasi pihak ketiga.

Memilih metode penyerapan data

Berikut adalah beberapa hal yang perlu dipertimbangkan saat Anda memilih metode penyerapan data.

Sumber Data. Sumber data atau format data dapat menentukan apakah pemuatan atau streaming batch lebih mudah diterapkan dan dikelola. Pertimbangkan hal-hal berikut:

  • Jika BigQuery Data Transfer Service mendukung sumber data, mentransfer data secara langsung ke BigQuery mungkin merupakan solusi paling sederhana untuk diterapkan.

  • Untuk data dari sumber pihak ketiga yang tidak didukung oleh BigQuery Data Transfer Service, ubah data ke dalam format yang didukung oleh pemuatan batch dan gunakan metode tersebut sebagai gantinya.

  • Jika data Anda berasal dari Spark atau Hadoop, pertimbangkan untuk menggunakan konektor BigQuery untuk menyederhanakan penyerapan data.

  • Untuk file lokal, pertimbangkan tugas pemuatan batch, terutama jika BigQuery mendukung format file tanpa memerlukan langkah transformasi atau pembersihan data.

  • Untuk data aplikasi seperti peristiwa aplikasi atau aliran log, mungkin lebih mudah untuk melakukan streaming data secara real time, daripada mengimplementasikan pemuatan batch.

Data yang berubah lambat versus data yang cepat berubah. Jika Anda perlu menyerap dan menganalisis data mendekati real-time, pertimbangkan untuk melakukan streaming data. Dengan streaming, data dapat dibuat kueri segera setelah setiap kumpulan data tiba. Hindari penggunaan pernyataan DML untuk mengirimkan update atau penyisipan baris individual dalam jumlah besar. Untuk data yang sering diupdate, sering kali lebih baik melakukan streaming log perubahan dan menggunakan tampilan untuk mendapatkan hasil terbaru. Opsi lainnya adalah menggunakan Cloud SQL sebagai database pemrosesan transaksi online (OLTP) dan menggunakan kueri gabungan untuk menggabungkan data di BigQuery.

Jika data sumber berubah secara lambat atau Anda tidak memerlukan hasil yang terus diupdate, pertimbangkan untuk menggunakan tugas pemuatan. Misalnya, jika Anda menggunakan data untuk menjalankan laporan harian atau per jam, tugas pemuatan dapat lebih murah dan dapat menggunakan lebih sedikit resource sistem.

Skenario lain adalah data yang jarang muncul atau sebagai respons terhadap suatu peristiwa. Dalam hal ini, pertimbangkan untuk menggunakan Dataflow untuk melakukan streaming data atau gunakan Cloud Functions untuk memanggil API streaming sebagai respons terhadap pemicu.

Keandalan solusi. BigQuery memiliki Perjanjian Tingkat Layanan (SLA). Namun, Anda juga perlu mempertimbangkan keandalan solusi tertentu yang Anda terapkan. Pertimbangkan hal-hal berikut:

  • Dengan format yang diketik secara longgar seperti JSON atau CSV, data yang buruk dapat membuat seluruh tugas pemuatan gagal. Pertimbangkan apakah Anda memerlukan langkah pembersihan data sebelum memuat, dan pertimbangkan cara merespons error. Pertimbangkan juga untuk menggunakan format yang diketik dengan kuat seperti Avro, ORC, atau Parquet.
  • Tugas pemuatan berkala memerlukan penjadwalan, yang menggunakan Cloud Composer, cron, atau alat lainnya. Komponen penjadwalan dapat menjadi titik kegagalan dalam solusi.
  • Dengan streaming, Anda dapat memeriksa keberhasilan setiap rekaman dan melaporkan error dengan cepat. Pertimbangkan untuk menulis pesan yang gagal ke antrean pesan yang belum diproses untuk analisis dan pemrosesan nanti. Untuk mengetahui informasi selengkapnya tentang error streaming BigQuery, baca Memecahkan masalah streaming insert.
  • Tugas streaming dan pemuatan tunduk pada quotas. Untuk mengetahui informasi tentang cara menangani error kuota, lihat Memecahkan masalah error kuota BigQuery.
  • Solusi pihak ketiga mungkin memiliki perbedaan konfigurasi, keandalan, jaminan pengurutan, dan faktor lainnya, jadi pertimbangkan hal ini sebelum mengadopsi solusi.

Latensi. Pertimbangkan berapa banyak data yang Anda muat dan seberapa cepat Anda perlu data tersebut tersedia. Streaming menawarkan latensi data terendah yang tersedia untuk analisis. Tugas pemuatan berkala memiliki latensi yang lebih tinggi karena data baru hanya akan tersedia setelah setiap tugas pemuatan selesai.

Tugas pemuatan menggunakan kumpulan slot bersama secara default. Tugas pemuatan mungkin menunggu dalam status tertunda hingga slot tersedia, terutama jika Anda memuat data dalam jumlah yang sangat besar. Jika hal itu menimbulkan waktu tunggu yang tidak dapat diterima, Anda dapat membeli slot khusus, bukan menggunakan gabungan slot bersama. Untuk informasi selengkapnya, lihat Pengantar Reservasi.

Performa kueri untuk sumber data eksternal mungkin tidak setinggi performa kueri untuk data yang disimpan di BigQuery. Jika meminimalkan latensi kueri itu penting, sebaiknya muat data ke BigQuery.

Format penyerapan data. Pilih format penyerapan data berdasarkan faktor berikut:

  • Dukungan skema. Ekspor Avro, ORC, Parquet, dan Firestore adalah format deskripsi mandiri. BigQuery membuat skema tabel secara otomatis berdasarkan data sumber. Untuk data JSON dan CSV, Anda dapat memberikan skema eksplisit, atau Anda dapat menggunakan deteksi otomatis skema.

  • Data datar atau kolom bertingkat dan berulang. Avro, CSV, JSON, ORC, dan Parquet mendukung data datar. Ekspor Avro, JSON, ORC, Parquet, dan Firestore juga mendukung data dengan kolom bertingkat dan berulang. Data bertingkat dan berulang berguna untuk mengekspresikan data hierarkis. Kolom bertingkat dan berulang juga mengurangi duplikasi data saat memuat data.

  • Newline yang disematkan. Saat Anda memuat data dari file JSON, barisnya harus dipisahkan newline. BigQuery mengharapkan file JSON yang dibatasi newline berisi satu data per baris.

  • Encoding. BigQuery mendukung encoding UTF-8 untuk data bertingkat atau berulang dan datar. BigQuery mendukung encoding ISO-8859-1 untuk data datar hanya untuk file CSV.

Memuat data bertingkat dan berulang

Anda dapat memuat data ke dalam kolom bertingkat dan berulang dalam format data berikut:

  • Avro
  • JSON (dibatasi baris baru)
  • ORC
  • Parquet
  • Ekspor Datastore
  • Ekspor Firestore

Untuk mengetahui informasi tentang cara menentukan kolom bertingkat dan berulang di skema saat Anda memuat data, lihat Menentukan kolom bertingkat dan berulang.

Memuat data dari layanan Google lainnya

Beberapa layanan Google mengekspor data ke BigQuery menggunakan kueri, ekspor, atau transfer terjadwal. Untuk mengetahui informasi lebih lanjut mengenai layanan yang mendukung ekspor ke BigQuery, baca Memuat data dari layanan Google.

Layanan Google lainnya mendukung ekspor data yang dimulai dari BigQuery Data Transfer Service. Untuk mengetahui informasi selengkapnya tentang layanan yang mendukung ekspor yang dimulai oleh BigQuery Data Transfer Service, lihat BigQuery Data Transfer Service.

Kuota

Untuk mengetahui informasi tentang kuota, lihat bagian berikut:

Alternatif untuk pemuatan data

Anda tidak perlu memuat data sebelum menjalankan kueri dalam situasi berikut:

Set data publik
Set data publik adalah set data yang disimpan di BigQuery dan dibagikan kepada publik. Untuk informasi lebih lanjut, baca Set data publik BigQuery.
Set data bersama
Anda dapat membagikan set data yang tersimpan di BigQuery. Jika seseorang telah membagikan set data kepada Anda, Anda dapat menjalankan kueri pada set data tersebut tanpa memuat data.
Sumber data eksternal
BigQuery dapat menjalankan kueri pada bentuk data eksternal tertentu, tanpa memuat data ke dalam penyimpanan BigQuery. Dengan pendekatan ini, Anda dapat memanfaatkan kemampuan analisis BigQuery tanpa memindahkan data yang disimpan di tempat lain. Untuk mengetahui informasi tentang manfaat dan batasan pendekatan ini, lihat sumber data eksternal.
Mencatat file
Cloud Logging menyediakan opsi untuk mengekspor file log ke BigQuery. Lihat Mengonfigurasi dan mengelola sink untuk informasi selengkapnya.

Memantau penggunaan tugas pemuatan

Anda dapat memantau penggunaan tugas pemuatan menggunakan dua cara berikut:

  • Menggunakan Cloud Monitoring. Untuk mendapatkan informasi lebih lanjut, lihat Metrik BigQuery. Secara khusus, Anda dapat memantau jumlah data dan jumlah baris yang diupload ke tabel tertentu. Jika tugas pemuatan Anda mengupload data ke tabel tertentu, ini dapat berupa proxy untuk memantau penggunaan data upload tugas pemuatan.

  • Penggunaan INFORMATION_SCHEMA.JOBS_BY_PROJECT. Anda dapat menggunakan tampilan INFORMATION_SCHEMA.JOBS_BY_PROJECT untuk mendapatkan jumlah tugas pemuatan per tabel per hari.

Contoh kasus penggunaan

Contoh berikut menjelaskan metode yang harus digunakan berdasarkan kasus penggunaan Anda dan cara menggunakannya dengan solusi analisis data lain.

Streaming data menggunakan Storage Write API

Misalkan ada data peristiwa pemrosesan pipeline dari log endpoint. Peristiwa dibuat secara terus-menerus dan harus tersedia untuk kueri di BigQuery sesegera mungkin. Keaktualan data sangat penting untuk kasus penggunaan ini, maka Storage Write API adalah pilihan terbaik untuk menyerap data ke BigQuery. Arsitektur yang direkomendasikan untuk menjaga agar endpoint tetap ringkas adalah mengirimkan peristiwa ke Pub/Sub, dari peristiwa tersebut digunakan oleh pipeline Dataflow streaming yang langsung streaming ke BigQuery.

Masalah keandalan utama arsitektur ini adalah cara menangani kegagalan memasukkan data ke BigQuery. Jika tiap kumpulan data penting dan tidak dapat hilang, data perlu di-buffer sebelum mencoba menyisipkan. Dalam arsitektur yang direkomendasikan di atas, Pub/Sub dapat berperan sebagai buffering dengan kemampuan retensi pesannya. Pipeline Dataflow harus dikonfigurasi untuk mencoba ulang penyisipan streaming BigQuery dengan backoff eksponensial terpotong. Setelah kapasitas Pub/Sub sebagai buffer habis, misalnya dalam kasus BigQuery tidak tersedia dalam waktu lama atau kegagalan jaringan, data harus dipertahankan di klien dan klien membutuhkan mekanisme untuk melanjutkan penyisipan kumpulan data yang dipertahankan setelah ketersediaan dipulihkan. Untuk mengetahui informasi selengkapnya tentang cara menangani situasi ini, lihat postingan blog Panduan Keandalan Google Pub/Sub.

Kasus kegagalan lain yang harus ditangani adalah kumpulan data poison. Kumpulan data poison adalah kumpulan data yang ditolak oleh BigQuery karena kumpulan data gagal disisipkan dengan error yang tidak dapat dicoba lagi atau kumpulan data yang belum berhasil dimasukkan setelah jumlah maksimum percobaan ulang. Kedua jenis kumpulan data harus disimpan di "antrean surat berhenti" oleh pipeline Dataflow untuk penyelidikan lebih lanjut.

Jika semantik tepat satu kali diperlukan, buat streaming tulis dalam jenis yang di-commit, dengan offset kumpulan data yang disediakan oleh klien. Tindakan ini akan menghindari duplikasi, karena operasi tulis hanya dilakukan jika nilai offset cocok dengan offset penambahan berikutnya. Jika offset tidak diberikan, kumpulan data akan ditambahkan ke akhir streaming saat ini, dan mencoba ulang penambahan yang gagal dapat mengakibatkan kumpulan data muncul lebih dari satu kali dalam streaming.

Jika jaminan tepat satu kali tidak diperlukan, penulisan ke streaming default memungkinkan throughput yang lebih tinggi dan juga tidak mengurangi batas kuota saat membuat streaming tulis.

Perkirakan throughput jaringan dan pastikan terlebih dahulu bahwa Anda memiliki kuota yang cukup untuk menyajikan throughput.

Jikaworkload Anda menghasilkan atau memproses data pada kecepatan yang sangat tidak merata, cobalah untuk lancarkan lonjakan beban pada klien dan streaming ke BigQuery dengan throughput yang konstan. Hal ini dapat menyederhanakan perencanaan kapasitas Anda. Jika tidak memungkinkan, pastikan Anda siap menangani error 429 (resource habis) jika dan saat throughput melebihi kuota selama lonjakan singkat.

Pemrosesan data batch

Misalnya ada pipeline batch processing malam yang harus diselesaikan sebelum batas waktu tetap. Data harus tersedia sebelum batas waktu ini untuk diproses lebih lanjut oleh proses batch lain agar dapat menghasilkan laporan yang akan dikirim ke regulator. Kasus penggunaan ini umum terjadi di industri yang diatur seperti keuangan.

Pemuatan batch data dengan tugas pemuatan adalah pendekatan yang tepat untuk kasus penggunaan ini karena latensi bukanlah masalah asalkan batas waktu dapat dipenuhi. Pastikan bucket Cloud Storage Anda memenuhi persyaratan lokasi untuk memuat data ke dalam set data BigQuery.

Hasil tugas pemuatan BigQuery bersifat atomik; baik semua kumpulan data akan disisipkan atau tidak sama sekali. Sebagai praktik terbaik, saat menyisipkan semua data dalam tugas pemuatan tunggal, buat tabel baru menggunakan disposisi WRITE_TRUNCATE resource JobConfigurationLoad. Hal ini penting saat mencoba kembali tugas pemuatan yang gagal, karena klien mungkin tidak dapat membedakan antara tugas yang gagal dan kegagalan yang disebabkan, misalnya, dalam mengomunikasikan status keberhasilan kembali kepada klien.

Dengan asumsi data yang akan diserap telah berhasil disalin ke Cloud Storage, percobaan ulang dengan backoff eksponensial sudah cukup untuk mengatasi kegagalan penyerapan.

Sebaiknya tugas batch per malam tidak mencapai kuota default sebesar 1.500 pemuatan per tabel per hari, bahkan dengan percobaan ulang. Saat memuat data secara inkremental, kuota default cukup untuk menjalankan tugas pemuatan setiap 5 menit dan memiliki kuota rata-rata untuk setidaknya 1 percobaan ulang per tugas.

Langkah selanjutnya