Memahami keandalan

BigQuery memungkinkan Anda menjalankan workload analisis dengan gangguan minimal dengan menangani kegagalan mesin dan zona secara otomatis dalam suatu region. Untuk ketahanan yang lebih luas, Anda dapat mengonfigurasi disaster recovery lintas region, memulihkan data yang dihapus atau rusak, dan menerapkan percobaan ulang error sisi klien untuk memenuhi persyaratan keandalan Anda.

Kemampuan ini mendukung workload yang menyerap dan menganalisis data dalam jumlah besar dengan performa yang konsisten, termasuk deteksi anomali, analisis real-time dengan penyerapan streaming, dan analisis prediktif dengan BigQuery ML. Untuk contoh mendetail dari solusi ini, lihat Pola referensi BigQuery.

Dimensi keandalan di BigQuery

Untuk menentukan apakah BigQuery memenuhi persyaratan workload Anda, Anda dapat mengevaluasi keandalannya di lima dimensi utama: ketersediaan, ketahanan, konsistensi data, konsistensi performa, dan pemulihan data.

Ketersediaan

Ketersediaan menentukan kemampuan Anda untuk membaca data dari BigQuery atau menulis data ke BigQuery. BigQuery dibuat untuk menjadikan operasi baca dan tulis dengan ketersediaan tinggi dengan SLA waktu beroperasi 99,99%. Ada dua komponen yang terlibat dalam kedua operasi tersebut:

• Layanan BigQuery
• Resource komputasi yang diperlukan untuk menjalankan kueri tertentu

Keandalan layanan adalah fungsi dari BigQuery API tertentu yang Anda gunakan untuk mengambil data. Ketersediaan resource komputasi bergantung pada kapasitas yang tersedia bagi Anda saat menjalankan kueri. Untuk mengetahui informasi selengkapnya tentang unit dasar komputasi untuk BigQuery dan ekonomi resource slot, lihat Memahami slot.

Ketahanan

Ketahanan mengukur proporsi data yang dapat Anda baca dengan berhasil, seperti yang didefinisikan dalam bab Mengimplementasikan SLO di Site Reliability Workbook. Untuk memberikan ketahanan yang tinggi, BigQuery secara otomatis menyimpan salinan redundan data Anda di dua zona dalam lokasi yang Anda pilih.

Konsistensi data

Konsistensi data menentukan cara dan waktu Anda dapat mengkueri data setelah ditulis atau diubah. Salah satu aspek konsistensi data adalah memastikan semantik "tepat satu kali" untuk penyerapan data. Untuk mengetahui informasi selengkapnya, lihat Mencoba kembali penyisipan tugas yang gagal.

Konsistensi performa

Secara umum, performa dapat dinyatakan dalam dua dimensi. Latensi adalah ukuran waktu eksekusi operasi pengambilan data yang panjang seperti kueri. Throughput adalah ukuran jumlah data yang dapat diproses BigQuery selama jangka waktu tertentu. Berkat desain multi-tenant BigQuery yang skalabel secara horizontal, throughput-nya dapat ditingkatkan ke berbagai ukuran data. Kasus penggunaan spesifik Anda menentukan tingkat kepentingan relatif terhadap latensi dan throughput.

Pemulihan data

Anda dapat mengukur kemampuan pemulihan data setelah terjadi pemadaman menggunakan metrik berikut:

• Batas Waktu Pemulihan (RTO): durasi waktu maksimum data tidak dapat tersedia setelah insiden.
• Recovery Point Objective (RPO): jumlah maksimum data yang dikumpulkan sebelum insiden yang dapat ditoleransi oleh organisasi Anda jika hilang.

Pertimbangan ini sangat relevan jika zona atau region mengalami pemadaman layanan yang merusak atau merusak selama beberapa hari.

Perencanaan penanganan bencana

Di bagian ini, perencanaan bencana mencakup kegagalan mulai dari hilangnya satu mesin hingga hilangnya seluruh region. BigQuery menangani kegagalan satu mesin dan kegagalan zona secara otomatis, sedangkan kegagalan regional mengharuskan Anda mendesain arsitektur untuk pemulihan jika workload Anda memerlukannya. Memahami di mana pemulihan otomatis berakhir dan tanggung jawab Anda dimulai sangat penting untuk perencanaan penanganan bencana.

BigQuery menawarkan SLA waktu beroperasi 99,99%. Ketersediaan ini didukung oleh arsitektur regional BigQuery, yang menulis data ke dua zona berbeda dan menyediakan kapasitas komputasi redundan. SLA BigQuery sama untuk region (seperti us-central1) dan multi-region (seperti US).

