Migrasi data, ETL, dan pemuatan untuk migrasi Teradata

Artikel ini adalah bagian kedua dari tujuh seri bagian yang memberikan panduan tentang cara bermigrasi dari Teradata ke Azure Synapse Analytics. Fokus artikel ini adalah praktik terbaik untuk ETL dan migrasi beban.

Pertimbangan migrasi data

Keputusan awal untuk migrasi data dari Teradata

Ketika memigrasikan gudang data Teradata, Anda perlu mengajukan beberapa pertanyaan dasar terkait data. Contohnya:

• Apakah struktur tabel yang tidak digunakan perlu dimigrasikan?

• Apa pendekatan migrasi terbaik untuk meminimalkan risiko dan dampak bagi pengguna?

• Saat memigrasikan data mart: tetap secara fisik atau virtual?

Bagian berikutnya membahas poin-poin ini dalam konteks migrasi dari Teradata.

Migrasikan tabel yang tidak digunakan?

Tip

Dalam sistem lama, tabel menjadi redundan dari waktu ke waktu adalah hal biasa—dalam banyak kasus, tabel tersebut tidak perlu dimigrasikan.

Hanya memigrasikan tabel yang sedang digunakan dalam sistem yang ada merupakan hal yang masuk akal. Tabel yang tidak aktif dapat diarsipkan, bukan dimigrasikan, sehingga data tersedia jika memerlukannya di masa mendatang. Sebaiknya gunakan metadata sistem dan file log daripada dokumentasi untuk menentukan tabel mana yang digunakan, karena dokumentasi bisa kedaluwarsa.

Jika diaktifkan, tabel dan log katalog sistem Teradata berisi informasi yang dapat menentukan kapan tabel tertentu terakhir diakses—yang selanjutnya dapat digunakan untuk memutuskan apakah tabel merupakan kandidat untuk migrasi.

Berikut ini contoh kueri pada DBC.Tables yang memberikan tanggal akses terakhir dan modifikasi terakhir:

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

Jika pencatatan diaktifkan dan riwayat log dapat diakses, informasi lain, seperti teks kueri SQL, tersedia di tabel DBQLogTbl dan tabel pencatatan terkait. Untuk informasi selengkapnya, lihat riwayat log Teradata.

Apa pendekatan migrasi terbaik untuk meminimalkan risiko dan dampak pada pengguna?

Pertanyaan ini sering muncul karena perusahaan ingin menurunkan dampak perubahan pada model data gudang data untuk meningkatkan ketangkasan. Perusahaan kerap melihat kesempatan untuk memodernisasi atau mengubah data mereka lebih lanjut selama migrasi ETL. Pendekatan ini membawa risiko yang lebih tinggi karena mengubah beberapa faktor secara bersamaan, sehingga sulit untuk membandingkan hasil sistem lama versus yang baru. Membuat perubahan model data di sini juga dapat memengaruhi pekerjaan ETL upstram atau hilir ke sistem lain. Karena risiko itu, sebaiknya desain ulang pada skala ini setelah migrasi gudang data.

Meskipun model data secara sengaja diubah sebagai bagian dari migrasi keseluruhan, praktik yang baik adalah memigrasikan model yang ada apa adanya ke Azure Synapse, bukan melakukan rekayasa ulang pada platform baru. Pendekatan ini meminimalkan dampak pada sistem produksi yang ada, sementara juga meningkatkan performa dan skalabilitas elastis platform Azure untuk tugas rekayasa ulang satu kali.

Saat bermigrasi dari Teradata, pertimbangkan untuk membuat lingkungan Teradata di mesin virtual dalam Azure sebagai batu loncatan dalam proses migrasi.

Tip

Migrasikan model yang ada apa adanya pada awalnya, bahkan jika perubahan pada model data direncanakan di masa mendatang.

Gunakan instans Teradata mesin virtual sebagai bagian dari migrasi

Salah satu pendekatan opsional untuk bermigrasi dari lingkungan Teradata lokal adalah dengan memanfaatkan lingkungan Azure untuk membuat instans Teradata di mesin virtual dalam Azure, yang dikolokasikan bersama dengan lingkungan Azure Synapse target. Ini dimungkinkan karena Azure menyediakan penyimpanan cloud yang murah dan skalabilitas yang elastis.

