Kasus penggunaan pemulihan dari bencana: aplikasi analisis data yang dibatasi lokalitas

Last reviewed 2022-01-07 UTC

Dokumen ini adalah bagian dari rangkaian yang membahas pemulihan bencana (DR) di Google Cloud. Dokumen ini menjelaskan cara menerapkan pembatasan lokalitas dari dokumen, Merancang pemulihan bencana untuk beban kerja yang dibatasi lokalitas, ke aplikasi analisis data. Secara khusus, dokumen ini menjelaskan bagaimana komponen yang Anda gunakan di platform analisis data cocok dengan arsitektur DR yang memenuhi batasan lokalitas yang mungkin tunduk pada aplikasi atau data Anda.

Rangkaian ini terdiri dari bagian berikut:

Dokumen ini ditujukan untuk arsitek sistem dan manajer IT. Hal ini mengasumsikan bahwa Anda memiliki pengetahuan dan keterampilan berikut:

Persyaratan lokalitas untuk platform analisis data

Platform analitik data biasanya merupakan aplikasi berlapis dan kompleks yang menyimpan data dalam penyimpanan. Aplikasi ini menghasilkan peristiwa yang diproses dan disimpan dalam sistem analisis Anda. Aplikasi itu sendiri dan data yang disimpan dalam sistem mungkin tunduk pada peraturan lokalitas. Peraturan ini bervariasi tidak hanya di seluruh negara, tetapi juga lintas vertical industri. Oleh karena itu, Anda harus memiliki pemahaman yang jelas tentang persyaratan lokalitas data sebelum mulai mendesain arsitektur DR.

Anda dapat menentukan apakah platform analisis data Anda memiliki persyaratan lokalitas dengan menjawab dua pertanyaan berikut:

  • Apakah aplikasi Anda perlu di-deploy ke region tertentu?
  • Apakah data dalam penyimpanan Anda dibatasi untuk region tertentu?

Jika Anda menjawab "tidak" untuk kedua pertanyaan tersebut, platform analisis data Anda tidak memiliki persyaratan spesifik per lokalitas. Karena platform Anda tidak memiliki persyaratan lokalitas, ikuti panduan DR untuk layanan dan produk yang mematuhi kebijakan yang diuraikan dalam Panduan perencanaan pemulihan dari bencana.

Namun, jika Anda menjawab "ya" untuk salah satu pertanyaan, berarti aplikasi Anda dibatasi lokalitas. Karena platform analisis Anda dibatasi oleh lokalitas, Anda harus mengajukan pertanyaan berikut: Dapatkah Anda menggunakan teknik enkripsi untuk mengurangi persyaratan data dalam penyimpanan?

Jika dapat menggunakan teknik enkripsi, Anda dapat menggunakan layanan multi-regional dan dual-regional dari Cloud External Key Manager dan Cloud Key Management Service. Anda juga dapat mengikuti teknik ketersediaan tinggi dan pemulihan dari bencana (HA/DR) standar yang dijelaskan dalam Skenario pemulihan dari bencana untuk data.

Jika tidak dapat menggunakan teknik enkripsi, Anda harus menggunakan solusi kustom atau penawaran partner untuk perencanaan DR. Untuk informasi selengkapnya tentang teknik mengatasi pembatasan lokalitas untuk skenario DR, lihat Merancang pemulihan bencana untuk beban kerja yang dibatasi lokalitas.

Komponen di platform analitik data