Penanganan kegagalan otomatis

Karena BigQuery adalah layanan regional, BigQuery otomatis menangani hilangnya mesin atau bahkan seluruh zona. BigQuery mengabstraksi infrastruktur zona yang mendasarinya dari Anda.

Kehilangan mesin

Kegagalan mesin adalah kejadian sehari-hari dalam skala operasional Google. BigQuery dirancang untuk menangani kegagalan mesin secara otomatis tanpa memengaruhi zona penampung.

BigQuery membagi setiap kueri menjadi tugas-tugas kecil dan mengirimkannya secara paralel ke banyak mesin. Jika mesin gagal atau mengalami penurunan performa, BigQuery akan otomatis mengirim ulang tugas yang terpengaruh ke mesin lain. Pendekatan ini penting untuk mengurangi latensi tail.

BigQuery menggunakan encoding Reed-Solomon untuk menyimpan salinan zona data Anda secara tahan lama, dan menyimpan setidaknya satu salinan zona tambahan di zona lain. Jika beberapa kegagalan mesin menyebabkan hilangnya salinan zona, BigQuery akan mendeteksi kehilangan tersebut dan membuat salinan zona baru untuk memulihkan redundansi.

Kehilangan zona

Untuk memenuhi SLA waktu beroperasi 99,99%, BigQuery menyediakan redundansi zona otomatis untuk slot data dan komputasi. Karena ketersediaan komputasi zona tunggal tidak dapat memenuhi SLA ini, BigQuery otomatis merutekan kueri baru ke zona lain dalam waktu satu menit setelah gangguan zona yang parah. Kueri yang sedang berlangsung mungkin memerlukan waktu lebih lama untuk diselesaikan, sedangkan kueri yang baru dikeluarkan akan selesai secara normal di zona lain.

Meskipun suatu zona tetap tidak tersedia untuk jangka waktu yang lama, kehilangan data tidak akan terjadi karena BigQuery menulis data secara sinkron ke dua zona. Akibatnya, pemadaman layanan di zona tidak akan mengganggu layanan Anda.

Jenis kegagalan

Ada dua jenis kegagalan: kegagalan ringan dan kegagalan berat.

Kegagalan ringan adalah kekurangan operasional saat hardware tidak hancur. Contohnya meliputi kegagalan daya, partisi jaringan, atau kerusakan mesin. BigQuery dirancang untuk mencegah kehilangan data selama kegagalan sementara.

Kegagalan berat adalah kegagalan operasional saat hardware hancur, seperti kerusakan akibat banjir, gempa bumi, atau badai. Apakah BigQuery dapat mencegah kehilangan data selama kegagalan berat bergantung pada apakah kegagalan tersebut memengaruhi satu zona atau seluruh region.

Redundansi lokasi dan perilaku kegagalan

Saat membuat set data BigQuery, Anda memilih lokasi untuk menyimpan data. Lokasi ini adalah salah satu dari berikut:

• Region: lokasi geografis tertentu, seperti Iowa (us-central1) atau Montréal (northamerica-northeast1).
• Multi-region: area geografis luas yang berisi dua atau beberapa tempat geografis, seperti Amerika Serikat (US) atau Eropa (EU).

Dalam kedua kasus tersebut, BigQuery secara otomatis menyimpan salinan data Anda di dua zona Google CloudGoogle Cloud yang berbeda dalam satu region di lokasi yang dipilih.

Selain redundansi penyimpanan, BigQuery juga mempertahankan kapasitas komputasi yang berlebihan di beberapa zona. Dengan menggabungkan penyimpanan redundan dan komputasi di berbagai zona ketersediaan, BigQuery memberikan ketersediaan tinggi dan ketahanan.

Catatan: Memilih lokasi multi-region tidak memberikan replikasi lintas-region atau redundansi regional. BigQuery menyimpan data Anda di satu region dalam lokasi multi-region.

Jika terjadi kegagalan tingkat mesin, BigQuery akan terus berjalan dengan penundaan tidak lebih dari beberapa milidetik, dan semua kueri yang sedang berjalan akan terus diproses. Selama kegagalan zona ringan atau berat, tidak akan terjadi kehilangan data, meskipun Anda mungkin perlu mengirim ulang kueri yang sedang berjalan. BigQuery secara otomatis memitigasi kegagalan zona ringan—seperti pemadaman listrik, kegagalan transformator, atau partisi jaringan—dalam beberapa menit.

