Ringkasan skema dan transfer data

Dokumen ini membahas konsep dan tugas untuk mentransfer skema dan data dari data warehouse yang ada ke BigQuery.

Memigrasikan data warehouse ke cloud adalah proses kompleks yang memerlukan perencanaan, resource, dan waktu. Untuk mengatasi kompleksitas ini, Anda harus melakukan migrasi data warehouse secara bertahap dan iteratif. Melakukan beberapa iterasi migrasi skema dan data dapat meningkatkan hasilnya.

Proses migrasi skema dan data

Di awal perjalanan migrasi, Anda memiliki sistem upstream yang memasok data warehouse yang ada, dan sistem downstream yang menggunakan data tersebut dalam laporan, dasbor, dan sebagai feed ke proses lainnya.

Aliran data umum ini mendukung banyak kasus penggunaan analisis, seperti yang ditunjukkan dalam diagram berikut:

Status akhir perjalanan Anda adalah memiliki sebanyak mungkin kasus penggunaan yang dijalankan di BigQuery. Status ini memungkinkan Anda meminimalkan penggunaan data warehouse yang ada dan pada akhirnya menghentikannya. Anda dapat mengontrol kasus penggunaan mana yang dimigrasikan dan kapan, dengan memprioritaskannya selama fase menyiapkan dan menemukan migrasi.

Mentransfer skema dan data ke BigQuery

Pada fase perencanaan migrasi, Anda harus mengidentifikasi kasus penggunaan yang ingin dimigrasikan. Kemudian, Anda akan memulai iterasi migrasi pada fase execute. Untuk mengelola iterasi saat menjalankan lingkungan analisis dengan gangguan minimal, ikuti proses tingkat tinggi ini:

1. Transfer tabel serta konfigurasi dan uji proses downstream.

   • Transfer grup tabel untuk setiap kasus penggunaan ke BigQuery tanpa perubahan apa pun, menggunakan BigQuery Data Transfer Service atau alat ETL lainnya. Untuk mengetahui informasi tentang alat, lihat bagian transfer data awal.
   • Konfigurasikan versi uji proses downstream untuk membaca dari tabel BigQuery.

   Langkah awal ini membagi aliran data. Diagram berikut menunjukkan alur yang dihasilkan. Beberapa sistem downstream kini membaca dari BigQuery seperti yang ditunjukkan dalam alur berlabel B. Yang lainnya masih membaca dari data warehouse yang ada, seperti yang ditunjukkan pada alur berlabel A.

   

2. Konfigurasikan beberapa proses upstream pengujian untuk menulis data ke tabel BigQuery, bukan (atau sebagai tambahan) dari data warehouse yang ada.

   Setelah pengujian, konfigurasikan proses upstream dan downstream produksi Anda untuk menulis dan membaca ke tabel BigQuery. Proses ini dapat terhubung ke BigQuery menggunakan BigQuery API dan menggabungkan produk cloud baru seperti Looker Studio dan Dataflow singkat ini.

   Pada tahap ini, Anda memiliki tiga aliran data:

   1. Yang Sudah Ada. Data dan prosesnya tidak berubah dan masih terpusat pada data warehouse yang ada.
   2. Pengurangan beban. Proses upstream memasukkan data warehouse yang ada, data dipindahkan ke BigQuery, lalu mengirimkan data ke proses downstream.
   3. Dimigrasikan sepenuhnya. Proses upstream dan downstream tidak lagi menulis atau membaca dari data warehouse yang ada.

      Diagram berikut menunjukkan sistem dengan ketiga alur ini:

      

3. Pilih kasus penggunaan tambahan untuk migrasi, lalu lanjutkan ke langkah 1 untuk memulai iterasi eksekusi baru. Terus lakukan iterasi melalui langkah-langkah ini sampai semua kasus penggunaan Anda dimigrasikan sepenuhnya ke BigQuery. Saat memilih kasus penggunaan, Anda dapat membuka kembali kasus yang tetap dalam status tidak dimuat untuk memindahkannya agar dimigrasikan sepenuhnya. Untuk kasus penggunaan yang telah dimigrasikan sepenuhnya, pertimbangkan untuk melanjutkan proses evolusi dengan mengikuti panduan dalam artikel Mengembangkan skema di BigQuery.

   

Mengembangkan skema Anda di BigQuery

Skema data warehouse menentukan cara data Anda disusun dan menentukan hubungan antara entity data Anda. Skema merupakan inti dari desain data Anda, dan memengaruhi banyak proses, baik upstream maupun downstream.