Saat memahami persyaratan lokalitas, langkah berikutnya adalah memahami komponen yang digunakan platform analisis data Anda. Beberapa komponen umum platform analisis data adalah database, data lake, pipeline pemrosesan, dan data warehouse, seperti yang dijelaskan dalam daftar berikut:

  • Google Cloud memiliki serangkaian layanan database yang sesuai dengan berbagai kasus penggunaan.
  • Data lake, data warehouse, dan pipeline pemrosesan dapat memiliki definisi yang sedikit berbeda. Dokumen ini menggunakan serangkaian definisi yang merujuk ke layanan Google Cloud:
    • Data lake adalah platform yang skalabel dan aman untuk menyerap dan menyimpan data dari beberapa sistem. Data lake standar mungkin menggunakan Cloud Storage sebagai repositori penyimpanan pusat.
    • Pipeline pemrosesan adalah proses menyeluruh yang mengambil data atau peristiwa dari satu atau beberapa sistem, mengubah data atau peristiwa tersebut, dan memuatnya ke sistem lain. Pipeline dapat mengikuti proses ekstrak, transformasi, dan muat (ETL) atau ekstrak, pemuatan, dan transformasi (ELT). Biasanya, sistem tempat data yang diproses dimuat adalah data warehouse. Pub/Sub, Dataflow, dan Dataproc adalah komponen yang umum digunakan dari pipeline pemrosesan.
    • Data warehouse adalah sistem perusahaan yang digunakan untuk analisis dan pelaporan data, yang biasanya berasal dari database operasional. BigQuery adalah sistem data warehouse yang umum digunakan dan berjalan di Google Cloud.

Bergantung pada persyaratan lokalitas dan komponen analisis data yang Anda gunakan, penerapan DR yang sebenarnya bervariasi. Bagian berikut menunjukkan variasi ini dengan dua kasus penggunaan.

Kasus penggunaan batch: tugas ETL berkala

Kasus penggunaan pertama menjelaskan suatu proses batch, yaitu ketika platform retail mengumpulkan peristiwa penjualan secara berkala sebagai file dari berbagai toko, lalu menulis file tersebut ke bucket Cloud Storage. Diagram berikut menggambarkan arsitektur analisis data untuk tugas batch retailer ini.

Diagram arsitektur kasus penggunaan batch yang melibatkan data tempat penjualan.

Arsitektur ini mencakup fase dan komponen berikut:

  • Fase penyerapan terdiri dari toko yang mengirimkan data tempat penjualan (POS) ke Cloud Storage. Data yang diserap ini menunggu pemrosesan.
  • Fase orkestrasi menggunakan Cloud Composer untuk mengorkestrasi pipeline batch menyeluruh.
  • Fase pemrosesan melibatkan tugas Apache Spark yang berjalan di cluster Dataproc. Tugas Apache Spark menjalankan proses ETL pada data yang diserap. Proses ETL ini menyediakan metrik bisnis.
  • Fase data lake mengambil data yang diproses dan menyimpan informasi dalam komponen berikut:
    • Data yang diproses biasanya disimpan dalam format kolom Cloud Storage sepertiParquet dan ORC karena format ini memungkinkan penyimpanan yang efisien dan akses yang lebih cepat untuk workload analisis.
    • Metadata tentang data proses (seperti database, tabel, kolom, dan partisi) disimpan di layanan metastore Hive yang disediakan oleh Dataproc Metastore.

Dalam skenario yang dibatasi lokalitas, mungkin akan sulit untuk menyediakan kapasitas pemrosesan dan orkestrasi yang redundan untuk mempertahankan ketersediaan. Karena data diproses dalam batch, pipeline pemrosesan dan orkestrasi dapat dibuat ulang, dan tugas batch dapat dimulai ulang setelah skenario bencana diselesaikan. Oleh karena itu, untuk pemulihan dari bencana, fokus utamanya adalah memulihkan data aktual: data POS yang diserap, data yang diproses yang disimpan di data lake, dan metadata yang disimpan di data lake.

Penyerapan ke Cloud Storage

Pertimbangan pertama Anda adalah persyaratan lokalitas untuk bucket Cloud Storage yang digunakan untuk menyerap data dari sistem POS. Gunakan informasi lokalitas ini saat mempertimbangkan opsi berikut:

  • Jika persyaratan lokalitas mengizinkan data dalam penyimpanan berada di salah satu lokasi multi-region atau dual-region, pilih jenis lokasi yang sesuai saat Anda membuat bucket Cloud Storage. Jenis lokasi yang Anda pilih menentukan region Google Cloud yang digunakan untuk mereplikasi data dalam penyimpanan. Jika terjadi pemadaman di salah satu region, data yang berada di bucket multi-region atau dual-region masih dapat diakses.
  • Cloud Storage juga mendukung kunci enkripsi yang dikelola pelanggan (CMEK) dan kunci enkripsi yang disediakan pelanggan (CSEK). Beberapa aturan lokalitas memungkinkan data dalam penyimpanan disimpan di beberapa lokasi saat Anda menggunakan CMEK atau CSEK untuk pengelolaan kunci. Jika aturan lokalitas Anda mengizinkan penggunaan CMEK atau CSEK, Anda dapat mendesain arsitektur DR untuk menggunakan region Cloud Storage.
  • Persyaratan lokalitas Anda mungkin tidak mengizinkan Anda menggunakan jenis lokasi atau pengelolaan kunci enkripsi. Jika tidak dapat menggunakan jenis lokasi atau pengelolaan kunci enkripsi, Anda dapat menggunakan perintah gsutil rsync untuk menyinkronkan data ke lokasi lain, seperti solusi penyimpanan atau penyimpanan lokal dari penyedia cloud lain.