Dengan pendekatan ini, utilitas Teradata standar, seperti Teradata Parallel Data Transporter—atau alat replikasi data pihak ketiga, seperti Attunity Replicate—dapat digunakan untuk secara efisien memindahkan subset tabel Teradata yang perlu dimigrasikan ke instans mesin virtual. Kemudian, semua tugas migrasi dapat dilakukan dalam lingkungan Azure. Pendekatan ini memiliki beberapa manfaat:

• Setelah replikasi awal data, tugas migrasi tidak memengaruhi sistem sumber.

• Lingkungan Azure memiliki antarmuka, alat, dan utilitas Teradata yang familier.

• Lingkungan Azure menyediakan ketersediaan bandwidth jaringan antara sistem sumber lokal dan sistem target cloud.

• Alat seperti Azure Data Factory dapat secara efisien memanggil utilitas seperti Teradata Parallel Transporter untuk memigrasikan data dengan cepat dan mudah.

• Proses migrasi diatur dan dikendalikan sepenuhnya dalam lingkungan Azure.

Saat memigrasikan data mart: tetap secara fisik atau virtual?

Tip

Virtualisasi data mart dapat menghemat penyimpanan dan sumber daya pemrosesan.

Di lingkungan gudang data Teradata lama, merupakan praktik umum untuk membuat beberapa data mart yang terstruktur untuk memberikan performa yang baik untuk kueri dan laporan layanan mandiri ad hoc untuk departemen atau fungsi bisnis tertentu dalam suatu organisasi. Dengan demikian, data mart biasanya terdiri dari subset gudang data dan berisi versi agregat data dalam bentuk yang memungkinkan pengguna untuk dengan mudah menanyakan data tersebut dengan waktu respons yang cepat melalui alat kueri yang mudah digunakan seperti Microsoft Power BI, Tableau, atau MicroStrategy. Formulir ini biasanya merupakan model data dimensional. Salah satu penggunaan data mart adalah untuk mengekspos data dalam bentuk yang dapat digunakan, bahkan jika model data gudang yang mendasarinya adalah sesuatu yang berbeda, seperti brankas data.

Anda dapat menggunakan data mart terpisah untuk unit bisnis individu dalam suatu organisasi untuk menerapkan rezim keamanan data yang kuat, dengan hanya mengizinkan pengguna mengakses data mart tertentu yang relevan dengan mereka, dan menghilangkan, mengaburkan, atau menganonimkan data sensitif.

Jika data mart ini diimplementasikan sebagai tabel fisik, mereka akan memerlukan sumber daya penyimpanan tambahan untuk menyimpannya, dan pemrosesan tambahan untuk membangun dan menyegarkannya secara teratur. Selain itu, data di mart hanya akan diperbarui seperti operasi penyegaran terakhir, dan mungkin tidak cocok untuk dasbor data yang sangat fluktuatif.

Tip

Performa dan skalabilitas Azure Synapse memungkinkan virtualisasi tanpa mengorbankan performa.

Dengan munculnya arsitektur MPP scalable yang relatif murah, seperti Azure Synapse, dan karakteristik performa yang melekat dari arsitektur tersebut, mungkin Anda dapat menyediakan fungsionalitas data mart tanpa harus membuat instans mart sebagai satu set tabel fisik. Hal ini dicapai dengan memvirtualisasikan data mart secara efektif melalui tampilan SQL ke gudang data utama, atau melalui lapisan virtualisasi menggunakan fitur seperti tampilan di Azure atau produk visualisasi mitra Microsoft. Pendekatan ini menyederhanakan atau menghilangkan kebutuhan untuk penyimpanan tambahan dan pemrosesan agregasi dan mengurangi jumlah keseluruhan objek database yang akan dimigrasikan.