Kegagalan regional ringan, seperti hilangnya konektivitas jaringan di seluruh region, akan mengakibatkan hilangnya ketersediaan hingga region tersebut kembali online, tetapi tidak mengakibatkan hilangnya data. Kegagalan regional berat, seperti bencana yang menghancurkan seluruh region, dapat mengakibatkan hilangnya data yang disimpan di region tersebut. BigQuery tidak secara otomatis menyediakan cadangan atau replika data Anda di region geografis lain. Anda dapat menggunakan replikasi set data lintas region atau disaster recovery terkelola untuk meningkatkan ketahanan terhadap kegagalan regional yang parah.

Untuk mengetahui informasi selengkapnya tentang lokasi set data BigQuery, baca artikel Pertimbangan lokasi.

Skenario: Kehilangan region

BigQuery tidak memberikan ketahanan atau ketersediaan jika region fisik hancur. Batasan ini berlaku untuk region dan multi-region, sehingga mempertahankan ketahanan dan ketersediaan selama pemadaman layanan regional mengharuskan Anda membuat rencana terlebih dahulu. Jika SLA 99,99% BigQuery tidak memenuhi persyaratan ketersediaan Anda selama pemadaman layanan regional sementara, pertimbangkan untuk mengonfigurasi ketersediaan redundan di seluruh region.

Untuk mencegah kehilangan data jika suatu region hancur, cadangkan data Anda ke lokasi geografis lain. Misalnya, Anda dapat menggunakan replikasi set data lintas region untuk terus mereplikasi data ke region yang berbeda secara geografis.

Jika Anda menggunakan multi-region BigQuery, jangan cadangkan data ke satu region dalam cakupan geografis multi-region tersebut. Misalnya, jika Anda mencadangkan data dari multi-region US, hindari memilih region yang tumpang tindih seperti us-central1 karena risiko kegagalan yang berkorelasi selama bencana. Untuk mengetahui informasi selengkapnya tentang cakupan geografis multi-region, lihat Multi-region.

Untuk menghindari ketidaktersediaan yang diperpanjang, replikasi data Anda dan sediakan slot di dua lokasi BigQuery yang terpisah secara geografis. Anda dapat menggunakan disaster recovery terkelola untuk menyediakan slot secara otomatis di region sekunder dan mengontrol failover workload Anda dari satu region ke region lain.

Skenario: Penghapusan yang tidak disengaja atau kerusakan data

Berdasarkan arsitektur kontrol konkurensi multiversi BigQuery, BigQuery mendukung perjalanan waktu. Dengan perjalanan waktu, Anda dapat membuat kueri data dari waktu mana pun dalam 7 hari terakhir. Kemampuan ini memungkinkan Anda memulihkan data yang salah dihapus, diubah, atau rusak dalam jangka waktu 7 hari. Perjalanan waktu juga dapat digunakan pada tabel yang telah dihapus.

BigQuery juga memungkinkan Anda membuat snapshot tabel untuk mencadangkan data dalam region yang sama untuk waktu yang lebih lama dari periode perjalanan waktu 7 hari. Membuat snapshot adalah operasi khusus metadata yang tidak menimbulkan biaya penyimpanan tambahan. Meskipun snapshot tabel membantu melindungi dari penghapusan yang tidak disengaja, snapshot tabel tidak meningkatkan ketahanan data.

Disaster recovery untuk analisis real-time

Untuk pipeline analisis real-time yang terus-menerus menyerap log endpoint streaming ke BigQuery, perlindungan terhadap ketidaktersediaan regional yang diperpanjang memerlukan replikasi data dan slot penyediaan secara terus-menerus di region sekunder. Namun, karena arsitektur penyerapan sudah tahan terhadap ketidaktersediaan BigQuery sementara saat menggunakan Pub/Sub dan Dataflow sebagai salah satu metode pemuatan data, tingkat redundansi yang tinggi ini mungkin tidak sepadan dengan biaya.

Misalnya, Anda mengonfigurasi tugas ekstrak setiap malam untuk mengekspor data BigQuery dari us-east4 ke penyimpanan Archive Cloud Storage di us-central1. Ekspor ini memberikan pencadangan yang andal jika terjadi kehilangan data yang drastis di us-east4. Dalam konfigurasi ini, Toleransi Jumlah Data yang Hilang (Recovery Point Objective/RPO) adalah 24 jam karena cadangan terbaru dapat berusia hingga 24 jam. Batas Waktu Pemulihan (RTO) dapat berlangsung beberapa hari karena Anda harus memulihkan data dari cadangan Cloud Storage ke BigQuery di us-central1. Jika Anda menyediakan BigQuery di region yang berbeda dari cadangan, Anda harus mentransfer data ke region tersebut terlebih dahulu. Kecuali Anda telah membeli slot redundan di region pemulihan terlebih dahulu, penyediaan kapasitas BigQuery yang diperlukan mungkin memerlukan waktu tambahan, bergantung pada jumlah yang Anda minta.