Migrasi data warehouse menghadirkan peluang unik untuk mengembangkan skema setelah dipindahkan ke BigQuery. Bagian ini memperkenalkan panduan untuk mengembangkan skema menggunakan serangkaian langkah. Panduan ini membantu Anda menjaga lingkungan data warehouse Anda tetap berjalan selama perubahan skema dengan gangguan minimal pada proses upstream dan downstream.

Langkah-langkah di bagian ini berfokus pada transformasi skema untuk satu kasus penggunaan.

Bergantung pada seberapa jauh Anda ingin melakukan evolusi, Anda mungkin berhenti pada langkah menengah, atau Anda mungkin melanjutkan hingga sistem Anda sepenuhnya berkembang.

1. Mentransfer kasus penggunaan sebagaimana adanya ke BigQuery.

   Sebelum melanjutkan ke langkah berikutnya, pastikan proses upstream dan downstream dari kasus penggunaan Anda sudah menulis dan membaca dari BigQuery. Namun, Anda juga dapat memulai dari status menengah, yaitu hanya proses downstream yang membaca dari BigQuery. Dalam skenario ini, hanya terapkan panduan untuk bagian downstream. Diagram berikut mengilustrasikan kasus penggunaan saat proses upstream dan downstream menulis ke dan membaca dari tabel di BigQuery.

   

2. Terapkan pengoptimalan ringan.

   1. Buat ulang tabel, dengan menerapkan partisi dan pengelompokan. Untuk tugas ini, Anda dapat menggunakan metode pembuatan tabel dari hasil kueri. Untuk mengetahui detailnya, lihat diskusi dan contoh untuk tabel yang dipartisi, dan lihat diskusi dan contoh untuk tabel yang dikelompokkan.
   2. Alihkan proses upstream dan downstream Anda ke tabel baru.

3. Buat tampilan facade.

   Jika Anda ingin mengembangkan skema lebih lanjut di luar pengoptimalan cahaya, buat tampilan facade untuk tabel Anda. Pola facade adalah metode desain yang menyamarkan kode atau struktur yang mendasarinya untuk menyembunyikan kerumitan. Dalam hal ini, tampilan facade menyamarkan tabel pokok untuk menyembunyikan kompleksitas yang disebabkan oleh perubahan tabel dari proses downstream.

   Penayangan dapat mendeskripsikan skema baru, bebas dari utang teknis, dan dimodelkan dengan mempertimbangkan skenario penyerapan dan konsumsi baru.

   Di balik layar, tabel dan definisi kueri tampilan itu sendiri dapat berubah. Namun, tampilan memisahkan perubahan ini sebagai detail implementasi internal data warehouse Anda, dan selalu menampilkan hasil yang sama. Lapisan abstraksi yang terbuat dari tampilan facade ini mengisolasi sistem upstream dan downstream Anda agar tidak berubah selama diperlukan, dan hanya menampilkan perubahan jika sesuai.

4. Mentransformasi proses downstream.

   Anda dapat mengubah beberapa proses downstream untuk membaca dari tampilan facade, bukan dari tabel yang sebenarnya. Proses ini akan mendapatkan manfaat dari skema yang dikembangkan. Dalam proses ini, proses ini transparan bahwa di balik layar, tampilan facade masih mendapatkan datanya dari skema BigQuery sumber, seperti yang ditunjukkan dalam diagram berikut:

   

   Kami telah menjelaskan transformasi proses downstream terlebih dahulu. Hal ini memungkinkan Anda menampilkan nilai bisnis lebih cepat, dalam bentuk dasbor atau laporan yang dimigrasikan, daripada jika Anda mengubah proses upstream yang tidak terlihat oleh pemangku kepentingan non-teknis. Namun, Anda dapat memulai transformasi dengan proses upstream. Prioritas tugas-tugas ini sepenuhnya tergantung pada kebutuhan Anda.

5. Mentransformasi proses upstream.

   Anda dapat mengubah beberapa proses upstream untuk menulis ke skema baru. Karena tampilan bersifat hanya baca, Anda membuat tabel berdasarkan skema baru, lalu mengubah definisi kueri tampilan facade. Beberapa tampilan akan tetap mengkueri skema sumber, sementara tampilan lain akan mengkueri tabel yang baru dibuat, atau menjalankan operasi UNION SQL pada keduanya, seperti yang ditunjukkan dalam diagram berikut:

   

   Pada tahap ini, Anda dapat memanfaatkan kolom bertingkat dan berulang saat membuat tabel baru. Hal ini memungkinkan Anda melakukan denormalisasi model lebih lanjut dan memanfaatkan langsung representasi data berbasis kolom dari BigQuery.

   Manfaat tampilan facade adalah proses downstream Anda dapat melanjutkan transformasinya secara independen dari perubahan skema dasar ini dan terlepas dari perubahan dalam proses upstream.