Ada manfaat potensial lainnya untuk pendekatan ini. Dengan menerapkan agregasi dan logika gabungan di dalam lapisan virtualisasi, dan menghadirkan alat pelaporan eksternal melalui tampilan yang divirtualisasikan, pemrosesan yang diperlukan untuk membuat tampilan ini “didorong” ke dalam gudang data, yang umumnya merupakan tempat yang terbaik untuk menjalankan gabungan, agregasi, dan operasi terkait lainnya pada volume data yang besar.

Penggerak utama untuk memilih implementasi data mart virtual daripada data mart fisik adalah:

• Lebih tangkas: data mart virtual lebih mudah diubah daripada tabel fisik dan proses ETL yang terkait.

• Total biaya kepemilikan yang lebih rendah, karena implementasi yang divirtualisasikan memerlukan lebih sedikit penyimpanan data dan salinan data.

• Penghapusan tugas ETL untuk bermigrasi dan menyederhanakan arsitektur gudang data dalam lingkungan virtual.

• Performa, karena meskipun data mart fisik secara historis lebih berkinerja, produk virtualisasi sekarang menerapkan teknik penembolokan cerdas untuk memitigasi.

Migrasi data dari Teradata

Memahami data Anda

Bagian dari perencanaan migrasi adalah memahami secara detail volume data yang perlu dimigrasikan karena dapat memengaruhi keputusan tentang pendekatan migrasi. Gunakan metadata sistem untuk menentukan ruang fisik yang digunakan oleh “data mentah” di dalam tabel yang akan dimigrasikan. Di dalam konteks ini, “data mentah” berarti jumlah ruang yang digunakan oleh baris data di dalam sebuah tabel, tidak termasuk overhead seperti indeks dan kompresi. Hal ini terutama berlaku untuk tabel fakta terbesar karena ini biasanya terdiri dari lebih dari 95% data.

Anda bisa mendapatkan angka yang akurat untuk volume data yang akan dimigrasikan untuk tabel tertentu dengan mengekstrak sampel data yang representatif—misalnya, satu juta baris—ke file data ASCII datar tanpa batas yang tidak terkompresi. Kemudian, gunakan ukuran file itu untuk mendapatkan ukuran data mentah rata-rata per baris tabel itu. Terakhir, kalikan ukuran rata-rata itu dengan jumlah total baris dalam tabel lengkap untuk memberikan ukuran data mentah untuk tabel. Gunakan ukuran data mentah itu dalam perencanaan Anda.

Pertimbangan migrasi ETL

Keputusan awal mengenai migrasi ETL Teradata

Tip

Rencanakan pendekatan untuk migrasi ETL sebelumnya dan manfaatkan fasilitas Azure jika sesuai.

Untuk pemrosesan ETL/ELT, gudang data Teradata lawas dapat menggunakan skrip yang dibuat khusus menggunakan utilitas Teradata seperti BTEQ dan Teradata Parallel Transporter (TPT), atau alat ETL pihak ketiga seperti Informatica atau Ab Initio. Terkadang, gudang data Teradata menggunakan kombinasi pendekatan ETL dan ELT yang berkembang seiring waktu. Saat merencanakan migrasi ke Azure Synapse, Anda perlu menentukan cara terbaik untuk menerapkan pemrosesan ETL/ELT yang diperlukan di lingkungan baru sambil meminimalkan biaya dan risiko yang terlibat. Untuk mempelajari selengkapnya tentang pemrosesan ETL dan ELT, lihat pendekatan desain ELT vs ETL.

Bagian berikut membahas opsi migrasi dan membuat rekomendasi untuk berbagai kasus penggunaan. Diagram alur ini merangkum satu pendekatan:

Langkah pertama adalah selalu membuat inventaris proses ETL/ELT yang perlu dimigrasikan. Seperti langkah-langkah lainnya, mungkin saja fitur standar “bawaan” Azure membuatnya tidak perlu memigrasikan beberapa proses yang ada. Untuk tujuan perencanaan, penting untuk memahami skala migrasi yang akan dilakukan.

