Otomatisasi pencadangan BigQuery yang skalabel

Last reviewed 2024-09-17 UTC

Arsitektur ini menyediakan framework dan deployment referensi untuk membantu Anda mengembangkan strategi pencadangan BigQuery. Framework yang direkomendasikan ini dan otomatisasinya dapat membantu organisasi Anda melakukan hal berikut:

  • Patuhi tujuan pemulihan dari bencana organisasi Anda.
  • Memulihkan data yang hilang karena kesalahan manusia.
  • Mematuhi peraturan.
  • Meningkatkan efisiensi operasional.

Cakupan data BigQuery dapat menyertakan (atau mengecualikan) folder, project, set data, dan tabel. Arsitektur yang direkomendasikan ini menunjukkan cara mengotomatiskan operasi pencadangan berulang dalam skala besar. Anda dapat menggunakan dua metode pencadangan untuk setiap tabel: snapshot BigQuery dan ekspor BigQuery ke Cloud Storage.

Dokumen ini ditujukan untuk arsitek, engineer, dan petugas tata kelola data cloud yang ingin menentukan dan mengotomatiskan kebijakan data di organisasi mereka.

Arsitektur

Diagram berikut menunjukkan arsitektur pencadangan otomatis:

Arsitektur untuk solusi pencadangan otomatis.

Alur kerja yang ditampilkan dalam diagram sebelumnya mencakup fase berikut:

  1. Cloud Scheduler memicu eksekusi ke layanan dispatcher melalui pesan Pub/Sub, yang berisi cakupan data BigQuery yang disertakan dan dikecualikan. Run dijadwalkan menggunakan ekspresi cron.
  2. Layanan dispatcher, yang dibangun di atas Cloud Run, menggunakan BigQuery API untuk mencantumkan tabel yang berada dalam cakupan BigQuery.
  3. Layanan dispatcher mengirimkan satu permintaan untuk setiap tabel ke layanan configurator melalui pesan Pub/Sub.

  4. Layanan konfigurasi Cloud Run menghitung kebijakan pencadangan tabel dari salah satu opsi yang ditentukan berikut:

    1. Kebijakan tingkat tabel, yang ditentukan oleh pemilik data.
    2. Kebijakan penggantian, yang ditentukan oleh petugas tata kelola data, untuk tabel yang tidak memiliki kebijakan yang ditentukan.

    Untuk mengetahui detail tentang kebijakan pencadangan, lihat Kebijakan pencadangan.

  5. Layanan konfigurasi mengirimkan satu permintaan untuk setiap tabel ke layanan berikutnya, berdasarkan kebijakan pencadangan yang dihitung.

  6. Bergantung pada metode pencadangan, salah satu layanan Cloud Run kustom berikut mengirimkan permintaan ke BigQuery API dan menjalankan proses pencadangan:

    1. Layanan untuk snapshot BigQuery mencadangkan tabel sebagai snapshot.
    2. Layanan untuk ekspor data mencadangkan tabel sebagai ekspor data ke Cloud Storage.

  7. Jika metode pencadangan adalah ekspor data tabel, sink log Cloud Logging akan memproses peristiwa penyelesaian tugas ekspor untuk mengaktifkan eksekusi asinkron langkah berikutnya.

  8. Setelah layanan pencadangan menyelesaikan operasinya, Pub/Sub akan memicu layanan pemberi tag.

  9. Untuk setiap tabel, layanan pemberi tag mencatat hasil layanan pencadangan dan memperbarui status pencadangan di lapisan metadata Cloud Storage.

Produk yang digunakan

Arsitektur referensi ini menggunakan produk Google Cloud berikut:

  • BigQuery: Data warehouse perusahaan yang membantu Anda mengelola dan menganalisis data dengan fitur bawaan seperti machine learning, analisis geospasial, dan business intelligence.
  • Cloud Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan pemberitahuan.
  • Pub/Sub: Layanan pesan asinkron dan skalabel yang memisahkan layanan yang menghasilkan pesan dari layanan yang memproses pesan tersebut.
  • Cloud Run: Platform komputasi serverless yang memungkinkan Anda menjalankan container langsung di atas infrastruktur Google yang bersifat skalabel.
  • Cloud Storage: Penyimpanan objek berbiaya rendah dan tanpa batas untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di berbagai lokasi untuk redundansi.
  • Cloud Scheduler: Penjadwal cron job tingkat perusahaan yang terkelola sepenuhnya yang memungkinkan Anda menyiapkan unit kerja terjadwal untuk dieksekusi pada waktu yang ditentukan atau interval reguler.
  • Datastore: Database NoSQL yang sangat skalabel untuk aplikasi web dan seluler Anda.

