Dokumen ini menjelaskan prinsip dan teknik untuk menerapkan alur kerja berulang yang akan membantu Anda mengintegrasikan perubahan data ke dalam data warehouse (DWH) berbasis BigQuery. Perubahan ini dapat mencakup set data baru, sumber data baru, atau update dan perubahan pada set data yang sudah ada. Dokumen ini juga menjelaskan arsitektur referensi untuk tugas ini.
Audiens untuk dokumen ini adalah software dan data arsitek serta data engineer yang menggunakan BigQuery sebagai DWH. Dokumen ini mengasumsikan bahwa Anda telah memahami konsep dasar CI/CD atau praktik pengelolaan siklus proses aplikasi yang serupa.
Pengantar
Continuous integration dan continuous delivery (CI/CD) telah menjadi teknik penting dalam siklus proses pengembangan software. Dengan mengadopsi prinsip-prinsip CI/CD, tim dapat menghasilkan software yang lebih baik dengan lebih sedikit masalah dibandingkan dengan mengintegrasikan fitur dan men-deploy-nya secara manual. CI/CD juga dapat menjadi bagian dari strategi manajemen data saat Anda memodernisasi data warehousing Anda.
Namun, saat Anda bekerja dengan DWH seperti BigQuery, ada perbedaan dalam cara mengimplementasikan CI/CD dibandingkan dengan menerapkan CI/CD dalam kode sumber. Perbedaan ini sebagian karena data warehousing adalah sistem stateful yang inheren untuk mengelola data pokok.
Dokumen ini memberikan informasi berikut:
- Teknik untuk menerapkan strategi continuous integration (CI) di BigQuery.
- Panduan dan metode yang membantu Anda menghindari kesalahan.
- Saran untuk fitur BigQuery yang mendukung CI di BigQuery.
Dokumen ini berfokus pada CI, karena integrasi memiliki pertimbangan yang lebih spesifik untuk data warehousing tim dibandingkan dengan continuous delivery (CD).
Kapan harus menggunakan CI untuk DWH BigQuery
Dalam dokumen ini, integrasi data adalah tugas yang biasanya dilakukan oleh tim DWH, yang mencakup memasukkan data baru ke dalam DWH. Tugas ini mungkin melibatkan penggabungan sumber data baru ke dalam DWH, atau mengubah struktur tabel yang sudah ada di dalam DWH.
Mengintegrasikan data baru ke dalam DWH adalah tugas yang mirip dengan mengintegrasikan fitur baru ke dalam software yang sudah ada. Hal ini mungkin menimbulkan bug dan berdampak negatif pada pengalaman pengguna akhir. Saat Anda mengintegrasikan data ke BigQuery, konsumen data downstream (misalnya, aplikasi, dasbor BI, dan pengguna individual) mungkin mengalami masalah karena ketidakcocokan skema. Atau konsumen mungkin menggunakan data yang salah yang tidak mencerminkan data dari sumber data asli.
CI untuk DWH berguna saat Anda ingin melakukan hal berikut:
- Menjelaskan poin-poin penting dalam CI untuk sistem DWH.
- Mendesain dan menerapkan strategi CI untuk lingkungan BigQuery Anda.
- Mempelajari cara menggunakan fitur BigQuery untuk mengimplementasikan CI.
Panduan ini tidak menjelaskan cara mengelola CI untuk produk non-DWH, termasuk produk data seperti Dataflow dan Bigtable.
Contoh skenario
Perusahaan Contoh adalah perusahaan retail besar yang mengelola DWH di BigQuery. Pada tahun mendatang, perusahaan ini ingin mengintegrasikan sumber data baru ke DWH dari perusahaan yang baru-baru ini diakuisisi oleh Perusahaan Contoh. Sumber data baru yang akan diintegrasikan memiliki skema yang berbeda. Namun, DWH harus mempertahankan skema yang ada dan harus memberikan konsistensi data dan kelengkapan data yang kuat sehingga konsumen downstream data tidak terpengaruh secara negatif.
Saat ini, tim DWH Perusahaan Contoh sedang melakukan integrasi data. Integrasi ini bergantung pada keberadaan sumber data yang ada dalam skema yang telah ditetapkan. Alur kerja ini melibatkan proses impor data lama, database yang diperoleh, dan layanan aplikasi.
Untuk memperbarui proses integrasi data guna mengakomodasi sumber data baru, tim DWH harus mendesain ulang pendekatan terhadap integrasi data untuk mematuhi persyaratan yang disebutkan sebelumnya, seperti konsistensi data yang kuat. Tim harus menerapkan perubahan secara terpisah sehingga perubahan data dapat diuji dan diukur sebelum data tersedia bagi konsumen downstream.
Setelah tim DWH mengadopsi alur kerja baru, tim memiliki proses yang dapat diulang. Setiap developer dapat membuat lingkungan pengembangan terpisah yang berdasarkan data produksi. Dengan menggunakan lingkungan terpisah ini, developer dapat membuat perubahan, mengujinya, meminta peninjauan, dan mengirimkan perubahan yang diperlukan ke lingkungan produksi. Jika perubahan menyebabkan bug atau masalah yang tidak terduga, perubahan tersebut dapat di-roll back dengan mudah.
Arti integrasi berkelanjutan bagi DWH
Continuous integration (CI) adalah sekumpulan praktik yang memungkinkan tim pengembangan mempersingkat siklus pengembangan dan menemukan masalah dalam kode lebih cepat dibandingkan dengan sistem manual. Manfaat utama penggunaan pendekatan CI adalah kemampuan untuk berkembang dengan cepat, sehingga mengurangi risiko interferensi antar-developer. Sasaran ini dicapai dengan memastikan bahwa proses ini dapat diulang, sekaligus memungkinkan setiap developer bekerja secara terpisah dari developer lain.
Prinsip-prinsip ini juga berlaku ketika organisasi harus mengintegrasikan data ke dalam DWH, dengan beberapa perbedaan. Dalam konteks pengembangan software standar, CI mengisolasi perubahan pada kode sumber, yang bersifat stateless. Dalam konteks CI dalam data, CI mengintegrasikan data ke dalam sistem DWH. Namun, data bersifat stateful menurut definisi. Perbedaan ini berimplikasi pada penerapan CI pada skenario DWH, seperti yang dijelaskan dalam dokumen ini.
Skenario tambahan yang tidak dibahas dalam dokumen ini
Meskipun dokumen ini berfokus pada mengisolasi perubahan pengembangan dari lingkungan produksi, dokumen ini tidak mencakup aspek-aspek integrasi data berikut:
- Pengujian data: Apakah Anda dapat memverifikasi bahwa data yang Anda miliki sesuai dengan persyaratan bisnis? Apakah data dapat diandalkan untuk menjadi sumber kebenaran? Untuk meningkatkan tingkat kepercayaan pada data yang Anda salurkan dari DWH, penting untuk menguji data tersebut. Untuk mengujinya, Anda dapat menjalankan serangkaian kueri, yang menyatakan bahwa data tidak kehilangan nilai atau menyatakan bahwa data tersebut berisi nilai "buruk".
- Silsilah data: Apakah Anda dapat melihat tabel dalam konteksnya? Misalnya, dapatkah Anda melihat dari mana data dikumpulkan, dan set data mana yang telah dihitung sebelumnya untuk menghasilkan tabel? Dalam arsitektur DWH modern, data dibagi menjadi banyak sistem yang menggunakan struktur data khusus yang berbeda. Hal ini termasuk database relasional, database NoSQL, dan sumber data eksternal. Untuk memahami data yang Anda miliki, Anda harus melacak data tersebut. Anda juga harus memahami bagaimana data dihasilkan dan dari mana data tersebut dihasilkan.
Topik-topik tersebut berada di luar cakupan panduan ini. Namun, akan menguntungkan strategi data Anda dengan merencanakan topik-topik ini saat Anda merancang alur kerja untuk tim Anda.
Penyiapan umum BigQuery sebagai DWH
Diagram berikut mengilustrasikan desain DWH umum untuk BigQuery. Contoh ini menunjukkan cara data dari sumber eksternal diserap ke dalam DWH, dan cara konsumen mengonsumsi data dari DWH.
Data dimulai di sumber data, dengan data berada dalam database transaksional konvensional atau berlatensi rendah seperti database SQL OLTP dan database NoSQL. Sebuah proses terjadwal menyalin data ke area staging.
Data disimpan sementara di area staging. Jika perlu, data diubah agar sesuai dengan sistem analisis sebelum dimuat ke tabel DWH. (Dalam diagram ini, area staging ada di dalam Google Cloud, tetapi sebenarnya tidak perlu demikian.) Transformasi dapat mencakup denormalisasi, memperkaya set data tertentu, atau menangani entri yang salah format (misalnya, entri dengan nilai yang hilang).
Dari area staging, data baru dimuat ke dalam tabel DWH. Tabel mungkin diatur dalam berbagai cara, bergantung pada desain DWH, dan biasanya disebut sebagai tabel inti. Beberapa contoh paradigma desain tabel meliputi paradigma skema bintang, paradigma denormalisasi, dan agregat multi-tingkat.
Terlepas dari desain tabelnya, tabel ini menyimpan data dari waktu ke waktu. Tabel harus mematuhi skema, dan dianggap menyimpan sumber kebenaran untuk semua tujuan analisis. Peran tabel ini berarti bahwa data dalam tabel ini harus lengkap, konsisten, dan mematuhi skema yang telah ditetapkan.
Tabel ini tidak menyajikan data langsung kepada konsumen. Sebaliknya, data disalurkan melalui lapisan akses, yang dirancang untuk mengenkapsulasi logika bisnis yang harus diterapkan ke data pokok. Contoh logika bisnis jenis ini adalah menghitung metrik untuk setiap catatan, atau memfilter dan mengelompokkan data.
Konsumen data dapat terhubung ke dan membaca data dari lapisan akses DWH. Konsumen data ini dapat mencakup sistem seperti berikut:
- Dasbor business intelligence (BI)
- Notebook data science
- Sistem operasional yang mengandalkan data yang dihitung di DWH
- Pengguna manusia untuk kueri ad-hoc
Konsumen data sangat bergantung pada DWH untuk memberikan skema yang konsisten dan logika bisnis yang dienkapsulasi oleh DWH. Skema dan logika bisnis ini dapat dianggap sebagai perjanjian tingkat layanan (SLA) dari platform DWH. Setiap perubahan pada logika bisnis, skema, atau kelengkapan data mungkin memiliki implikasi yang besar pada downstream. Mengingat sifat platform data modern yang terus berubah, tim DWH mungkin perlu melakukan perubahan tersebut sekaligus tetap sangat mematuhi SLA. Agar tim dapat memenuhi SLA ini dan juga menjaga DWH selalu terbaru, mereka memerlukan alur kerja yang memungkinkan integrasi data sekaligus meminimalkan hambatan yang mungkin ditimbulkan oleh perubahan ini.
Aset untuk continuous integration di DWH
Seperti halnya tim pengembangan atau tim IT lainnya, tim DWH harus memelihara aset yang penting untuk tanggung jawab mereka. Aset ini biasanya dapat dibagi menjadi beberapa kategori berikut:
Codebase untuk pipeline data: Aset ini biasanya terdiri dari kode sumber dalam bahasa pemrograman tingkat tinggi seperti Python atau Java. Untuk jenis aset tersebut, proses CI/CD dibuat menggunakan alat seperti Git dan Jenkins, atau dengan menggunakan solusi Google Cloud seperti Cloud Source Repositories dan Cloud Build.
Skrip SQL: Aset ini mendeskripsikan struktur dan logika bisnis yang dienkapsulasi di dalam DWH. Dalam kategori ini, aset dapat dibagi lagi menjadi subkategori berikut:
- Bahasa definisi data (DDL): Aset ini digunakan untuk menentukan skema tabel dan tampilan.
- Bahasa manipulasi data (DML): Aset ini digunakan untuk memanipulasi data di dalam tabel. Perintah DML juga digunakan untuk membuat tabel baru berdasarkan tabel yang sudah ada.
- Bahasa kontrol data (DCL): Aset ini digunakan untuk mengontrol izin dan akses ke tabel. Dalam BigQuery, Anda dapat mengontrol akses menggunakan SQL dan alat command line
bqatau dengan menggunakan BigQuery REST API. Namun, sebaiknya gunakan IAM.
Aset ini, dan lainnya seperti skrip Terraform yang digunakan untuk mem-build komponen, dikelola di dalam repositori kode. Alat seperti Dataform dapat membantu Anda membuat pipeline CI/CD yang memvalidasi skrip SQL dan memeriksa aturan validasi yang telah ditetapkan pada tabel yang dibuat oleh skrip DDL. Alat ini memungkinkan Anda menerapkan proses kompilasi dan pengujian untuk SQL, yang dalam sebagian besar konteks tidak memiliki lingkungan pengujian alami.
Selain aset yang terkait dengan alat dan proses, aset utama untuk tim DWH adalah data. Data tidak dapat dilacak menggunakan sistem pelacakan aset seperti Git, yang dirancang untuk melacak kode sumber. Dokumen ini membahas masalah yang terkait dengan data pelacakan.
Masalah terkait mengintegrasikan data
Karena potensi kompleksitas hubungan tabel di dalam DWH (misalnya, dalam salah satu paradigma desain tabel yang disebutkan sebelumnya), menjaga status data produksi tetap terisolasi dari lingkungan pengujian merupakan sebuah tantangan. Praktik standar dalam pengembangan software tidak dapat diterapkan ke skenario integrasi data.
Tabel berikut merangkum perbedaan antara praktik mengintegrasikan kode dan praktik untuk mengintegrasikan data.
| Mengintegrasikan kode | Mengintegrasikan data | |
|---|---|---|
| Pengembangan lokal | Kode sumber mudah di-clone karena ukurannya yang relatif kecil. Umumnya, kode tersebut sesuai dengan sebagian besar mesin pengguna akhir (tidak termasuk kasus monorepos, yang memiliki solusi lain). | Sebagian besar tabel dalam DWH tidak dapat dimuat di mesin pengembangan karena ukurannya. |
| Pengujian pusat | Status kode sumber yang berbeda di-clone ke dalam sistem pusat (server CI) untuk menjalani pengujian otomatis. Memiliki status kode yang berbeda memungkinkan Anda membandingkan hasil antara versi stabil dan versi pengembangan. | Membuat status data yang berbeda di lingkungan yang terpisah tidaklah mudah. Memindahkan data di luar DWH adalah operasi yang memakan banyak sumber daya dan memakan waktu. Tidak praktis untuk dilakukan sesering yang diperlukan untuk pengujian. |
| Versi lama | Selama proses rilis versi baru software, Anda dapat melacak versi sebelumnya. Jika mendeteksi masalah dalam rilis baru, Anda dapat melakukan roll back ke versi yang aman. | Mengambil cadangan tabel di dalam DWH adalah praktik standar jika Anda harus melakukan roll back. Namun, Anda harus memastikan bahwa semua tabel yang terpengaruh di-roll back ke titik waktu yang sama. Dengan begitu, tabel yang terkait akan konsisten satu sama lain. |
Mengintegrasikan data ke dalam tabel BigQuery
BigQuery memiliki dua fitur yang dapat membantu Anda mendesain alur kerja untuk integrasi data: snapshot tabel dan clone tabel. Anda dapat menggabungkan fitur-fitur ini untuk mewujudkan alur kerja yang memberi Anda lingkungan pengembangan yang hemat biaya. Developer dapat memanipulasi data dan strukturnya secara terpisah dari lingkungan produksi, dan dapat melakukan roll back perubahan jika perlu.
Snapshot tabel BigQuery adalah representasi hanya baca dari sebuah tabel (disebut tabel dasar) pada waktu tertentu. Demikian pula, Clone tabel BigQuery adalah representasi baca-tulis tabel pada waktu tertentu. Dalam kedua kasus tersebut, biaya penyimpanan diminimalkan karena hanya perbedaan dari tabel dasar yang disimpan. Clone tabel mulai dikenai biaya saat tabel dasar berubah atau saat clone tabel berubah. Karena bersifat hanya baca, snapshot tabel hanya dikenai biaya jika tabel dasar berubah.
Untuk mengetahui informasi selengkapnya tentang harga snapshot tabel dan clone tabel, lihat Pengantar snapshot tabel dan Pengantar clone tabel.
Anda dapat mengambil snapshot tabel dan clone tabel menggunakan fitur perjalanan waktu BigQuery (hingga tujuh hari sebelumnya). Fitur ini memungkinkan Anda mengambil snapshot dan clone beberapa tabel secara bersamaan, sehingga lingkungan kerja dan snapshot Anda konsisten satu sama lain. Menggunakan fitur ini dapat membantu untuk tabel yang sering diperbarui.
Cara menggunakan clone tabel dan snapshot tabel untuk memungkinkan isolasi
Sebagai ilustrasi alur kerja integrasi untuk CI dalam DWH, bayangkan skenario berikut. Anda diberi tugas untuk mengintegrasikan set data baru ke dalam DWH. Tugasnya mungkin adalah membuat tabel DWH baru, memperbarui tabel yang ada, mengubah struktur tabel, atau kombinasi apa pun dari tugas ini. Alur kerjanya mungkin terlihat seperti urutan berikut:
- Anda mengidentifikasi tabel yang mungkin terpengaruh oleh perubahan tersebut dan tabel tambahan yang mungkin ingin Anda periksa.
- Anda membuat set data BigQuery baru guna memuat aset untuk perubahan ini. Set data ini membantu mengisolasi perubahan dan memisahkan tugas ini dari tugas lain yang dikerjakan oleh anggota tim lainnya. Set data harus berada di region yang sama dengan set data sumber. Namun, project dapat dipisahkan dari project produksi untuk membantu memenuhi persyaratan keamanan dan penagihan organisasi Anda.
Untuk setiap tabel, Anda dapat membuat clone dan snapshot dalam set data baru, kemungkinan untuk titik yang sama pada waktunya. Pendekatan ini memberikan manfaat seperti berikut:
- Clone tabel dapat bertindak sebagai salinan kerja, sehingga Anda dapat membuat perubahan dengan bebas tanpa memengaruhi tabel produksi. Anda dapat membuat beberapa clone tabel dari tabel dasar yang sama agar dapat menguji berbagai jalur integrasi secara bersamaan, dengan overhead minimal.
- Snapshot dapat bertindak sebagai titik pemulihan dan referensi, titik di mana data diketahui telah berfungsi sebelum perubahan terjadi. Dengan snapshot ini, Anda dapat melakukan rollback jika terjadi masalah terdeteksi nanti dalam proses.
Anda dapat menggunakan clone tabel untuk menerapkan perubahan yang diperlukan untuk tabel. Tindakan ini menghasilkan versi clone tabel yang telah diperbarui, yang dapat Anda uji dalam set data terisolasi.
Secara opsional, pada akhir fase implementasi, Anda dapat menampilkan set data yang dapat digunakan untuk tugas-tugas berikut:
- Pengujian unit dengan alat validasi seperti Dataform. Pengujian unit bersifat mandiri, yang berarti bahwa aset diuji secara terpisah. Dalam hal ini, aset adalah tabel di BigQuery. Pengujian unit dapat memeriksa nilai null, dapat memverifikasi bahwa semua string memenuhi persyaratan panjang, dan dapat memastikan bahwa agregat tertentu memberikan hasil yang berguna. Pengujian unit dapat mencakup pengujian keyakinan apa pun yang memastikan bahwa tabel mempertahankan aturan bisnis organisasi.
- Pengujian integrasi dengan konsumen downstream.
- Ulasan sejawat.
Alur kerja ini memungkinkan Anda melakukan pengujian dengan data produksi, tanpa memengaruhi konsumen downstream.
Sebelum menggabungkan data baru ke BigQuery, Anda dapat membuat snapshot lain. Snapshot ini berguna sebagai opsi rollback lain jika data dalam tabel dasar telah berubah.
Proses penggabungan perubahan bergantung pada proses yang ingin diterapkan organisasi Anda dan perubahan apa yang diperlukan. Misalnya, untuk perubahan dalam skrip SQL, set data baru mungkin disertai dengan permintaan pull ke codebase standar. Jika perubahannya terbatas pada perubahan data dalam tabel tertentu, Anda bisa menyalin data menggunakan metode standar BigQuery.
Anda dapat menggunakan skrip prosedur yang tersimpan untuk mengenkapsulasi dan mengotomatiskan langkah-langkah untuk membuat set data serta membuat clone dan snapshot. Mengotomatiskan tugas ini akan mengurangi risiko kesalahan manusia. Untuk mengetahui contoh skrip yang dapat membantu mengotomatisasi proses, baca repositori GitHub CI untuk Data di utilitas BigQuery CLI.
Manfaat menggunakan clone tabel dan snapshot tabel
Jika Anda menggunakan alur kerja yang dijelaskan di bagian sebelumnya, developer dapat bekerja secara terpisah dan paralel, tanpa mengganggu kolega mereka. Developer dapat menguji dan meninjau perubahan, dan jika ada masalah, roll back perubahan tersebut. Karena Anda bekerja menggunakan snapshot tabel dan bukan menggunakan tabel penuh, Anda dapat meminimalkan biaya dan penyimpanan dibandingkan jika menggunakan tabel dalam format lengkap.
Bagian ini memberikan detail selengkapnya tentang cara snapshot tabel dan clone tabel memungkinkan developer mencapai alur kerja ini. Diagram berikut menunjukkan hubungan antara snapshot tabel dan clone tabel dengan data dalam set data produksi.
Dalam diagram, set data produksi berisi semua tabel yang sedang digunakan dalam produksi. Setiap developer dapat membuat set data untuk lingkungan pengembangannya sendiri. Diagram ini menunjukkan dua set data developer, yang diberi label Dev Dataset 1 dan Dev Dataset 2. Dengan menggunakan set data developer ini, developer dapat bekerja secara bersamaan pada tabel yang sama tanpa mengganggu satu sama lain.
Setelah membuat set data, developer dapat membuat clone dan snapshot tabel yang sedang mereka kerjakan. Clone dan snapshot mewakili data pada titik waktu tertentu. Pada tahap ini, developer bebas mengubah clone tabel karena perubahan tidak terlihat pada tabel dasar.
Developer dapat meninjau clone tabel, membandingkannya dengan snapshot, dan mengujinya untuk mengetahui kompatibilitasnya dengan konsumen downstream. Developer lain dapat menggunakan clone dan snapshot lain tanpa interferensi, serta tanpa membuat terlalu banyak salinan tabel dasar yang menghabiskan resource.
Developer dapat menggabungkan perubahan ke dalam tabel dasar sekaligus menjaga snapshot tersebut aman untuk dimiliki sebagai opsi rollback, jika diperlukan. Proses ini juga dapat diulang untuk berbagai lingkungan, seperti pengembangan, pengujian, dan produksi.
Alternatif untuk clone tabel dan snapshot tabel
Ada alternatif untuk menggunakan clone tabel dan snapshot tabel yang memungkinkan Anda mencapai hasil serupa. Metode alternatif ini biasanya digunakan secara berbeda daripada clone dan snapshot. Penting untuk memahami perbedaan antara metode-metode ini dan di mana Anda mungkin lebih memilih satu metode daripada metode yang lain.
Salin seluruh tabel ke dalam set data yang berbeda
Salah satu metode alternatif adalah menggunakan set data yang berbeda dan menyalin tabel ke dalam set data tersebut. Menggunakan metode ini mirip dengan menggunakan clone dan snapshot tabel, tetapi Anda menyalin seluruh kumpulan tabel. Tergantung pada ukuran data yang disalin, biaya penyimpanan mungkin tinggi. Beberapa organisasi menggunakan metode ini sebelum clone tabel tersedia di BigQuery. Namun, metode ini tidak memberikan keuntungan apa pun dibandingkan penggunaan clone dan snapshot.
Mengekspor dan mengimpor tabel ke Cloud Storage
Metode alternatif lainnya adalah memindahkan data melalui Cloud Storage. Metode ini juga mirip dengan penggunaan clone tabel dan snapshot tabel. Namun, tindakan ini mencakup langkah tambahan untuk mengekspor data ke bucket Cloud Storage. Salah satu keuntungan dari metode ini adalah memberikan cadangan tambahan atas data Anda. Anda dapat memilih metode ini jika menginginkan cadangan untuk pemulihan dari bencana atau solusi campuran.
Menggunakan Analytics Hub
Analytics Hub memungkinkan Anda berbagi set data baik di luar dan di dalam organisasi dengan cara yang didesain agar aman. Set data ini menawarkan banyak fitur yang memungkinkan Anda memublikasikan set data agar pelanggan memiliki akses hanya baca yang terkontrol ke set data tersebut. Namun, meskipun Anda dapat menggunakan Analytics Hub untuk mengekspos set data agar dapat menerapkan perubahan, developer tetap harus membuat clone tabel agar dapat menggunakan tabel.
Ringkasan opsi continuous integration DWH
Tabel berikut merangkum perbedaan, kelebihan, dan potensi kelemahan antara berbagai opsi untuk continuous integration DWH. (Analytics Hub menawarkan set fitur yang berbeda, sehingga tidak dapat diukur menggunakan parameter yang tercantum dalam tabel.)
| Biaya | Rollback | Risiko | |
|---|---|---|---|
| Snapshot tabel dan clone tabel | Minimal. Anda hanya membayar selisih antara snapshot atau clone dan tabel dasar. | Snapshot berfungsi sebagai cadangan untuk roll back jika diperlukan. | Anda yang mengendalikan jumlah risikonya. Snapshot dapat diambil pada waktu tertentu untuk semua tabel, sehingga mengurangi inkonsistensi meskipun terjadi rollback. |
| Salinan tabel | Biaya lebih tinggi dibandingkan menggunakan snapshot tabel dan clone tabel. Seluruh data diduplikasi. Untuk mendukung rollback, Anda memerlukan beberapa salinan tabel yang sama. | Dapat digunakan, tetapi memerlukan dua salinan tabel—satu salinan untuk digunakan sebagai cadangan dan satu salinan untuk digunakan dan diubah. | Cloning lebih sulit dilakukan untuk waktu tertentu. Jika rollback diperlukan, tidak semua tabel diambil dari titik waktu yang sama. |
| Mengekspor dan mengimpor | Biaya lebih tinggi dibandingkan menggunakan snapshot tabel dan clone tabel. Datanya diduplikasi. Untuk mendukung rollback, Anda memerlukan beberapa salinan tabel yang sama. | Data yang diekspor berfungsi sebagai cadangan. | Data yang diekspor bukan merupakan ekspor point-in-time untuk beberapa tabel. |
Langkah selanjutnya
- Baca snapshot tabel BigQuery di Pengantar snapshot tabel.
- Pelajari lebih lanjut continuous integration untuk pengembangan software di Teknologi DevOps: Continuous integration.
- Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.