Dalam diagram alur sebelumnya, keputusan 1 berkaitan dengan keputusan tingkat tinggi tentang apakah akan bermigrasi ke lingkungan native Azure sepenuhnya. Jika Anda pindah ke lingkungan yang benar-benar asli Azure, kami menyarankan Anda merekayasa ulang pemrosesan ETL menggunakan Alur dan aktivitas di Azure Data Factory atau Alur Azure Synapse. Jika Anda tidak pindah ke lingkungan native total Azure, keputusan 2 adalah apakah alat ETL pihak ketiga yang ada sudah digunakan.

Di lingkungan Teradata, beberapa atau semua pemrosesan ETL dapat dilakukan oleh skrip khusus menggunakan utilitas khusus Teradata seperti BTEQ dan TPT. Dalam hal ini, pendekatan Anda harus merekayasa ulang menggunakan Data Factory.

Tip

Manfaatkan investasi di alat pihak ketiga yang ada untuk mengurangi biaya dan risiko.

Jika alat ETL pihak ketiga sudah digunakan, dan terutama jika ada investasi besar dalam keterampilan atau beberapa alur kerja dan jadwal yang ada menggunakan alat tersebut, keputusan 3 adalah apakah alat dapat secara efisien mendukung Azure Synapse sebagai lingkungan target. Idealnya, alat ini akan mencakup konektor “asli” yang dapat memanfaatkan fasilitas Azure seperti PolyBase atau COPY INTO, untuk pemuatan data yang paling efisien. Ada cara untuk memanggil proses eksternal, seperti PolyBase atau COPY INTO, dan meneruskan parameter yang sesuai. Dalam hal ini, manfaatkan keterampilan dan alur kerja yang ada, dengan Azure Synapse sebagai lingkungan target baru.

Jika Anda memutuskan untuk mempertahankan alat ETL pihak ketiga yang ada, mungkin ada manfaat menjalankan alat tersebut dalam lingkungan Azure (bukan di server ETL lokal yang ada) dan membuat Azure Data Factory menangani orkestrasi keseluruhan alur kerja yang ada. Satu manfaat khusus adalah lebih sedikit data yang perlu diunduh dari Azure, diproses, dan kemudian diunggah kembali ke Azure. Jadi, keputusan 4 adalah apakah akan membiarkan alat yang ada berjalan apa adanya atau memindahkannya ke lingkungan Azure untuk mencapai manfaat biaya, performa, dan skalabilitas.

Rekayasa ulang skrip khusus Teradata yang ada

Jika beberapa atau semua pemrosesan ETL/ELT gudang Teradata yang ada ditangani oleh skrip kustom yang menggunakan utilitas khusus Teradata, seperti BTEQ, MLOAD, atau TPT, skrip ini perlu dikode ulang untuk lingkungan Azure Synapse yang baru. Demikian pula, jika proses ETL diterapkan menggunakan prosedur tersimpan di Teradata, ini juga harus dikodekan ulang.

Tip

Inventarsi tugas ETL yang akan dimigrasikan harus mencakup skrip dan prosedur tersimpan.

Beberapa elemen proses ETL mudah dipindahkan, misalnya dengan memuat data massal sederhana ke dalam tabel staging dari file eksternal. Bahkan dimungkinkan untuk mengotomatisasi bagian-bagian proses tersebut, misalnya, dengan menggunakan PolyBase alih-alih memuat cepat atau MLOAD. Jika file yang diekspor adalah Parquet, Anda dapat menggunakan pembaca Parquet asli, yang merupakan opsi yang lebih cepat daripada PolyBase. Bagian lain dari proses yang berisi SQL kompleks yang berubah-ubah dan/atau prosedur tersimpan akan membutuhkan lebih banyak waktu untuk direkayasa ulang.

Salah satu cara menguji Teradata SQL untuk kompatibilitas dengan Azure Synapse adalah dengan menangkap beberapa pernyataan SQL representatif dari log Teradata, lalu mengawali kueri tersebut denganEXPLAIN, lalu—misalnya, model data yang dimigrasikan like-for-like di Azure Synapse—jalankan pernyataan EXPLAIN tersebut di Azure Synapse. SQL yang tidak kompatibel akan menghasilkan kesalahan, dan informasi kesalahan dapat menentukan skala tugas pengodean ulang.