Disaster recovery untuk pemrosesan data batch

Untuk workload pemrosesan data batch yang mengharuskan Anda mengirimkan laporan harian yang penting bagi bisnis kepada regulator sebelum batas waktu yang ditentukan, menerapkan redundansi dengan menjalankan dua instance terpisah dari seluruh pipeline pemrosesan sering kali sepadan dengan biayanya. Penggunaan dua region terpisah, seperti us-west1 dan us-east4, memberikan pemisahan geografis dan dua domain kegagalan independen jika terjadi ketidaktersediaan regional yang berkepanjangan atau hilangnya region secara permanen.

Jika Anda harus mengirimkan laporan tepat sekali, Anda harus merekonsiliasi output saat kedua pipeline berhasil diselesaikan. Salah satu pendekatannya adalah memilih hasil dari pipeline yang selesai terlebih dahulu—misalnya, dengan memublikasikan notifikasi ke topik Pub/Sub setelah selesai. Atau, Anda dapat mengizinkan pipeline kedua menimpa hasil dan menggunakan pembuatan versi objek di Cloud Storage. Jika pipeline yang nanti selesai menulis data rusak, Anda dapat memulihkan versi yang ditulis oleh pipeline pertama dari Cloud Storage.

Penanganan error

Bagian berikut menjelaskan praktik terbaik untuk menangani error yang memengaruhi keandalan.

Mencoba lagi permintaan API yang gagal

Saat aplikasi klien, library klien, atau alat partner Anda mengeluarkan permintaan API ke BigQuery, gunakan backoff eksponensial terpotong. Dengan strategi percobaan ulang ini, jika menerima error sistem atau error kuota, klien akan mencoba lagi permintaan tersebut hingga beberapa kali menggunakan interval tunggu yang acak dan meningkat.

Menggunakan backoff eksponensial terpotong membuat aplikasi Anda lebih tahan terhadap error sementara. Bahkan dalam kondisi operasi normal, Anda dapat memperkirakan sekitar satu dari 10.000 permintaan akan gagal,seperti yang dijelaskan dalam SLA ketersediaan 99, 99% BigQuery. Dalam kondisi abnormal, tingkat error ini mungkin meningkat. Namun, jika error didistribusikan secara acak, backoff eksponensial dapat memitigasi sebagian besar kegagalan.

Jika permintaan terus-menerus gagal dengan error 5xx, hubungi Cloud Customer Care dan sampaikan dampak bisnisnya dengan jelas saat menetapkan prioritas kasus dukungan agar dukungan dapat melakukan triase masalah secara akurat. Sebaliknya, jika permintaan terus-menerus gagal dengan error 4xx, Anda dapat menyelesaikan masalah tersebut dengan mengubah aplikasi. Periksa pesan error untuk mengetahui detailnya.

Contoh logika backoff eksponensial

Logika backoff eksponensial mencoba ulang kueri atau permintaan dengan meningkatkan waktu tunggu antar-percobaan ulang hingga waktu backoff maksimum. Langkah-langkah berikut menggambarkan cara klien menerapkan backoff eksponensial terpotong:

1. Buat permintaan ke BigQuery.

2. Jika permintaan gagal, tunggu 1 + random_number_milliseconds detik dan coba lagi permintaan tersebut.

3. Jika permintaan gagal, tunggu 2 + random_number_milliseconds detik dan coba lagi permintaan tersebut.

4. Jika permintaan gagal, tunggu 4 + random_number_milliseconds detik dan coba lagi permintaan tersebut.

5. Ulangi pola ini, dengan menggandakan waktu tunggu dasar pada setiap percobaan ulang hingga maximum_backoff kali.

6. Terus tunggu dan coba ulang hingga jumlah maksimum percobaan ulang, tanpa menambah waktu tunggu melebihi maximum_backoff.

Pertimbangkan detail berikut untuk penghitungan backoff ini:

• Waktu tunggu adalah min(((2^n)+random_number_milliseconds), maximum_backoff), dengan n bertambah 1 untuk setiap iterasi (permintaan).

• random_number_milliseconds adalah jumlah acak milidetik yang kurang dari atau sama dengan 1.000. Pengacakan ini membantu menghindari situasi saat banyak klien disinkronkan secara kebetulan dan mencoba lagi secara bersamaan, sehingga mengirimkan permintaan dalam gelombang yang disinkronkan. Hitung ulang random_number_milliseconds setelah setiap permintaan coba lagi.