6. Kembangkan kasus penggunaan Anda sepenuhnya.

   Terakhir, Anda dapat mengubah proses upstream dan downstream yang tersisa. Saat semua itu diubah agar dapat ditulis ke dalam tabel baru dan untuk membaca dari tampilan facade baru, Anda akan mengubah definisi kueri tampilan facade agar tidak lagi membaca dari skema sumber. Anda kemudian dapat menghentikan tabel dalam model sumber dari aliran data. Diagram berikut menunjukkan status tempat tabel sumber tidak lagi digunakan.

   

   Jika tampilan facade tidak menggabungkan kolom atau memfilter kolom, Anda dapat mengonfigurasi proses downstream agar membaca dari tabel yang diubah, lalu menghentikan tampilan facade untuk mengurangi kompleksitas, seperti yang ditunjukkan pada diagram berikut .

   

Melakukan transfer awal skema dan data Anda

Bagian ini membahas pertimbangan praktis untuk memigrasikan skema dan data dari data warehouse yang ada ke BigQuery.

Sebaiknya Anda mentransfer skema tanpa perubahan apa pun selama iterasi awal migrasi. Hal ini memberi Anda keuntungan berikut:

• Pipeline data yang memasok data warehouse Anda tidak perlu disesuaikan untuk skema baru.
• Anda menghindari penambahan skema baru ke daftar materi pelatihan untuk staf.
• Anda dapat memanfaatkan alat otomatis untuk melakukan skema dan transfer data.

Selain itu, bukti konsep (PoC) dan aktivitas eksplorasi data lainnya yang memanfaatkan kemampuan cloud dapat dilanjutkan tanpa hambatan, bahkan saat migrasi terjadi secara paralel.

Pilih metode transfer

Anda dapat melakukan transfer awal menggunakan salah satu dari beberapa pendekatan.

• Untuk data warehouse Amazon Redshift dan Teradata, Anda dapat menggunakan BigQuery Data Transfer Service untuk memuat skema dan data secara langsung dari sistem yang ada ke BigQuery. Cloud Storage masih digunakan untuk menyiapkan data sebagai bagian dari proses migrasi.
• Untuk setiap data warehouse, Anda dapat mengekstrak file yang berisi skema dan data, mengupload file tersebut ke Cloud Storage, lalu menggunakan salah satu opsi berikut untuk memuat skema dan data dari file tersebut ke BigQuery:
  • BigQuery Data Transfer Service
  • BigQuery Storage Write API
  • Pemuatan batch

Untuk pertimbangan lebih lanjut saat memilih metode transfer data, baca Memilih metode penyerapan data.

Pertimbangkan transformasi data

Bergantung pada format ekstraksi data dan apakah Anda ingin memangkas atau memperkaya data sebelum memuatnya ke BigQuery, Anda dapat menyertakan satu langkah untuk mentransformasi data. Anda dapat mengubah data di lingkungan yang sudah ada atau di Google Cloud:

• Jika Anda mengubah data di lingkungan saat ini, pertimbangkan bagaimana kapasitas komputasi dan alat yang tersedia dapat membatasi throughput. Selain itu, jika Anda memperkaya data selama proses transformasi, pertimbangkan apakah Anda memerlukan waktu transfer atau bandwidth jaringan tambahan.
• Jika Anda mengubah data di Google Cloud, baca artikel Memuat data menggunakan alat ETL untuk mengetahui informasi selengkapnya tentang opsi yang tersedia.

Ekstrak skema dan data yang ada ke dalam file

Platform Anda yang ada mungkin menyediakan alat untuk mengekspor data ke format yang tidak terkait vendor seperti Apache AVRO atau CSV. Untuk mengurangi kompleksitas transfer, sebaiknya gunakan AVRO, ORC, atau Parquet, tempat informasi skema disematkan dengan data. Jika memilih CSV atau format data delimited yang sederhana dan serupa, Anda harus menentukan skema secara terpisah. Cara melakukannya bergantung pada metode transfer data yang Anda pilih. Misalnya, untuk upload banyak, Anda dapat menentukan skema pada waktu pemuatan atau mengizinkan deteksi otomatis skema berdasarkan konten file CSV.