Mitra Microsoft menawarkan alat dan layanan untuk memigrasikan Teradata SQL dan prosedur tersimpan ke Azure Synapse.

Menggunakan alat ETL pihak ketiga

Seperti yang dijelaskan di bagian sebelumnya, dalam banyak kasus, sistem gudang data lama yang ada sudah akan diisi dan dikelola oleh produk ETL pihak ketiga. Untuk daftar mitra integrasi data Microsoft untuk Azure Synapse, lihat Mitra integrasi data.

Pemuatan data dari Teradata

Pilihan tersedia saat memuat data dari Teradata

Tip

Alat pihak ketiga dapat menyederhanakan dan mengotomatiskan proses migrasi dan karenanya mengurangi risiko.

Dalam hal memigrasikan data dari gudang data Teradata, ada beberapa pertanyaan dasar yang terkait dengan pemuatan data yang perlu diselesaikan. Anda harus memutuskan bagaimana data akan dipindahkan secara fisik dari lingkungan Teradata lokal yang ada ke Azure Synapse di cloud, dan alat mana yang akan digunakan untuk melakukan transfer dan memuat. Pertimbangkan pertanyaan-pertanyaan berikut, yang akan dibahas di bagian selanjutnya.

• Apakah Anda akan mengekstrak data ke file, atau memindahkannya langsung melalui koneksi jaringan?

• Apakah Anda akan mengatur proses dari sistem sumber, atau dari lingkungan target Azure?

• Alat mana yang akan Anda gunakan untuk mengotomatisasi dan mengelola proses?

Mentransfer data melalui file atau koneksi jaringan?

Tip

Pahami volume data yang akan dimigrasikan dan bandwidth jaringan yang tersedia karena faktor-faktor ini memengaruhi keputusan pendekatan migrasi.

Setelah tabel database yang akan dimigrasikan dibuat di Azure Synapse, Anda dapat memindahkan data untuk mengisi tabel tersebut keluar dari sistem Teradata lama dan ke lingkungan baru. Ada dua pendekatan dasar:

• Ekstrak file: ekstrak data dari tabel Teradata ke file datar, biasanya dalam format CSV, melalui BTEQ, Ekspor Cepat, atau Teradata Parallel Transporter (TPT). Gunakan TPT bila memungkinkan karena ini yang paling efisien dalam hal throughput data.

  Pendekatan ini membutuhkan ruang untuk mendaratkan file data yang diekstraksi. Ruang dapat berupa lokal ke database sumber Teradata (jika penyimpanan yang memadai tersedia), atau jarak jauh di Azure Blob Storage. Performa terbaik dicapai ketika file ditulis secara lokal, karena itu menghindari overhead jaringan.

  Untuk meminimalkan persyaratan penyimpanan dan transfer jaringan, praktik yang baik adalah mengompresi file data yang diekstrak menggunakan utilitas seperti gzip.

  Begitu diekstraksi, file datar dapat dipindahkan ke Azure Blob Storage (ditempatkan dengan instans Azure Synapse target) atau dimuat langsung ke Azure Synapse menggunakan PolyBase atau COPY INTO. Metode untuk memindahkan data secara fisik dari penyimpanan lokal ke lingkungan cloud Azure bergantung pada jumlah data dan bandwidth jaringan yang tersedia.

  Microsoft menyediakan opsi berbeda untuk memindahkan data dalam jumlah besar, termasuk AZCopy untuk memindahkan file di seluruh jaringan ke Azure Storage, Azure ExpressRoute untuk memindahkan data massal melalui koneksi jaringan pribadi, dan Azure Data Box tempat file dipindahkan ke perangkat penyimpanan fisik yang kemudian dikirim ke pusat data Azure untuk dimuat. Untuk informasi lebih lanjut, lihat transfer data.