Jika terjadi bencana, data POS yang diserap di bucket Cloud Storage mungkin memiliki data yang belum diproses dan diimpor ke data lake. Atau, data POS mungkin tidak dapat diserap ke dalam bucket Cloud Storage. Untuk kasus ini, Anda memiliki opsi pemulihan dari bencana berikut:

  • Biarkan sistem POS mencoba lagi. Jika sistem tidak dapat menulis data POS ke Cloud Storage, proses penyerapan data akan gagal. Untuk mengurangi situasi ini, Anda dapat menerapkan algoritma backoff eksponensial terpotong agar sistem POS dapat mencoba kembali operasi penyerapan data. Karena Cloud Storage memberikan ketahanan dengan sebelas 9, penyerapan data dan pipeline pemrosesan berikutnya akan dilanjutkan dengan sedikit atau tanpa kehilangan data setelah layanan Cloud Storage dilanjutkan singkat ini.

  • Membuat salinan data yang diserap. Cloud Storage mendukung jenis lokasi multi-region dan dual-region. Bergantung pada persyaratan lokalitas data, Anda mungkin dapat menyiapkan bucket Cloud Storage multi-region atau dual-region untuk meningkatkan ketersediaan data. Anda juga dapat menggunakan alat seperti gsutil untuk menyinkronkan data antara Cloud Storage dan lokasi lain.

Orkestrasi dan pemrosesan data POS yang diserap

Dalam diagram arsitektur untuk kasus penggunaan batch, Cloud Composer melakukan langkah-langkah berikut:

  • Memvalidasi bahwa file baru telah diupload ke bucket penyerapan Cloud Storage.
  • Memulai cluster Dataproc efemeral.
  • Memulai tugas Apache Spark untuk memproses data.
  • Menghapus cluster Dataproc di akhir tugas.

Cloud Composer menggunakan file grafik asiklik terarah (DAG) yang menentukan rangkaian langkah ini. File DAG ini disimpan di bucket Cloud Storage yang tidak ditampilkan dalam diagram arsitektur. Dalam hal lokalitas dual-region dan multi-region, pertimbangan DR untuk bucket file DAG sama dengan yang dibahas untuk bucket penyerapan.

Cluster Dataproc bersifat sementara. Artinya, cluster hanya ada selama tahap pemrosesan berjalan. Sifatnya yang singkat ini berarti Anda tidak perlu secara eksplisit melakukan apa pun untuk DR sehubungan dengan cluster Dataproc.

Penyimpanan data lake dengan Cloud Storage

Bucket Cloud Storage yang Anda gunakan untuk data lake memiliki pertimbangan lokalitas yang sama seperti yang dibahas untuk bucket penyerapan: pertimbangan dual-region dan multi-region, penggunaan enkripsi, dan penggunaan gsutil rsync.