Saat Anda mengekstrak file ini dari platform yang ada, salin file tersebut ke penyimpanan staging di lingkungan yang ada.

Upload file ke Cloud Storage

Kecuali jika menggunakan BigQuery Data Transfer Service untuk memuat data langsung dari data warehouse Amazon Redshift atau Teradata yang ada, Anda harus mengupload file yang diekstrak ke bucket di Cloud Storage. Bergantung pada jumlah data yang ditransfer dan bandwidth jaringan yang tersedia, Anda dapat memilih dari opsi transfer berikut:

• Jika data yang diekstrak berada di penyedia cloud lain, gunakan Storage Transfer Service.

• Jika data berada di lingkungan lokal atau di fasilitas kolokasi yang memiliki bandwidth jaringan yang baik, gunakan alat gsutil. Alat gsutil mendukung upload paralel multi-thread, yang dilanjutkan setelah terjadi error, dan mengenkripsi traffic dalam pengiriman untuk menjaga keamanan.

  • Jika tidak dapat menggunakan gsutil, Anda dapat mencoba alat pihak ketiga dari partner Google.
  • Jika bandwidth jaringan terbatas, Anda dapat menggunakan teknik kompresi untuk membatasi ukuran data, atau mengubah koneksi saat ini ke Google Cloud untuk meningkatkan bandwidth.

• Jika tidak dapat mencapai bandwidth jaringan yang cukup, Anda dapat melakukan transfer offline menggunakan Transfer Appliance.

Saat Anda membuat bucket Cloud Storage dan mentransfer data melalui jaringan, minimalkan latensi jaringan dengan memilih lokasi yang paling dekat dengan pusat data Anda. Jika memungkinkan, pilih lokasi bucket agar sama dengan lokasi set data BigQuery.

Untuk mengetahui informasi mendetail tentang praktik terbaik saat memindahkan data ke Cloud Storage, termasuk memperkirakan biaya, lihat Strategi untuk mentransfer set data besar.

Muat skema dan data ke BigQuery

Muat skema dan data ke BigQuery menggunakan salah satu opsi yang dibahas dalam artikel Memilih metode transfer.

Untuk informasi selengkapnya tentang pemuatan satu kali, lihat Pengantar pemuatan data dari Cloud Storage dalam dokumentasi BigQuery. Untuk mengetahui informasi selengkapnya tentang pemuatan yang dijadwalkan secara berkala, baca Ringkasan transfer Cloud Storage di dokumentasi BigQuery Data Transfer Service.

Muat data menggunakan alat ETL

Jika data Anda memerlukan transformasi lebih lanjut saat dimuat ke BigQuery, gunakan salah satu opsi berikut:

• Cloud Data Fusion. Alat ini secara grafis mem-build pipeline data ETL/ELT yang terkelola sepenuhnya menggunakan library open source dari konektor dan transformasi yang telah dikonfigurasi sebelumnya.
• Dataflow. Alat ini menentukan dan menjalankan grafik pengayaan dan transformasi data yang kompleks menggunakan model Apache Beam. Dataflow tidak memiliki server dan dikelola sepenuhnya oleh Google, sehingga memberi Anda akses ke kapasitas pemrosesan yang hampir tanpa batas.
• Dataproc. Tindakan ini menjalankan cluster Apache Spark dan Apache Hadoop pada layanan cloud yang terkelola sepenuhnya.
• Alat Pihak Ketiga. Hubungi salah satu partners kami. Eksperimen dapat memberikan pilihan yang efektif saat Anda ingin mengeksternalkan pembuatan pipeline data.

Diagram berikut menunjukkan pola yang dijelaskan di bagian ini. Alat transfer data gsutil, dan ada langkah transformasi yang memanfaatkan Dataflow dan menulis langsung ke BigQuery, mungkin menggunakan Apache Beam bawaan Konektor Google BigQuery I/O.

Setelah memuat kumpulan awal data ke BigQuery, Anda dapat mulai memanfaatkan fitur-fitur canggih BigQuery.

Namun, seperti saat Anda mentransfer skema, mengupload data adalah bagian dari proses berulang. Iterasi berikutnya dapat dimulai dengan memperluas jejak data yang ditransfer ke BigQuery. Kemudian, Anda dapat mengubah rute feed data upstream ke BigQuery tanpa perlu menjaga data warehouse yang ada tetap berjalan. Topik-topik ini akan dibahas di bagian berikutnya.

Validasi data