Kasus penggunaan

Bagian ini memberikan contoh kasus penggunaan yang dapat Anda gunakan untuk arsitektur ini.

Otomatisasi pencadangan

Sebagai contoh, perusahaan Anda mungkin beroperasi di industri yang diatur dan menggunakan BigQuery sebagai data warehouse utama. Meskipun perusahaan Anda mengikuti praktik terbaik dalam pengembangan software, peninjauan kode, dan engineering rilis, masih ada risiko kehilangan data atau kerusakan data akibat kesalahan manusia. Dalam industri yang diatur, Anda harus meminimalkan risiko ini sebanyak mungkin.

Contoh kesalahan manusia ini meliputi:

  • Penghapusan tabel yang tidak disengaja.
  • Kerusakan data karena logika pipeline data yang salah.

Jenis kesalahan manusia ini biasanya dapat diselesaikan dengan fitur kembali ke waktu sebelumnya, yang memungkinkan Anda memulihkan data hingga tujuh hari yang lalu. Selain itu, BigQuery juga menawarkan periode fail-safe, yang selama periode tersebut data yang dihapus akan disimpan di penyimpanan fail-safe selama tujuh hari lagi setelah periode perjalanan waktu. Data tersebut tersedia untuk pemulihan bencana melalui Cloud Customer Care. Namun, jika perusahaan Anda tidak menemukan dan memperbaiki error tersebut dalam jangka waktu gabungan ini, data yang dihapus tidak dapat dipulihkan lagi dari status stabil terakhirnya.

Untuk memitigasi hal ini, sebaiknya Anda menjalankan pencadangan rutin untuk semua tabel BigQuery yang tidak dapat direkonstruksi dari data sumber (misalnya, catatan historis atau KPI dengan logika bisnis yang terus berkembang).

Perusahaan Anda dapat menggunakan skrip dasar untuk mencadangkan puluhan tabel. Namun, jika Anda perlu mencadangkan ratusan atau ribuan tabel secara rutin di seluruh organisasi, Anda memerlukan solusi otomatisasi yang skalabel yang dapat melakukan hal berikut:

  • Menangani batas API yang berbeda-beda Google Cloud .
  • Menyediakan framework standar untuk menentukan kebijakan pencadangan.
  • Menyediakan kemampuan pemantauan dan transparansi untuk operasi pencadangan.

Kebijakan pencadangan

Perusahaan Anda juga mungkin mewajibkan agar kebijakan pencadangan ditentukan oleh grup orang berikut:

  • Pemilik data, yang paling memahami tabel dan dapat menetapkan kebijakan pencadangan tingkat tabel yang sesuai.
  • Tim tata kelola data, yang memastikan bahwa kebijakan penggantian diterapkan untuk mencakup tabel yang tidak memiliki kebijakan tingkat tabel. Kebijakan penggantian memastikan bahwa set data, project, dan folder tertentu dicadangkan untuk mematuhi peraturan retensi data perusahaan Anda.

Dalam deployment untuk arsitektur referensi ini, ada dua cara untuk menentukan kebijakan pencadangan untuk tabel, dan keduanya dapat digunakan bersama-sama:

  • Konfigurasi pemilik data (terdesentralisasi): kebijakan pencadangan tingkat tabel, yang dilampirkan secara manual ke tabel.

    • Pemilik data menentukan file JSON tingkat tabel yang disimpan di bucket umum.
    • Kebijakan manual lebih diprioritaskan daripada kebijakan penggantian saat solusi menentukan kebijakan pencadangan tabel.
    • Untuk mengetahui detail dalam deployment, lihat Menetapkan kebijakan pencadangan tingkat tabel.

  • Konfigurasi default organisasi (terpusat): kebijakan penggantian, yang hanya berlaku untuk tabel yang tidak memiliki kebijakan yang dilampirkan secara manual.

    • Tim tata kelola data menentukan file JSON pusat di Terraform, sebagai bagian dari solusi.
    • Kebijakan penggantian menawarkan strategi pencadangan default di tingkat folder, project, set data, dan tabel.
    • Untuk mengetahui detail penerapan, lihat Menentukan kebijakan pencadangan penggantian.