Saat mendesain rencana DR untuk data lake Anda, pikirkan aspek-aspek berikut:

  • Ukuran data. Volume data di data lake bisa besar. Pemulihan data dalam jumlah besar memerlukan waktu. Dalam skenario DR, Anda perlu mempertimbangkan dampak volume data lake terhadap jumlah waktu yang diperlukan
    untuk memulihkan data ke titik yang memenuhi kriteria berikut:

    Untuk kasus penggunaan batch saat ini, Cloud Storage digunakan untuk lokasi data lake dan memberikan ketahanan sebesar 99,999%. Namun, serangan ransomware semakin meningkat. Untuk memastikan Anda memiliki kemampuan untuk pulih dari serangan tersebut, sebaiknya ikuti praktik terbaik yang dijelaskan dalam artikel Cara Cloud Storage memberikan ketahanan 99,999%.

  • Dependensi data. Data di data lake biasanya digunakan oleh komponen lain dari sistem analisis data seperti pipeline pemrosesan. Dalam skenario DR, pipeline pemrosesan dan data yang menjadi dependensinya harus memiliki RTO yang sama. Dalam konteks ini, fokus pada berapa lama Anda dapat membuat sistem tidak tersedia.

  • Usia data. Data historis mungkin memungkinkan RPO yang lebih tinggi. Jenis data ini mungkin telah dianalisis atau diproses oleh komponen analisis data lain dan mungkin telah dipertahankan di komponen lain yang memiliki strategi DR sendiri. Misalnya, catatan penjualan yang diekspor ke Cloud Storage diimpor setiap hari ke BigQuery untuk dianalisis. Dengan strategi DR yang tepat untuk BigQuery, data penjualan historis yang telah diimpor ke BigQuery mungkin memiliki tujuan pemulihan yang lebih rendah daripada catatan penjualan yang belum diimpor.

Penyimpanan metadata data lake dengan Dataproc Metastore

Dataproc Metastore adalah metastore Apache Hive yang terkelola sepenuhnya, sangat tersedia, autohealing, dan tanpa server. Metastore menyediakan fitur abstraksi data dan penemuan data. Metastore dapat dicadangkan dan dipulihkan jika terjadi bencana. Layanan Dataproc Metastore juga memungkinkan Anda mengekspor dan import metadata. Anda dapat menambahkan tugas untuk mengekspor metastore dan mempertahankan cadangan eksternal bersama dengan tugas ETL.

Jika menemukan ketidakcocokan metadata, Anda dapat membuat ulang metastore dari data itu sendiri menggunakan perintah MSCK.

Kasus penggunaan streaming: mengubah pengambilan data menggunakan ELT

Kasus penggunaan kedua menjelaskan platform retail yang menggunakan pengambilan data perubahan (CDC) untuk mengupdate sistem inventaris backend dan melacak metrik penjualan real-time. Diagram berikut menunjukkan arsitektur yang digunakan untuk memproses peristiwa dari database transaksional, seperti Cloud SQL, yang diproses lalu disimpan di data warehouse.

Diagram arsitektur kasus penggunaan streaming yang melibatkan perubahan pengambilan data dari data retail.

Arsitektur ini mencakup fase dan komponen berikut:

  • Fase penyerapan terdiri dari peristiwa perubahan yang masuk yang dikirim ke Pub/Sub. Sebagai layanan pengiriman pesan, Pub/Sub digunakan untuk menyerap dan mendistribusikan data analisis streaming secara andal. Pub/Sub memiliki manfaat tambahan, yaitu skalabel dan serverless.
  • Fase pemrosesan melibatkan penggunaan Dataflow untuk menjalankan proses ELT pada peristiwa yang diserap.
  • Fase data warehouse menggunakan BigQuery untuk menyimpan peristiwa yang diproses. Operasi penggabungan akan menyisipkan atau memperbarui data di BigQuery. Dengan operasi ini, informasi yang tersimpan di BigQuery dapat terus diperbarui dengan database transaksional.

Meskipun arsitektur CDC ini tidak mengandalkan Cloud Composer, beberapa arsitektur CDC memerlukan Cloud Composer untuk mengatur integrasi streaming ke dalam beban kerja batch. Dalam kasus tersebut, alur kerja Cloud Composer menerapkan pemeriksaan integritas, pengisian ulang, dan proyeksi yang tidak dapat dilakukan secara real time karena batasan latensi. Teknik DR untuk Cloud Composer dibahas dalam kasus penggunaan batch processing yang dibahas sebelumnya dalam dokumen.