Setelah data Anda berada di BigQuery, Anda dapat memverifikasi keberhasilan transfer data dengan Alat Validasi Data (DVT). DVT adalah alat Python CLI open source yang memungkinkan Anda membandingkan data dari berbagai sumber dengan target Anda di BigQuery. Anda dapat menentukan agregasi yang ingin dijalankan (misalnya, jumlah, jumlah, rata-rata) dan kolom tempat agregasi tersebut akan diterapkan. Untuk mengetahui informasi selengkapnya, lihat Mengotomatiskan Validasi Data dengan DVT.

Mengiterasi pada transfer awal

Bagian ini membahas cara melanjutkan setelah transfer data awal agar dapat memanfaatkan BigQuery sebaik mungkin.

Sebagian besar data Anda kini ada di BigQuery. Anda bersiap untuk meningkatkan jejak data yang digunakan di BigQuery, sehingga untuk mengurangi ketergantungan pada data warehouse yang ada.

Metode yang Anda pilih untuk iterasi berikutnya bergantung pada seberapa penting bagi kasus penggunaan Anda untuk memperbarui data ke detik saat ini. Jika analis data Anda dapat bekerja dengan data yang digabungkan ke dalam data warehouse pada interval berulang, opsi terjadwal adalah pilihan yang tepat. Anda dapat membuat transfer terjadwal dengan cara yang mirip dengan transfer awal. Anda menggunakan BigQuery Data Transfer Service, alat ETL lainnya seperti Storage Transfer Service Google, atau implementasi pihak ketiga tersebut.

Jika Anda menggunakan BigQuery Data Transfer Service, pertama-tama Anda memutuskan tabel mana yang akan dipindahkan. Kemudian, Anda membuat pola nama tabel untuk menyertakan tabel-tabel tersebut. Terakhir, Anda menetapkan jadwal berulang untuk menjalankan transfer.

Di sisi lain, jika kasus penggunaan Anda memerlukan akses instan ke data baru, Anda memerlukan pendekatan streaming. Anda memiliki dua opsi:

• Siapkan pipeline pemuatan dengan produk Google Cloud. Google menyediakan sekumpulan template Dataflow streaming untuk memfasilitasi tugas ini.
• Gunakan solusi dari salah satu partners kami.

Dalam jangka pendek, meningkatkan jejak data BigQuery Anda dan menggunakannya untuk proses downstream harus berfokus pada pemenuhan kasus penggunaan prioritas utama Anda, dengan tujuan jangka menengah untuk memindahkan data warehouse yang ada. Gunakan iterasi awal dengan bijak dan jangan menghabiskan banyak resource untuk meningkatkan kualitas pipeline penyerapan dari data warehouse yang ada ke BigQuery. Pada akhirnya, Anda harus menyesuaikan pipeline tersebut agar tidak menggunakan data warehouse yang ada.

Mengoptimalkan skema

Cukup dengan memigrasikan tabel apa adanya ke BigQuery, Anda dapat memanfaatkan fitur-fitur uniknya. Misalnya, Anda tidak perlu membangun ulang indeks, melakukan reshuffle blok data (penyedotan) atau periode nonaktif atau penurunan performa karena upgrade versi.

Namun, menjaga agar model data warehouse tetap utuh di luar iterasi awal migrasi juga memiliki kekurangan:

• Masalah yang ada dan utang teknis yang terkait dengan skema tersebut tetap ada.
• Pengoptimalan kueri bersifat terbatas, dan mungkin perlu diulangi jika skema diperbarui di tahap selanjutnya.
• Anda tidak perlu sepenuhnya memanfaatkan fitur BigQuery lainnya, seperti kolom bertingkat dan berulang, partisi, dan pengelompokan.

Saat akan melakukan transfer akhir, sebaiknya tingkatkan performa sistem dengan menerapkan partisi dan pengelompokan ke tabel yang Anda buat dalam skema.

Membuat partisi

BigQuery memungkinkan Anda membagi data menjadi beberapa segmen, yang disebut partisi, yang mempermudah dan lebih efisien untuk mengelola serta membuat kueri data Anda. Anda dapat mempartisi tabel berdasarkan kolom TIMESTAMP atau DATE, atau BigQuery dapat menambahkan kolom semu untuk mempartisi data secara otomatis selama penyerapan. Kueri yang melibatkan partisi lebih kecil dapat berperforma lebih baik karena hanya memindai subset data, dan dapat mengurangi biaya dengan meminimalkan jumlah byte yang dibaca.