Pencadangan versus replikasi

Proses pencadangan membuat salinan data tabel dari waktu tertentu, sehingga dapat dipulihkan jika data hilang atau rusak. Pencadangan dapat dijalankan sebagai kejadian satu kali atau berulang (melalui kueri atau alur kerja terjadwal). Di BigQuery, pencadangan pada waktu tertentu dapat dilakukan dengan snapshot. Anda dapat menggunakan snapshot untuk menyimpan salinan data di luar periode perjalanan waktu tujuh hari dalam lokasi penyimpanan yang sama dengan data sumber. Snapshot BigQuery sangat berguna untuk memulihkan data setelah terjadi kesalahan manusia yang menyebabkan kehilangan atau kerusakan data, bukan untuk memulihkan data dari kegagalan regional. BigQuery menawarkan Sasaran Tingkat Layanan (SLO) sebesar 99,9% hingga 99,99%, bergantung pada edisinya.

Sebaliknya, replikasi adalah proses berkelanjutan untuk menyalin perubahan database ke database sekunder (atau replika) di lokasi yang berbeda. Di BigQuery, replikasi lintas region dapat membantu menyediakan geo-redundansi dengan membuat salinan data hanya baca di region Google Cloud sekunder, yang berbeda dari region data sumber. Namun, replikasi lintas-region BigQuery tidak dimaksudkan untuk digunakan sebagai disaster recovery plan untuk skenario gangguan total tingkat region. Untuk ketahanan terhadap bencana regional, pertimbangkan untuk menggunakan pemulihan dari bencana yang dikelola BigQuery.

Replikasi lintas region BigQuery menyediakan salinan data hanya baca yang disinkronkan di region yang dekat dengan konsumen data. Salinan data ini memungkinkan gabungan yang ditempatkan bersama dan menghindari traffic serta biaya lintas region. Namun, dalam kasus kerusakan data akibat kesalahan manusia, replikasi saja tidak dapat membantu pemulihan, karena data yang rusak otomatis disalin ke replika. Dalam kasus seperti ini, cadangan point-in-time (snapshot) adalah pilihan yang lebih baik.

Tabel berikut menunjukkan ringkasan perbandingan metode pencadangan dan replikasi:

Metode Frekuensi Lokasi penyimpanan Kasus penggunaan Biaya
Pencadangan

(Snapshot atau ekspor Cloud Storage)		 Satu kali atau berulang Sama seperti data tabel sumber Memulihkan data asli, di luar periode perjalanan waktu Snapshot dikenai biaya penyimpanan untuk perubahan data dalam snapshot saja

Ekspor dapat dikenai biaya penyimpanan standar

Lihat Pengoptimalan biaya
Replikasi lintas-region Terus-menerus Eksternal Membuat replika di region lain

Migrasi satu kali antar-region		 Menimbulkan biaya untuk menyimpan data di replika

Menimbulkan biaya replikasi data

Pertimbangan desain

Bagian ini memberikan panduan yang perlu Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan spesifik Anda terkait keamanan, keandalan, pengoptimalan biaya, efisiensi operasional, dan performa.

Keamanan, privasi, dan kepatuhan

Deployment ini menggabungkan tindakan keamanan berikut dalam desain dan penerapannya:

  • Setelan ingress jaringan untuk Cloud Run hanya menerima traffic internal, untuk membatasi akses dari internet. Hal ini juga memungkinkan hanya pengguna dan akun layanan terautentikasi yang dapat memanggil layanan.
  • Setiap layanan Cloud Run dan langganan Pub/Sub menggunakan akun layanan terpisah, yang hanya memiliki izin yang diperlukan yang ditetapkan untuknya. Tindakan ini mengurangi risiko yang terkait dengan penggunaan satu akun layanan untuk sistem dan mengikuti prinsip hak istimewa terendah.