Untuk pipeline data streaming, Anda harus mempertimbangkan hal-hal berikut saat merencanakan arsitektur DR:

  • Dependensi pipeline. Pipeline pemrosesan mengambil input dari satu atau beberapa sistem (sumber). Pipeline kemudian memproses, mengubah, dan menyimpan input ini ke dalam beberapa sistem lain (sink). Penting untuk merancang arsitektur DR guna mencapai RTO secara menyeluruh. Anda harus memastikan bahwa RPO sumber data dan sink memungkinkan Anda memenuhi RTO. Selain mendesain arsitektur cloud untuk memenuhi persyaratan lokalitas, Anda juga harus mendesain sumber CDC asal agar RTO menyeluruh dapat terpenuhi.
  • Enkripsi dan lokalitas. Jika enkripsi memungkinkan Anda mengurangi pembatasan lokalitas, Anda dapat menggunakan Cloud KMS untuk mencapai tujuan berikut:
    • Mengelola kunci enkripsi Anda sendiri.
    • Memanfaatkan kemampuan enkripsi setiap layanan.
    • Deploy layanan di region yang tidak akan tersedia untuk digunakan karena pembatasan lokalitas.
  • Aturan lokalitas terkait data yang bergerak. Beberapa aturan lokalitas mungkin hanya berlaku untuk data dalam penyimpanan, tetapi tidak untuk data yang bergerak. Jika aturan lokalitas Anda tidak berlaku untuk data yang bergerak, desain arsitektur DR Anda untuk memanfaatkan resource di region lain untuk meningkatkan tujuan pemulihan. Anda dapat melengkapi pendekatan regional dengan mengintegrasikan teknik enkripsi.

Penyerapan ke Pub/Sub

Jika tidak memiliki pembatasan lokalitas, Anda dapat memublikasikan pesan ke endpoint Pub/Sub global. Endpoint Pub/Sub global dapat dilihat dan diakses dari lokasi Google Cloud mana pun.

Jika persyaratan lokalitas Anda memungkinkan penggunaan enkripsi, Anda dapat mengonfigurasi Pub/Sub untuk mencapai tingkat ketersediaan tinggi yang serupa dengan endpoint global. Meskipun pesan Pub/Sub dienkripsi dengan kunci yang dikelola Google secara default, Anda dapat mengonfigurasi Pub/Sub untuk menggunakan CMEK. Dengan menggunakan Pub/Sub dengan CMEK, Anda dapat memenuhi aturan lokalitas tentang enkripsi sambil tetap mempertahankan ketersediaan tinggi.

Beberapa aturan lokalitas mengharuskan pesan tetap berada di lokasi tertentu bahkan setelah enkripsi. Jika aturan lokalitas Anda memiliki batasan ini, Anda dapat menentukan kebijakan penyimpanan pesan topik Pub/Sub dan membatasinya ke sebuah region. Jika Anda menggunakan pendekatan penyimpanan pesan ini, pesan yang dipublikasikan ke topik tidak akan pernah dipertahankan di luar kumpulan region Google Cloud yang Anda tentukan. Jika aturan lokalitas Anda mengizinkan lebih dari satu region Google Cloud untuk digunakan, Anda dapat meningkatkan ketersediaan layanan dengan mengaktifkan region tersebut dalam topik Pub/Sub. Anda perlu memahami bahwa menerapkan kebijakan penyimpanan pesan untuk membatasi lokasi resource Pub/Sub memang menimbulkan konsekuensi terkait ketersediaan.

Dengan langganan Pub/Sub, Anda dapat menyimpan pesan yang tidak terkonfirmasi hingga 7 hari tanpa batasan jumlah pesan. Jika perjanjian tingkat layanan memungkinkan data tertunda, Anda dapat mem-buffer data dalam langganan Pub/Sub jika pipeline berhenti berjalan. Saat pipeline berjalan lagi, Anda dapat memproses peristiwa yang dicadangkan. Desain ini memiliki keuntungan karena memiliki RPO yang rendah. Untuk mengetahui informasi selengkapnya tentang batas resource untuk Pub/Sub, lihat batas resource untuk kuota Pub/Sub.

Pemrosesan peristiwa dengan Dataflow

Dataflow adalah layanan terkelola untuk menjalankan berbagai macam pola pemrosesan data. Apache Beam SDK adalah model pemrograman open source yang memungkinkan Anda mengembangkan pipeline batch dan streaming. Anda membuat pipeline dengan program Apache Beam dan kemudian menjalankannya di layanan Dataflow.