• Interval backoff maksimum (maximum_backoff) biasanya 32 atau 64 detik. Nilai yang sesuai untuk maximum_backoff bergantung pada kasus penggunaan Anda.

Klien dapat terus mencoba ulang setelah mencapai waktu backoff maksimum. Percobaan ulang setelah tahap ini tidak perlu terus meningkatkan waktu backoff. Misalnya, jika klien menggunakan waktu backoff maksimum 64 detik, setelah mencapai nilai ini, klien dapat terus mencoba lagi setiap 64 detik. Untuk menghindari loop percobaan ulang tanpa henti, konfigurasikan jumlah maksimum percobaan ulang sehingga klien berhenti mencoba ulang setelah batas yang ditetapkan.

Waktu tunggu antara percobaan ulang dan jumlah percobaan ulang bergantung pada kasus penggunaan dan kondisi jaringan Anda.

Mencoba lagi penyisipan tugas yang gagal

Jika aplikasi Anda memerlukan semantik penyisipan tepat satu kali, pertimbangkan cara WriteDisposition tugas Anda menangani data yang ada dalam tabel (gagal, menimpa, atau menambahkan).

Dengan disposisi WRITE_EMPTY atau WRITE_TRUNCATE, Anda dapat mencapai semantik paling banyak sekali dengan mencoba kembali penyisipan atau eksekusi tugas yang gagal, karena BigQuery menulis semua baris yang diserap tugas ke tabel secara atomik.

Dengan disposisi WRITE_APPEND, tentukan ID tugas kustom agar percobaan ulang tidak menambahkan data duplikat. Karena BigQuery menolak permintaan pembuatan ID pekerjaan apa pun yang menggunakan kembali ID pekerjaan sebelumnya, menentukan ID pekerjaan akan memberikan semantik paling banyak satu kali untuk ID tersebut. Kemudian, Anda dapat mencapai semantik tepat satu kali dengan mengonfirmasi bahwa semua upaya sebelumnya gagal sebelum mencoba lagi dengan ID pekerjaan baru yang dapat diprediksi.

Jika masalah jaringan sementara mencegah klien Anda menerima konfirmasi penyisipan tugas, percobaan ulang dengan ID pekerjaan yang sama akan gagal dengan status=ALREADY_EXISTS (code=409 dan reason="duplicate"). Panggil jobs.get untuk mengambil status tugas yang ada dan menentukan apakah akan membuat tugas baru dengan ID pekerjaan baru.

Kasus penggunaan dan persyaratan keandalan

BigQuery dapat berfungsi sebagai komponen penting dalam berbagai arsitektur. Bergantung pada kasus penggunaan dan arsitektur yang Anda deploy, Anda mungkin perlu memenuhi persyaratan ketersediaan, performa, dan keandalan yang berbeda. Bagian berikut membahas dua arsitektur umum dan persyaratan keandalannya.

Analisis real-time

Contoh pertama adalah pipeline pemrosesan data peristiwa. Dalam arsitektur ini, Pub/Sub menyerap peristiwa log dari endpoint, dan pipeline Dataflow streaming memproses dan menulis data ke BigQuery menggunakan BigQuery Storage Write API. Analis kemudian menjalankan kueri ad hoc pada data untuk membuat ulang urutan peristiwa, dan dasbor hampir real-time memvisualisasikan data untuk mendeteksi tren dan pola.

Karena workload ini memerlukan keaktualan data menyeluruh yang tinggi, latensi penyerapan yang rendah sangatlah penting. Setelah data ditulis ke BigQuery, keandalan bergantung pada dua faktor: apakah pengguna dapat menjalankan kueri ad hoc dengan latensi yang konsisten dan dapat diprediksi, serta apakah dasbor yang menggunakan data mencerminkan informasi terbaru.

Pemrosesan data batch

Contoh kedua adalah arsitektur batch processing untuk kepatuhan terhadap peraturan di industri jasa keuangan. Persyaratan utamanya adalah memberikan laporan harian kepada badan pengatur dengan batas waktu setiap malam yang tetap. Selama proses batch setiap malam yang menghasilkan laporan selesai sebelum batas waktu ini, proses tersebut memenuhi persyaratan performa.

Pipeline memuat data ke BigQuery dan menggabungkannya dengan sumber data lain untuk dasbor, analisis, dan pembuatan laporan PDF. Penyerahan laporan ini tepat waktu dan tanpa kesalahan adalah persyaratan bisnis yang sangat penting. Oleh karena itu, Anda harus memastikan keandalan selama penyerapan data dan membuat laporan yang akurat dalam jangka waktu yang konsisten untuk memenuhi tenggat waktu peraturan.