Untuk pertimbangan privasi, solusi ini tidak mengumpulkan atau memproses informasi identitas pribadi (PII). Namun, jika tabel sumber telah mengekspos PII, cadangan yang diambil dari tabel tersebut juga menyertakan data yang terekspos ini. Pemilik data sumber bertanggung jawab untuk melindungi PII apa pun dalam tabel sumber (misalnya, dengan menerapkan keamanan tingkat kolom, penyamaran data, atau penyensoran). Cadangan hanya aman jika data sumber diamankan. Pendekatan lainnya adalah memastikan bahwa project, set data, atau bucket yang menyimpan data cadangan dengan PII yang terekspos memiliki kebijakan Identity and Access Management (IAM) yang diperlukan yang membatasi akses hanya untuk pengguna yang diberi otorisasi.

Sebagai solusi serbaguna, deployment referensi tidak selalu mematuhi persyaratan khusus industri tertentu.

Keandalan

Bagian ini menjelaskan fitur dan pertimbangan desain untuk keandalan.

Mitigasi kegagalan dengan perincian

Untuk mencadangkan ribuan tabel, kemungkinan Anda akan mencapai batas API untuk produk yang mendasarinya (misalnya, batas operasi snapshot dan ekspor untuk setiap project). Google Cloud Namun, jika pencadangan satu tabel gagal karena kesalahan konfigurasi atau masalah sementara lainnya, hal itu tidak akan memengaruhi eksekusi keseluruhan dan kemampuan untuk mencadangkan tabel lain.

Untuk mengurangi potensi kegagalan, deployment referensi memisahkan langkah-langkah pemrosesan dengan menggunakan layanan Cloud Run yang terperinci dan menghubungkannya melalui Pub/Sub. Jika permintaan pencadangan tabel gagal pada langkah layanan penanda akhir, Pub/Sub hanya akan mencoba kembali langkah ini dan tidak akan mencoba kembali seluruh proses.

Memecah alur menjadi beberapa layanan Cloud Run, bukan beberapa endpoint yang dihosting di satu layanan Cloud Run, akan membantu memberikan kontrol terperinci atas setiap konfigurasi layanan. Tingkat konfigurasi bergantung pada kemampuan layanan dan API yang berkomunikasi dengannya. Misalnya, layanan dispatcher dijalankan sekali per proses, tetapi memerlukan waktu yang cukup lama untuk mencantumkan semua tabel dalam cakupan pencadangan BigQuery. Oleh karena itu, layanan dispatcher memerlukan setelan waktu tunggu dan memori yang lebih tinggi. Namun, layanan Cloud Run untuk snapshot BigQuery dieksekusi sekali per tabel dalam satu kali eksekusi, dan selesai dalam waktu yang lebih singkat daripada layanan dispatcher. Oleh karena itu, layanan Cloud Run memerlukan serangkaian konfigurasi yang berbeda di tingkat layanan.

Konsistensi data

Konsistensi data di seluruh tabel dan tampilan sangat penting untuk mempertahankan strategi pencadangan yang andal. Karena data terus diperbarui dan dimodifikasi, cadangan yang diambil pada waktu yang berbeda dapat merekam status set data yang berbeda. Pencadangan dalam berbagai status ini dapat menyebabkan inkonsistensi saat Anda memulihkan data, terutama untuk tabel yang termasuk dalam set data fungsional yang sama. Misalnya, memulihkan tabel penjualan ke titik waktu yang berbeda dengan tabel inventaris yang sesuai dapat menyebabkan ketidakcocokan dalam stok yang tersedia. Demikian pula, tampilan database yang menggabungkan data dari beberapa tabel dapat sangat rentan terhadap inkonsistensi. Memulihkan tampilan ini tanpa memastikan bahwa tabel pokok berada dalam status yang konsisten dapat menyebabkan hasil yang tidak akurat atau menyesatkan. Oleh karena itu, saat mendesain kebijakan dan frekuensi pencadangan BigQuery, Anda harus mempertimbangkan konsistensi ini dan memastikan bahwa data yang dipulihkan mencerminkan secara akurat status set data Anda di dunia nyata pada waktu tertentu.