Saat mendesain untuk pembatasan lokalitas, Anda perlu mempertimbangkan lokasi sumber, sink, dan file sementara. Jika lokasi file ini berada di luar region pekerjaan Anda, data Anda mungkin dikirim ke berbagai region. Jika aturan lokalitas Anda mengizinkan pemrosesan data di lokasi yang berbeda, desain arsitektur DR Anda untuk men-deploy pekerja di region Google Cloud lain guna memberikan ketersediaan tinggi.

Jika batasan lokalitas membatasi pemrosesan ke satu lokasi, Anda dapat membuat tugas Dataflow yang dibatasi untuk region atau zona tertentu. Saat mengirimkan tugas Dataflow, Anda dapat menentukan parameter endpoint regional, region pekerja, dan zona pekerja. Parameter ini mengontrol tempat pekerja di-deploy dan tempat penyimpanan metadata tugas.

Apache Beam menyediakan framework yang memungkinkan pipeline dijalankan di berbagai runner. Anda dapat mendesain arsitektur DR untuk memanfaatkan kemampuan ini. Misalnya, Anda dapat mendesain arsitektur DR agar memiliki pipeline cadangan yang berjalan pada cluster Spark lokal menggunakan Apache Spark Runner. Untuk mengetahui informasi tentang apakah runner tertentu mampu melakukan operasi pipeline tertentu, lihat Matriks Kemampuan Balok.

Jika enkripsi memungkinkan Anda memitigasi pembatasan lokalitas, Anda dapat menggunakan CMEK di Dataflow untuk mengenkripsi artefak status pipeline, serta mengakses sumber dan sink yang dilindungi dengan kunci Cloud KMS singkat ini. Dengan enkripsi, Anda dapat mendesain arsitektur DR menggunakan region yang tidak akan tersedia karena pembatasan lokalitas.

Data warehouse yang dibangun di BigQuery

Data warehouse mendukung analisis dan pengambilan keputusan. Selain berisi database analitis, data warehouse berisi banyak komponen dan prosedur analisis.

Saat mendesain rencana DR untuk data warehouse, pikirkan karakteristik berikut:

  • Ukuran. Data warehouse jauh lebih besar daripada sistem pemrosesan transaksi online (OLTP). Bukan hal aneh bagi data warehouse untuk memiliki data berukuran terabyte hingga petabyte. Anda perlu mempertimbangkan berapa lama waktu yang diperlukan untuk memulihkan data ini guna mencapai nilai RPO dan RTO. Saat merencanakan strategi DR, Anda juga harus memperhitungkan biaya yang terkait dengan pemulihan data terabita. Guna mengetahui informasi selengkapnya tentang teknik mitigasi DR untuk BigQuery, baca informasi BigQuery di bagian mekanisme pencadangan dan pemulihan untuk layanan database terkelola di Google Cloud.

  • Ketersediaan.  Saat membuat set data BigQuery, Anda memilih lokasi untuk menyimpan data: regional atau multi-region. Lokasi regional adalah lokasi geografis tunggal yang spesifik, seperti Iowa (us-central1) atau Montréal (northamerica-northeast1). Lokasi multi-region adalah area geografis yang luas, seperti Amerika Serikat (AS) atau Eropa (EU), yang berisi dua tempat geografis atau lebih.

    Saat mendesain rencana DR untuk memenuhi batasan lokalitas, domain kegagalan (yaitu, apakah kegagalan terjadi di tingkat mesin, zona, atau regional) akan berdampak langsung pada Anda dalam memenuhi RTO yang Anda tentukan. Untuk mengetahui informasi selengkapnya tentang domain gagal ini dan pengaruhnya terhadap ketersediaan, lihat Ketersediaan dan ketahanan BigQuery.

  • Sifat data. Data warehouse berisi informasi historis, dan sebagian besar data lama sering kali bersifat statis. Banyak data warehouse yang didesain agar bersifat khusus penambahan. Jika data warehouse Anda bersifat khusus tambahan, Anda mungkin dapat mencapai RTO dengan memulihkan data yang sedang ditambahkan saja. Dalam pendekatan ini, Anda hanya mencadangkan data yang ditambahkan ini. Jika terjadi bencana, Anda dapat memulihkan data yang ditambahkan dan menyediakan data warehouse untuk digunakan, tetapi dengan subset data.

  • Pola pembaruan dan penambahan data. Data warehouse biasanya diperbarui menggunakan pola ETL atau ELT. Setelah mengontrol jalur update, Anda dapat mereproduksi peristiwa update terbaru dari sumber alternatif.