Partisi tidak memengaruhi struktur tabel yang ada. Oleh karena itu, Anda harus mempertimbangkan untuk membuat tabel yang dipartisi meskipun skema tidak dimodifikasi.

Pengelompokan

Di BigQuery, tidak ada indeks yang digunakan untuk mengkueri data Anda. Performa BigQuery dioptimalkan oleh model dasar, teknik penyimpanan dan kuerinya, serta arsitektur paralel secara masif. Saat Anda menjalankan kueri, makin banyak data yang diproses, makin banyak mesin yang ditambahkan untuk memindai data dan menggabungkan hasil secara serentak. Teknik ini diskalakan dengan baik untuk set data besar, tetapi tidak melakukan build ulang indeks.

Meskipun demikian, ada ruang untuk pengoptimalan kueri lebih lanjut dengan teknik seperti pengelompokan. Dengan pengelompokan, BigQuery mengurutkan data secara otomatis berdasarkan nilai dari beberapa kolom yang Anda tentukan dan menempatkannya dalam blok dengan ukuran optimal. Pengelompokan akan meningkatkan performa kueri dibandingkan dengan tidak menggunakan pengelompokan. Dengan pengelompokan, BigQuery dapat memperkirakan biaya menjalankan kueri dengan lebih baik dibandingkan tanpa pengelompokan. Dengan kolom yang dikelompokkan, kueri juga menghilangkan pemindaian data yang tidak diperlukan, dan dapat menghitung agregat dengan lebih cepat karena blok tersebut menempatkan kumpulan data dengan nilai yang serupa.

Periksa kueri Anda untuk kolom yang sering digunakan untuk memfilter, dan buat tabel dengan mengelompokkan pada kolom tersebut. Pengelompokan memerlukan tabel yang dipartisi dan juga ditentukan pada waktu pembuatan tabel.

Denormalisasi

Migrasi data adalah proses iteratif. Oleh karena itu, setelah Anda memindahkan skema awal ke cloud, melakukan pengoptimalan ringan, dan menguji beberapa kasus penggunaan utama, mungkin sudah waktunya untuk mengeksplorasi kemampuan tambahan yang mendapatkan manfaat dari desain dasar BigQuery. Ini mencakup kolom bertingkat dan berulang.

Skema data warehouse secara historis telah menggunakan model berikut:

• Skema Star. Ini adalah model yang didenormalisasi. Tabel fakta mengumpulkan metrik seperti jumlah pesanan, diskon, dan jumlah, bersama dengan grup kunci. Kunci ini termasuk dalam tabel dimensi seperti pelanggan, pemasok, wilayah, dan sebagainya. Secara grafis, model ini menyerupai bintang, dengan tabel fakta di tengah yang dikelilingi oleh tabel dimensi.
• Skema Snowflake. Ini mirip dengan skema bintang, tetapi dengan tabel dimensinya dinormalisasi, yang menampilkan skema snowflake yang unik.

BigQuery mendukung skema bintang dan snowflake, tetapi representasi skema native-nya tidak sama dengan keduanya. Kode ini menggunakan kolom bertingkat dan berulang, bukan untuk representasi data yang lebih alami. Untuk mengetahui informasi selengkapnya, lihat contoh skema dalam dokumentasi BigQuery.

Mengubah skema untuk menggunakan kolom bertingkat dan berulang adalah pilihan evolusioner yang sangat baik. Tindakan ini mengurangi jumlah join yang diperlukan untuk kueri Anda, dan menyelaraskan skema Anda dengan representasi data internal BigQuery. Secara internal, BigQuery mengatur data menggunakan model Dremel dan menyimpannya dalam format penyimpanan berbasis kolom yang disebut Capacitor.

Untuk menentukan pendekatan denormalisasi terbaik untuk kasus Anda, pertimbangkan praktik terbaik untuk denormalisasi di BigQuery serta teknik untuk menangani perubahan skema singkat ini.

Langkah selanjutnya

Pelajari lebih lanjut langkah-langkah berikut dalam migrasi data warehouse:

• Ringkasan migrasi
• Penilaian migrasi
• Pipeline data
• Terjemahan batch SQL
• Terjemahan SQL interaktif
• Tata kelola dan keamanan data
• Alat validasi data

Anda juga dapat mempelajari cara beralih dari teknologi data warehouse tertentu ke BigQuery:

• Bermigrasi dari Netezza
• Bermigrasi dari Oracle
• Bermigrasi dari Amazon Redshift
• Bermigrasi dari Teradata
• Bermigrasi dari Snowflake