Misalnya, dalam deployment untuk arsitektur referensi ini, konsistensi data dikontrol melalui dua konfigurasi berikut dalam kebijakan pencadangan. Konfigurasi ini menghitung waktu snapshot tabel yang tepat melalui perjalanan waktu, tanpa harus mencadangkan semua tabel secara bersamaan.

  • backup_cron: Mengontrol frekuensi pencadangan tabel. Stempel waktu mulai proses digunakan sebagai titik referensi untuk perhitungan perjalanan waktu bagi semua tabel yang dicadangkan dalam proses ini.
  • backup_time_travel_offset_days: Mengontrol jumlah hari di masa lalu yang harus dikurangi dari titik referensi waktu (waktu mulai operasi), untuk menghitung versi tabel yang tepat untuk perjalanan waktu.

Pemulihan cadangan otomatis

Meskipun arsitektur referensi ini berfokus pada otomatisasi pencadangan dalam skala besar, Anda juga dapat mempertimbangkan untuk memulihkan cadangan ini secara otomatis. Otomatisasi tambahan ini dapat memberikan manfaat serupa dengan otomatisasi pencadangan, termasuk peningkatan efisiensi dan kecepatan pemulihan, dengan waktu henti yang lebih singkat. Karena solusi ini melacak semua parameter dan hasil pencadangan melalui layanan tagger, Anda dapat mengembangkan arsitektur serupa untuk menerapkan operasi pemulihan dalam skala besar.

Misalnya, Anda dapat membuat solusi berdasarkan pemicu sesuai permintaan yang mengirim cakupan data BigQuery ke layanan pengirim, yang mengirim satu permintaan per tabel ke layanan konfigurasi. Layanan konfigurasi dapat mengambil histori pencadangan yang Anda inginkan untuk tabel tertentu. Layanan konfigurasi kemudian dapat meneruskannya ke layanan pemulihan snapshot BigQuery atau layanan pemulihan Cloud Storage untuk menerapkan operasi pemulihan yang sesuai. Terakhir, layanan penanda dapat menyimpan hasil operasi ini di penyimpanan status. Dengan demikian, framework pemulihan otomatis dapat memanfaatkan tujuan desain yang sama dengan framework pencadangan yang dijelaskan dalam dokumen ini.

Pengoptimalan biaya

Framework arsitektur ini menyediakan kebijakan pencadangan yang menetapkan parameter berikut untuk pengoptimalan biaya secara keseluruhan:

  • Metode pencadangan: Framework menawarkan dua metode pencadangan berikut:
    • Snapshot BigQuery, yang menimbulkan biaya penyimpanan berdasarkan data yang diupdate dan dihapus dibandingkan dengan tabel dasar. Oleh karena itu, snapshot lebih hemat biaya untuk tabel yang hanya dapat ditambahkan atau memiliki update terbatas.
    • Ekspor BigQuery ke Cloud Storage, yang dikenai biaya penyimpanan standar. Namun, untuk tabel besar yang mengikuti pendekatan potong dan muat, lebih hemat biaya untuk mencadangkan tabel tersebut sebagai ekspor dalam kelas penyimpanan yang lebih murah.
  • Masa berlaku snapshot: Time to live (TTL) ditetapkan untuk satu snapshot tabel, untuk menghindari biaya penyimpanan snapshot tanpa batas waktu. Biaya penyimpanan dapat meningkat seiring waktu jika tabel tidak memiliki masa berlaku.

Efisiensi operasional

Bagian ini menjelaskan fitur dan pertimbangan untuk efisiensi operasional.

Kebijakan pencadangan yang terperinci dan skalabel

Salah satu tujuan framework ini adalah efisiensi operasional dengan meningkatkan hasil bisnis sekaligus menjaga input bisnis tetap relatif rendah dan mudah dikelola. Misalnya, outputnya adalah sejumlah besar tabel yang dicadangkan secara rutin, sedangkan inputnya adalah sejumlah kecil kebijakan dan konfigurasi pencadangan yang dipertahankan.

Selain mengizinkan kebijakan pencadangan di tingkat tabel, framework ini juga mengizinkan kebijakan di tingkat set data, project, folder, dan global. Artinya, dengan beberapa konfigurasi di tingkat yang lebih tinggi (misalnya, tingkat folder atau project), ratusan atau ribuan tabel dapat dicadangkan secara rutin dalam skala besar.