Persyaratan lokalitas Anda mungkin membatasi apakah Anda dapat menggunakan satu region atau beberapa region untuk data warehouse. Meskipun set data BigQuery dapat bersifat regional, penyimpanan multi-region adalah cara paling sederhana dan paling hemat biaya untuk memastikan ketersediaan data Anda jika terjadi bencana. Jika penyimpanan multi-region tidak tersedia di region Anda, tetapi Anda dapat menggunakan region lain, gunakan BigQuery Data Transfer Service untuk menyalin set data ke region lain singkat ini. Jika dapat menggunakan enkripsi untuk mengurangi persyaratan lokalitas, Anda dapat mengelola kunci enkripsi Anda sendiri dengan Cloud KMS dan BigQuery.

Jika Anda hanya dapat menggunakan satu region, pertimbangkan untuk mencadangkan tabel BigQuery. Solusi paling hemat biaya untuk tabel pencadangan adalah dengan menggunakan BigQuery Export. Gunakan Cloud Scheduler atau Cloud Composer untuk menjadwalkan tugas ekspor secara berkala untuk menulis ke Cloud Storage. Anda dapat menggunakan format seperti Avro dengan kompresi SNAPPY atau JSON dengan kompresi GZIP. Saat merancang strategi ekspor, perhatikan batas ekspor.

Anda juga dapat menyimpan cadangan BigQuery dalam format kolom seperti Parquet dan ORC. Versi ini memberikan kompresi tinggi dan juga memungkinkan interoperabilitas dengan banyak mesin open source, seperti Hive dan Presto, yang mungkin Anda miliki di sistem lokal. Diagram berikut menguraikan proses ekspor data BigQuery ke format berbasis kolom untuk penyimpanan di lokasi lokal.

Diagram arsitektur yang menunjukkan ekspor data BigQuery ke penyimpanan berbasis kolom untuk pemulihan dari bencana.

Secara khusus, proses ekspor data BigQuery ke lokasi penyimpanan lokal ini melibatkan langkah-langkah berikut:

  • Data BigQuery dikirim ke tugas Apache Spark di Dataproc. Penggunaan tugas Apache Spark mengizinkan evolusi skema.
  • Setelah tugas Dataproc memproses file BigQuery, file yang diproses akan ditulis ke Cloud Storage, lalu ditransfer ke lokasi DR lokal.
  • Cloud Interconnect digunakan untuk menghubungkan jaringan Virtual Private Cloud ke jaringan lokal Anda.
  • Transfer ke lokasi DR lokal dapat terjadi melalui tugas Spark.

Jika desain warehouse Anda bersifat khusus tambahan dan dipartisi berdasarkan tanggal, Anda harus membuat salinan partisi yang diperlukan dalam tabel baru sebelum menjalankan tugas BigQuery Export di tabel baru. Selanjutnya, Anda dapat menggunakan alat seperti gsutil untuk mentransfer file terbaru ke lokasi cadangan Anda di infrastruktur lokal atau di cloud lain. (Biaya traffic keluar mungkin berlaku saat Anda mentransfer data keluar dari Google Cloud.)

Misalnya, Anda memiliki data warehouse penjualan yang terdiri dari tabel orders hanya tambahan, tempat pesanan baru ditambahkan ke partisi yang mewakili tanggal saat ini. Namun, kebijakan pengembalian mungkin mengizinkan item ditampilkan dalam waktu 7 hari. Oleh karena itu, data dalam tabel orders dalam 7 hari terakhir mungkin diperbarui. Strategi ekspor Anda perlu mempertimbangkan kebijakan pengembalian. Dalam contoh ini, setiap tugas ekspor untuk mencadangkan tabel orders juga harus mengekspor partisi yang mewakili pesanan dalam 7 hari terakhir untuk menghindari pembaruan yang tidak ada karena pengembalian.

Langkah selanjutnya