• Ekstrak dan pemuatan langsung di seluruh jaringan: lingkungan Azure target mengirimkan permintaan ekstrak data, biasanya melalui perintah SQL, ke sistem Teradata lama untuk mengekstrak data. Hasilnya dikirim di seluruh jaringan dan dimuat langsung ke Azure Synapse, tanpa perlu memasukkan data ke dalam file perantara. Faktor pembatas dalam skenario ini biasanya bandwidth koneksi jaringan antara database Teradata dan lingkungan Azure. Untuk volume data yang sangat besar, pendekatan ini mungkin tidak praktis.

Ada juga pendekatan hibrida yang menggunakan kedua metode tersebut. Misalnya, Anda dapat menggunakan pendekatan ekstrak jaringan langsung untuk tabel dimensi yang lebih kecil dan sampel tabel fakta yang lebih besar untuk menyediakan lingkungan pengujian di Azure Synapse dengan cepat. Untuk tabel fakta historis volume besar, Anda dapat menggunakan pendekatan ekstrak dan transfer file menggunakan Azure Data Box.

Atur dari Teradata atau Azure?

Pendekatan yang disarankan saat berpindah ke Azure Synapse adalah mengatur ekstrak dan pemuatan data dari lingkungan Azure menggunakan Alur Azure Synapse atau Azure Data Factory, serta utilitas terkait, seperti PolyBase atau COPY INTO, untuk pemuatan data yang paling efisien. Pendekatan ini memanfaatkan kemampuan Azure dan menyediakan metode yang mudah untuk membangun alur pemuatan data yang dapat digunakan kembali.

Manfaat lain dari pendekatan ini termasuk pengurangan dampak pada sistem Teradata selama proses pemuatan data karena proses manajemen dan pemuatan berjalan di Azure, dan kemampuan untuk mengotomatiskan proses dengan menggunakan alur pemuatan data berbasis metadata.

Alat apa saja yang bisa digunakan?

Tugas transformasi dan pergerakan data adalah fungsi dasar dari semua produk ETL. Jika salah satu produk ini sudah digunakan di lingkungan Teradata yang ada, menggunakan alat ETL yang ada dapat menyederhanakan migrasi data dari Teradata ke Azure Synapse. Pendekatan ini mengasumsikan bahwa alat ETL mendukung Azure Synapse sebagai lingkungan target. Untuk informasi selengkapnya tentang alat yang mendukung Azure Synapse, lihat Mitra integrasi data.

Jika Anda menggunakan alat ETL, pertimbangkan untuk menjalankan alat tersebut dalam lingkungan Azure untuk mendapatkan manfaat dari performa, skalabilitas, dan biaya cloud Azure, serta mengosongkan sumber daya di pusat data Teradata. Manfaat lainnya adalah berkurangnya pergerakan data antara cloud dan lingkungan lokal.

Ringkasan

Singkatnya, rekomendasi kami untuk memigrasi data dan proses ETL terkait dari Teradata ke Azure Synapse adalah:

• Rencanakan lebih dahulu guna memastikan keberhasilan latihan migrasi.

• Buat inventaris detail data dan proses yang akan dimigrasikan sesegera mungkin.

• Gunakan metadata sistem dan file log untuk mendapatkan pemahaman yang akurat tentang penggunaan data dan proses. Jangan mengandalkan dokumentasi karena mungkin itu sudah kedaluwarsa.

• Pahami volume data yang akan dimigrasikan, dan bandwidth jaringan antara pusat data lokal dan lingkungan cloud Azure.

• Pertimbangkan untuk menggunakan instans Teradata di mesin virtual Azure sebagai batu loncatan untuk memindahkan beban migrasi dari lingkungan Teradata lama.

• Manfaatkan fitur Azure bawaan standar untuk meminimalkan beban kerja migrasi.

• Identifikasi dan pahami alat paling efisien untuk ekstraksi dan pemuatan data di lingkungan Teradata dan Azure. Gunakan alat yang sesuai di setiap fase dalam prosesnya.

• Gunakan fasilitas Azure seperti Alur Azure Synapse atau Azure Data Factory untuk mengatur dan mengotomatiskan proses migrasi serta meminimalkan dampak pada sistem Teradata.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang operasi akses keamanan, lihat artikel berikutnya dalam seri ini: Keamanan, akses, dan operasi untuk migrasi Teradata.