Kemampuan observasi

Dengan framework otomatisasi, Anda harus memahami status proses. Misalnya, Anda akan dapat menemukan informasi untuk kueri umum berikut:

  • Kebijakan pencadangan yang digunakan oleh sistem untuk setiap tabel.
  • Histori pencadangan dan lokasi pencadangan setiap tabel.
  • Status keseluruhan satu proses (jumlah tabel yang diproses dan tabel yang gagal).
  • Error fatal yang terjadi dalam satu kali proses, dan komponen atau langkah-langkah proses yang menyebabkan error tersebut.

Untuk memberikan informasi ini, deployment menulis log terstruktur ke Cloud Logging di setiap langkah eksekusi yang menggunakan layanan Cloud Run. Log mencakup input, output, dan error, beserta titik pemeriksaan progres lainnya. Sink log merutekan log ini ke tabel BigQuery. Anda dapat menjalankan sejumlah kueri untuk memantau eksekusi dan mendapatkan laporan untuk kasus penggunaan kemampuan pengamatan umum. Untuk mengetahui informasi selengkapnya tentang log dan kueri di BigQuery, lihat artikel Melihat log yang dirutekan ke BigQuery.

Pengoptimalan performa

Untuk menangani ribuan tabel di setiap proses, solusi ini memproses permintaan pencadangan secara paralel. Layanan dispatcher mencantumkan semua tabel yang disertakan dalam cakupan pencadangan BigQuery dan membuat satu permintaan pencadangan per tabel pada setiap proses. Hal ini memungkinkan aplikasi memproses ribuan permintaan dan tabel secara paralel, bukan berurutan.

Beberapa permintaan ini mungkin awalnya gagal karena alasan sementara seperti mencapai batas API Google Cloud dasar atau mengalami masalah jaringan. Hingga permintaan selesai, Pub/Sub akan otomatis mencoba lagi permintaan dengan kebijakan percobaan ulang backoff eksponensial. Jika ada error fatal seperti tujuan pencadangan yang tidak valid atau izin yang tidak ada, error akan dicatat dan eksekusi permintaan tabel tertentu tersebut akan dihentikan tanpa memengaruhi keseluruhan proses.

Batas

Kuota dan batasan berikut berlaku untuk arsitektur ini.

Untuk snapshot tabel, hal berikut berlaku untuk setiap project operasi pencadangan yang Anda tentukan:

  • Satu project dapat menjalankan hingga 100 tugas snapshot tabel serentak.
  • Satu project dapat menjalankan hingga 50.000 tugas snapshot tabel per hari.
  • Satu project dapat menjalankan hingga 50 tugas snapshot tabel per tabel per hari.

Untuk mengetahui detailnya, lihat Snapshot tabel.

Untuk tugas ekspor (ekspor ke Cloud Storage), hal berikut berlaku:

  • Anda dapat mengekspor hingga 50 TiB data per hari dari sebuah project secara gratis, dengan menggunakan gabungan slot bersama.
  • Satu project dapat menjalankan hingga 100.000 ekspor per hari. Untuk memperpanjang batas ini, buat pemesanan slot.

Untuk mengetahui informasi selengkapnya tentang cara memperpanjang batas ini, lihat Tugas ekspor.

Mengenai batas serentak, arsitektur ini menggunakan Pub/Sub untuk mencoba ulang permintaan yang gagal secara otomatis karena batas ini, hingga permintaan tersebut ditayangkan oleh API. Namun, untuk batas lain pada jumlah operasi per project per hari, hal ini dapat diatasi dengan permintaan penambahan kuota, atau dengan menyebarkan operasi pencadangan (snapshot atau ekspor) ke beberapa project. Untuk menyebarkan operasi di seluruh project, konfigurasi kebijakan pencadangan seperti yang dijelaskan di bagian deployment berikut:

Deployment

Untuk men-deploy arsitektur ini, lihat Men-deploy otomatisasi pencadangan BigQuery yang skalabel.

Langkah berikutnya

Kontributor

Penulis: Karim Wadie | Strategic Cloud Engineer

Kontributor lainnya: