Memigrasikan pipeline data

Dokumen ini menjelaskan cara memigrasikan pipeline data upstream, yang memuat data ke dalam data warehouse Anda. Anda dapat menggunakan dokumen ini untuk lebih memahami pengertian pipeline data, prosedur dan pola yang dapat digunakan pipeline, serta opsi dan teknologi migrasi mana yang tersedia untuk migrasi data warehouse.

Apa itu pipeline data?

Dalam komputasi, pipeline data adalah jenis aplikasi yang memproses data melalui serangkaian langkah pemrosesan yang terhubung. Sebagai konsep umum, pipeline data dapat diterapkan, misalnya, untuk transfer data antar sistem informasi, ekstraksi, transformasi, dan pemuatan (ETL), pengayaan data, dan analisis data secara real time. Biasanya, pipeline data dioperasikan sebagai proses batch yang mengeksekusi dan memproses data saat dijalankan, atau sebagai proses streaming yang mengeksekusi secara terus-menerus dan memproses data saat tersedia untuk digunakan dalam pipeline.

Dalam konteks data warehousing, pipeline data biasanya digunakan untuk membaca data dari sistem transaksional, menerapkan transformasi, lalu menulis data ke data warehouse. Setiap transformasi dijelaskan oleh sebuah fungsi, dan input untuk setiap fungsi tertentu merupakan output dari fungsi atau fungsi-fungsi sebelumnya. Fungsi yang terhubung ini dijelaskan sebagai grafik, dan grafik ini sering disebut sebagai Directed Acyclic Graph (DAG)—yaitu, grafik mengikuti arah (dari sumber ke tujuan), dan acyclic—input untuk fungsi apa pun tidak boleh bergantung pada output fungsi lain di downstream dalam DAG. Dengan kata lain, loop tidak diizinkan. Setiap node grafik adalah sebuah fungsi, dan setiap edge mewakili data yang mengalir dari satu fungsi ke fungsi berikutnya. Fungsi awalnya adalah sumber, atau koneksi ke sistem data sumber. Fungsi akhirnya adalah sink, atau koneksi ke sistem data tujuan.

Dalam konteks pipeline data, sumber biasanya berupa sistem transaksional—misalnya, RDBMS—dan sink terhubung ke data warehouse. Jenis grafik ini disebut sebagai DAG aliran data. Anda juga dapat menggunakan DAG untuk mengatur perpindahan data antara pipeline data dan sistem lainnya. Penggunaan ini disebut sebagai orkestrasi atau DAG alur kontrol.

Saat yang tepat untuk memigrasikan pipeline data

Saat memigrasikan kasus penggunaan ke BigQuery, Anda dapat memilih untuk mengurangi beban atau migrasikan sepenuhnya.

Di satu sisi, saat Anda mengurangi beban suatu kasus penggunaan, Anda tidak perlu memigrasikan pipeline data upstreamnya sejak awal. Pertama-tama, migrasikan skema dan data kasus penggunaan dari data warehouse yang ada ke BigQuery. Kemudian, buat salinan bertahap dari data warehouse lama ke baru untuk menjaga agar data tetap sinkron. Terakhir, lakukan migrasi dan validasi pada proses downstream seperti skrip, kueri, dasbor, dan aplikasi bisnis.

Pada tahap ini, pipeline data upstream Anda tidak berubah dan masih menulis data ke data warehouse yang ada. Anda dapat menyertakan kembali kasus penggunaan yang bebannya sudah dikurangi di backlog migrasi untuk dimigrasikan sepenuhnya dalam iterasi berikutnya.

Di sisi lain, jika Anda sepenuhnya memigrasikan kasus penggunaan, pipeline data upstream yang diperlukan untuk kasus penggunaan tersebut akan dimigrasikan ke Google Cloud. Migrasi penuh mengharuskan Anda mengurangi beban kasus penggunaan terlebih dahulu. Setelah migrasi penuh, Anda dapat menghentikan penggunaan tabel lama yang sesuai dari data warehouse lokal karena data diserap langsung ke BigQuery.

Selama iterasi, Anda dapat memilih salah satu opsi berikut:

  • Hanya kurangi beban kasus penggunaan Anda.
  • Migrasikan sepenuhnya kasus penggunaan yang bebannya dikurangi sebelumnya.
  • Migrasikan sepenuhnya kasus penggunaan dari awal dengan mengurangi bebannya terlebih dahulu dalam iterasi yang sama.

Setelah semua kasus penggunaan Anda dimigrasikan sepenuhnya, Anda dapat memilih untuk menonaktifkan warehouse lama, yang merupakan langkah penting untuk mengurangi overhead dan biaya.

Cara memigrasikan pipeline data

Bagian selanjutnya dari dokumen ini membahas cara memigrasikan pipeline data Anda, termasuk pendekatan, prosedur, dan teknologi yang harus digunakan. Opsinya bervariasi, mulai dari menggunakan kembali pipeline data yang sudah ada (mengalihkannya untuk memuat ke BigQuery) hingga menulis ulang pipeline data guna memanfaatkan layanan yang dikelola Google Cloud.

Prosedur dan pola untuk pipeline data

Anda dapat menggunakan pipeline data untuk menjalankan sejumlah prosedur dan pola. Pipeline ini adalah yang paling umum digunakan dalam data warehousing. Anda mungkin memiliki pipeline data batch atau pipeline data streaming. Pipeline data batch berjalan pada data yang dikumpulkan selama jangka waktu tertentu (misalnya, sekali sehari). Pipeline data streaming menangani peristiwa real-time yang dihasilkan oleh sistem operasional Anda—misalnya, dalam perubahan baris CDC yang dihasilkan oleh database Pemrosesan Transaksi Online (OLTP).

Ekstraksi, transformasi, dan pemuatan (ETL)

Dalam konteks data warehousing, pipeline data sering menjalankan prosedur ekstraksi, transformasi, dan pemuatan (ETL). Teknologi ETL berjalan di luar data warehouse. Artinya, resource data warehouse dapat digunakan terutama untuk pembuatan kueri secara serentak, alih-alih untuk menyiapkan dan mengubah data. Salah satu kelemahan dari transformasi yang dijalankan di luar data warehouse adalah Anda harus mempelajari alat dan bahasa tambahan (selain SQL) untuk mengekspresikan transformasi.

Diagram berikut menunjukkan prosedur ETL umum.

Alur yang menunjukkan sumber (ekstraksi) yang mengarah ke satu atau beberapa transformasi (transformasi), lalu ke sink, dan terakhir ke data warehouse (pemuatan)

Gambar 1. Prosedur ETL umum.

Pipeline data ETL yang umum mengambil data dari satu atau beberapa sistem sumber (sebaiknya, sesedikit mungkin untuk menghindari kegagalan yang disebabkan oleh masalah seperti sistem yang tidak tersedia). Selanjutnya, pipeline melakukan serangkaian transformasi, termasuk membersihkan data, menerapkan aturan bisnis, memeriksa integritas data, dan membuat penggabungan atau pemisahan. Untuk mengetahui informasi selengkapnya, lihat Siklus ETL di kehidupan nyata.

Memiliki beberapa pipeline data adalah hal yang umum. Pipeline pertama berfokus pada penyalinan data dari sistem sumber ke data warehouse. Pipeline berikutnya menerapkan logika bisnis dan mengubah data untuk digunakan di berbagai data mart, yang merupakan subset dari data warehouse yang berfokus pada unit bisnis atau fokus bisnis tertentu.

Jika memiliki beberapa pipeline data, Anda perlu mengaturnya. Diagram berikut menunjukkan tampilan proses orkestrasi ini.

Orkestrator (DAG) yang mengelola dua proses WTL (Sub DAG)

Gambar 2. Proses orkestrasi untuk beberapa pipeline data.

Dalam diagram, setiap pipeline data dianggap sebagai sub-DAG dari DAG orkestrasi. Setiap orkestrasi DAG mencakup beberapa pipeline data agar selaras dengan tujuan yang lebih besar, misalnya, menyiapkan data untuk unit bisnis sehingga analis bisnis dapat menjalankan dasbor atau laporan mereka.

Ekstraksi, pemuatan, dan transformasi (ELT)

ELT adalah alternatif untuk ETL. Dengan ELT, pipeline data dibagi menjadi dua bagian. Pertama, teknologi ELT mengekstrak data dari sistem sumber dan memuatnya ke data warehouse. Kedua, skrip SQL di atas data warehouse melakukan transformasi. Kelebihan dari pendekatan ini adalah Anda dapat menggunakan SQL untuk mengekspresikan transformasi. Sementara itu, kelemahannya adalah pendekatan ini mungkin memakai resource data warehouse yang diperlukan untuk pembuatan kueri secara serentak. Oleh karena itu, batch ELT sering berjalan pada malam hari (atau di luar waktu puncak) saat resource sistem data warehouse memiliki permintaan yang lebih rendah.

Diagram berikut menunjukkan prosedur ELT yang umum.

Alur yang menunjukkan sumber (ekstraksi) yang mengarah ke satu atau beberapa transformasi (transformasi), lalu ke sink, dan terakhir ke data warehouse (pemuatan).

Gambar 3. Prosedur ELT umum.

Saat Anda mengadopsi pendekatan ELT, biasanya ekstraksi dan pemuatan dipisahkan ke dalam satu DAG, dan transformasi dipisahkan ke dalam DAG-nya sendiri. Data dimuat ke data warehouse satu kali, lalu diubah beberapa kali untuk membuat berbagai tabel yang digunakan downstream dalam pelaporan dan seterusnya. DAG ini kemudian menjadi sub-DAG dalam DAG orkestrasi yang lebih besar (seperti yang ditunjukkan di bagian EL).

Ketika Anda memigrasikan pipeline data dari data warehouse lokal yang padat ke cloud, penting untuk mengingat bahwa sistem cloud data warehouse (CDW), seperti BigQuery adalah teknologi pemrosesan data paralel secara masif. Bahkan dalam kasus BigQuery, Anda dapat membeli lebih banyak resource untuk mendukung peningkatan permintaan untuk ELT dan pembuatan kueri serentak. Untuk mengetahui informasi selengkapnya, lihat Pengantar cara mengoptimalkan performa kueri.

Ekstraksi dan pemuatan (EL)

Anda dapat menggunakan prosedur ekstraksi dan pemuatan (EL) sendiri atau diikuti dengan transformasi, yang dalam hal ini menjadi ELT. EL disebutkan secara terpisah karena tersedia beberapa layanan otomatis yang melakukan tugas ini, sehingga Anda tidak perlu membuat pipeline data penyerapan Anda sendiri. Untuk mengetahui detail selengkapnya, lihat BigQuery Data Transfer Service.

Pengambilan data perubahan (CDC)

Pengambilan data perubahan (CDC) adalah salah satu dari beberapa pola desain software yang digunakan untuk melacak perubahan data. Pengambilan data perubahan sering digunakan dalam data warehousing karena data warehouse digunakan untuk menyusun dan melacak data serta perubahannya dari berbagai sistem sumber dari waktu ke waktu.

Diagram berikut menunjukkan contoh cara kerja CDC dengan ELT.

Alur ETL yang menunjukkan kumpulan data individual dengan informasi versi yang ditetapkan saat ekstraksi dan stempel waktu yang ditambahkan saat pemuatan.

Gambar 4. Cara kerja CDC dengan ELT.

CDC berfungsi baik dengan ELT karena Anda ingin menyimpan kumpulan data asli sebelum melakukan perubahan apa pun ke downstream.

Agar bagian EL terjadi, Anda dapat memproses log database dengan menggunakan software CDC seperti Datastream atau alat open source seperti Debezium dan menulis kumpulan data ke BigQuery menggunakan Dataflow. Kemudian, Anda dapat menggunakan kueri SQL untuk menentukan versi terbaru sebelum menerapkan transformasi lebih lanjut. Berikut contohnya:

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

Saat Anda memfaktorkan ulang atau membuat pipeline data baru, pertimbangkan untuk menggunakan pola CDC yang diterapkan sebagai prosedur ELT. Pendekatan ini memastikan bahwa Anda memiliki histori lengkap tentang perubahan data upstream dan memberikan pemisahan tanggung jawab yang baik, misalnya:

  • Tim sistem sumber memastikan ketersediaan log dan publikasi peristiwa data mereka.
  • Tim platform data memastikan bahwa kolasi penyerapan kumpulan data asli menyertakan stempel waktu di data warehouse.
  • Tim analis dan data engineer menjadwalkan serangkaian transformasi untuk mengisi data mart mereka.

Feedback loop dengan pipeline data operasional

Pipeline data operasional adalah pipeline pemrosesan data yang mengambil data dari data warehouse, mengubahnya jika diperlukan, dan menulis hasilnya ke dalam sistem operasi.

Sistem operasional mengacu pada sistem yang memproses transaksi sehari-hari organisasi, seperti database OLTP, sistem Pengelolaan Hubungan Pelanggan (CRM), sistem Pengelolaan Katalog Produk (PCM), dan sebagainya. Karena sistem-sistem ini sering bertindak sebagai sumber data, pipeline data operasional mengimplementasikan pola feedback loop.

Pola pipeline data operasional ditampilkan dalam diagram berikut.

Pipeline ETL memasukkan data ke data warehouse, lalu ke pipeline operasional yang memasukkan data kembali ke sistem sumber yang memasukan data ke pipeline ETL.

Gambar 5. Pola untuk pipeline data operasional.

Contoh berikut menjelaskan pipeline data operasional yang menulis harga produk ke dalam sistem PCM. Sistem PCM adalah sistem otoritatif untuk informasi produk terkait penjualan seperti warna, saluran penjualan, harga, dan tren musiman. Berikut adalah aliran data secara menyeluruh:

  • Data terkait harga tersedia dari berbagai sumber. Data ini dapat mencakup harga saat ini berdasarkan region dari PCM, harga pesaing dari layanan pihak ketiga, perkiraan permintaan, dan keandalan pemasok dari sistem internal, dan sebagainya.
  • Pipeline ETL mengambil data dari sumber, mentransformasinya, dan menulis hasilnya ke dalam data warehouse. Dalam hal ini, transformasi adalah perhitungan kompleks yang melibatkan semua sumber dengan tujuan menghasilkan harga dasar yang optimal untuk setiap produk di PCM.
  • Terakhir, pipeline operasional mengambil harga dasar dari data warehouse, melakukan transformasi ringan untuk menyesuaikan harga peristiwa musiman, dan menuliskan harga akhir kembali ke PCM.

Sistem PCM dimasukkan ke dalam sistem ETL.

Gambar 6. Pipeline data operasional yang menuliskan harga produk ke dalam sistem PCM.

Pipeline data operasional adalah jenis proses downstream, sedangkan pipeline data yang menerapkan ETL, ELT, atau CDC adalah proses upstream. Meskipun demikian, alat yang digunakan untuk mengimplementasikan keduanya dapat tumpang-tindih. Misalnya, Anda dapat menggunakan Dataflow untuk menentukan dan menjalankan semua DAG pemrosesan data, GoogleSQL untuk menentukan transformasi yang dijalankan dalam BigQuery, dan Cloud Composer untuk mengatur aliran data yang menyeluruh.

Memilih pendekatan migrasi

Bagian ini menjelaskan berbagai pendekatan yang dapat Anda gunakan untuk memigrasikan pipeline data Anda.

Mengalihkan pipeline data untuk menulis ke BigQuery

Dalam kondisi berikut, Anda dapat mempertimbangkan apakah teknologi yang Anda gunakan menawarkan sink BigQuery bawaan (konektor tulis):

  • Data warehouse lama diumpankan oleh pipeline data yang menjalankan prosedur ETL.
  • Logika transformasi dijalankan sebelum data disimpan di data warehouse.

Vendor software independen (ISV) menawarkan teknologi pemrosesan data dengan konektor BigQuery, termasuk hal berikut:

Jika teknologi pipeline data tidak mendukung penyerapan data ke BigQuery, pertimbangkan untuk menggunakan variasi pada pendekatan ini yang menulis data untuk sementara ke file yang kemudian diserap oleh BigQuery.

Pipeline data yang diblokir agar tidak masuk ke sistem lama dan sebagai gantinya dimasukkan ke BigQuery.

Gambar 7. Menulis ulang, atau mengonfigurasi ulang, fungsi terakhir pipeline data untuk menulis data ke BigQuery.

Pada tingkat tinggi, pekerjaan yang terlibat meliputi menulis ulang, atau mengonfigurasi ulang, fungsi terakhir pipeline data untuk menulis data ke BigQuery. Namun, Anda akan menghadapi sejumlah opsi yang mungkin memerlukan perubahan tambahan atau pekerjaan baru, misalnya:

Fungsional

  • Pemetaan data: Mengingat skema tabel database target mungkin berubah, Anda mungkin perlu mengonfigurasi ulang pemetaan ini.
  • Validasi metrik: Anda harus memvalidasi laporan historis dan laporan baru, karena skema dan kueri dapat berubah.

Nonfungsional

  • Firewall mungkin perlu dikonfigurasi untuk mengizinkan transfer data keluar dari lokal ke BigQuery.
  • Perubahan jaringan mungkin diperlukan untuk menghasilkan bandwidth tambahan, guna mengakomodasi transfer data keluar.

Mengalihkan pipeline data menggunakan file sebagai sarana perantara

Jika teknologi pipeline data lokal yang ada tidak mendukung Google API , atau jika Anda dilarang menggunakan Google API, Anda dapat menggunakan file sebagai sarana perantara bagi data Anda untuk menjangkau BigQuery.

Pendekatan ini mirip dengan pendekatan pengalihan, tetapi alih-alih menggunakan sink native yang dapat menulis ke BigQuery, Anda menggunakan sink yang dapat menulis ke sistem file lokal. Setelah data Anda berada di sistem file, Anda dapat menyalin file tersebut ke Cloud Storage. Untuk mengetahui detail selengkapnya, lihat ringkasan opsi penyerapan untuk Cloud Storage dan kriteria yang terlibat dalam pemilihan opsi penyerapan.

Langkah terakhir adalah memuat data dari Cloud Storage ke BigQuery dengan mengikuti panduan dalam Pemuatan batch data.

Diagram berikut menunjukkan pendekatan yang diuraikan di bagian ini.

Pipeline ETL yang memasukkan data ke sistem file, alih-alih ke data warehouse lama. Kemudian, sistem file memasukkan data ke Cloud Storage, dan dari sana meneruskannya ke BigQuery.

Gambar 8. Mengalihkan pipeline data dengan menggunakan file sebagai sarana perantara.

Sehubungan dengan orkestrasi pipeline ETL, Anda perlu melakukan dua langkah terpisah:

  1. Gunakan kembali orkestrasi pipeline lokal yang ada untuk menulis data yang diubah ke dalam sistem file. Perluas orkestrasi ini untuk menyalin file dari sistem file lokal ke Cloud Storage, atau buat skrip tambahan yang berjalan secara teratur untuk melakukan langkah penyalinan.
  2. Jika data berada di Cloud Storage, gunakan transfer Cloud Storage untuk menjadwalkan pemuatan berulang dari Cloud Storage ke BigQuery. Alternatif untuk transfer Cloud Storage adalah pemicu Cloud Storage dan Cloud Composer.

Pada Gambar 8, perhatikan bahwa orkestrasi di Google Cloud juga dapat menggunakan model pull dengan mengambil file menggunakan protokol seperti SFTP.

Memigrasikan pipeline ELT yang ada ke BigQuery

Pipeline ELT terdiri dari dua bagian: bagian yang memuat data ke data warehouse Anda, dan bagian yang mengubah data dengan menggunakan SQL sehingga dapat digunakan di downstream. Saat Anda memigrasikan pipeline ELT, setiap bagian tersebut memiliki pendekatan migrasinya sendiri.

Untuk bagian yang memuat data ke data warehouse (bagian EL), Anda dapat mengikuti panduan di bagian pipeline data pengalihan, tanpa saran tentang transformasi, yang bukan bagian dari pipeline EL.

Jika sumber data Anda didukung oleh BigQuery Data Transfer Service (DTS), baik secara langsung maupun melalui integrasi pihak ketiga, Anda dapat menggunakan DTS untuk menggantikan pipeline EL Anda.

Memigrasikan pipeline data OSS yang ada ke Dataproc

Saat memigrasikan pipeline data ke Google Cloud, Anda mungkin ingin memigrasikan beberapa pekerjaan lama yang ditulis dengan framework software open source seperti Apache Hadoop, Apache Spark, atau Apache Flink.

Dataproc memungkinkan Anda men-deploy cluster Hadoop dan Spark yang cepat, mudah digunakan, dan terkelola sepenuhnya dengan cara yang sederhana dan hemat biaya. Dataproc terintegrasi dengan konektor BigQuery, library Java yang memungkinkan Hadoop dan Spark menulis data secara langsung ke BigQuery dengan menggunakan versi terpisah dari class InputFormat dan OutputFormat Apache Hadoop.

Dataproc memudahkan pembuatan dan penghapusan cluster sehingga Anda dapat menggunakan banyak cluster sementara, alih-alih menggunakan satu cluster monolitik. Pendekatan ini memiliki beberapa manfaat:

  • Anda dapat menggunakan konfigurasi cluster yang berbeda untuk tugas individu, sehingga menghilangkan beban administratif alat pengelolaan di berbagai tugas.
  • Anda dapat menskalakan cluster agar sesuai dengan tugas individu atau tugas grup.
  • Anda hanya membayar sumber daya ketika tugas Anda menggunakannya.
  • Anda tidak perlu mempertahankan cluster dari waktu ke waktu, karena cluster dikonfigurasi setiap kali Anda menggunakannya.
  • Anda tidak perlu memelihara infrastruktur terpisah untuk pengembangan, pengujian, dan produksi. Anda dapat menggunakan definisi yang sama untuk membuat sebanyak mungkin versi cluster yang diperlukan saat Anda membutuhkannya.

Saat memigrasikan pekerjaan Anda, sebaiknya lakukan pendekatan bertahap. Dengan melakukan migrasi secara bertahap, Anda dapat melakukan hal berikut:

  • Memisahkan tugas individu dalam infrastruktur Hadoop Anda yang sudah ada dari kompleksitas yang melekat di lingkungan yang matang.
  • Memeriksa setiap tugas secara terpisah untuk mengevaluasi kebutuhannya dan menentukan jalur terbaik untuk migrasi.
  • Menangani masalah tak terduga yang muncul tanpa menunda tugas dependen.
  • Membuat bukti konsep untuk setiap proses yang kompleks tanpa memengaruhi lingkungan produksi Anda.
  • Memindahkan tugas Anda ke model sementara yang direkomendasikan dengan cermat dan hati-hati.

Saat memigrasikan tugas Hadoop dan Spark yang ada ke Dataproc, Anda dapat memeriksa apakah dependensi tugas Anda tercakup dalam versi Dataproc yang didukung. Jika perlu menginstal software kustom, Anda dapat mempertimbangkan untuk membuat image Dataproc Anda sendiri, menggunakan beberapa tindakan inisialisasi yang tersedia (misalnya, untuk Apache Flink), menulis tindakan inisialisasi Anda sendiri, atau menentukan persyaratan paket Python kustom.

Untuk memulai, lihat panduan memulai Dataproc dan contoh kode konektor BigQuery. Lihat juga memigrasikan tugas Hadoop dari lokal ke Dataproc.

Menghosting ulang pipeline data pihak ketiga untuk dijalankan di Google Cloud

Skenario umum saat membangun pipeline data secara lokal adalah menggunakan software pihak ketiga untuk mengelola eksekusi pipeline dan alokasi resource komputasi.

Untuk memindahkan pipeline ini ke cloud, Anda memiliki beberapa alternatif, bergantung pada kemampuan software yang Anda gunakan, serta bergantung pada persyaratan pemberian lisensi, dukungan, dan pemeliharaan.

Bagian berikut menampilkan beberapa alternatif tersebut.

Pada tingkat tinggi, Anda memiliki alternatif berikut untuk menjalankan software pihak ketiga di Google Cloud, mulai dari yang paling sederhana hingga yang paling kompleks:

  • Vendor software Anda telah berpartner dengan Google Cloud untuk menawarkan software mereka di Google Cloud Marketplace.
  • Vendor software pihak ketiga Anda dapat berjalan di Kubernetes.
  • Software pihak ketiga Anda berjalan di satu atau beberapa virtual machine (VM).

Jika software pihak ketiga Anda menyediakan solusi Cloud Marketplace, pekerjaan yang terkait adalah sebagai berikut:

Alternatif ini adalah yang paling sederhana karena Anda mengaktivasi pipeline data Anda ke cloud menggunakan platform yang sudah dikenal dan disediakan oleh vendor Anda. Anda mungkin juga dapat menggunakan alat eksklusif dari vendor untuk memfasilitasi migrasi antara lingkungan asli Anda dan lingkungan baru Anda di Google Cloud.

Jika vendor Anda tidak menyediakan solusi Cloud Marketplace, tetapi produk mereka dapat berjalan di Kubernetes, Anda dapat menggunakan Google Kubernetes Engine (GKE) untuk menghosting pipeline Anda. Pekerjaan berikut terlibat:

  • Buat cluster GKE dengan mengikuti rekomendasi dari vendor Anda untuk memastikan bahwa produk pihak ketiga dapat memanfaatkan paralelisasi tugas yang ditawarkan Kubernetes.
  • Menginstal software pihak ketiga di cluster GKE Anda dengan mengikuti rekomendasi vendor.
  • Memilih dan memigrasikan kasus penggunaan Anda dengan mengikuti pendekatan iteratif yang dijelaskan dalam Memigrasikan data warehouse ke BigQuery: Ringkasan.

Alternatif ini memberikan jalan tengah dalam hal kompleksitas. Alternatif tersebut memanfaatkan dukungan berbasis vendor Anda untuk Kubernetes guna menskalakan dan memparalelkan eksekusi pipeline Anda. Namun, hal ini mengharuskan Anda membuat dan mengelola cluster GKE.

Jika vendor Anda tidak mendukung Kubernetes, Anda harus menginstal software mereka di kumpulan VM untuk memungkinkan peningkatan skala dan memparalelkan pekerjaan. Jika software vendor Anda mendukung distribusi pekerjaan ke beberapa VM secara native, gunakan fasilitas yang disediakan tersebut, mungkin kelompokkan instance VM dalam grup instance terkelola (MIG) untuk menurunkan atau menaikkan skala sesuai kebutuhan.

Menangani paralelisasi pekerjaan bukanlah hal yang mudah. Jika vendor Anda tidak menyediakan kemampuan untuk mendistribusikan tugas ke VM yang berbeda, sebaiknya gunakan pola task-farming untuk mendistribusikan pekerjaan ke VM dalam MIG. Diagram berikut mengilustrasikan pendekatan ini.

beberapa input masuk ke Pub/Sub yang membuat topik. Topik dibaca oleh berbagai MIG.

Gambar 9. Grup instance terkelola (MIG) dengan tiga VM.

Dalam diagram ini, setiap VM di MIG mengeksekusi software pipeline pihak ketiga. Anda dapat memicu eksekusi pipeline dengan beberapa cara:

Pada dasarnya, semua metode ini mengirim pesan ke topik Pub/Sub yang telah ditetapkan. Anda membuat agen sederhana untuk diinstal di setiap VM. Agen tersebut memproses satu atau beberapa topik Pub/Sub. Setiap kali pesan masuk ke topik, agen akan menarik pesan dari topik, memulai pipeline di software pihak ketiga Anda, dan memproses penyelesaiannya. Saat pipeline selesai, agen mengambil pesan berikutnya dari topik yang diprosesnya.

Dalam semua skenario, sebaiknya Anda bekerja sama dengan vendor untuk mematuhi persyaratan pemberian lisensi yang sesuai agar pipeline Anda dapat berfungsi di Google Cloud.

Menulis ulang pipeline data untuk menggunakan layanan yang dikelola Google Cloud

Dalam beberapa kasus, Anda mungkin memilih untuk menulis ulang sebagian pipeline data yang ada untuk menggunakan framework dan layanan baru yang terkelola sepenuhnya di Google Cloud. Opsi ini berfungsi dengan baik jika pipeline yang ada awalnya diimplementasikan dengan teknologi yang sudah tidak digunakan lagi, atau jika Anda mengantisipasi bahwa porting dan terus mempertahankan pipeline tersebut tanpa dimodifikasi di cloud akan menjadi sangat tidak praktis dan memerlukan biaya yang besar.

Bagian berikut menghadirkan layanan Google Cloud yang terkelola sepenuhnya yang memungkinkan Anda melakukan transformasi data lanjutan dalam skala besar: Cloud Data Fusion dan Dataflow.

Cloud Data Fusion

Cloud Data Fusion, yang dibuat berdasarkan project CDAP open source, adalah layanan integrasi data terkelola sepenuhnya untuk membuat dan mengelola pipeline data melalui antarmuka grafis.

Anda dapat mengembangkan pipeline data di UI Cloud Data Fusion dengan menghubungkan sumber ke transformasi, sink, dan node lain untuk membentuk DAG. Saat Anda men-deploy pipeline data, perencana Cloud Data Fusion akan mengubah DAG ini menjadi serangkaian komputasi paralel yang akan dijalankan sebagai tugas Apache Spark di Dataproc.

Saat menggunakan Cloud Data Fusion, Anda dapat terhubung ke database sistem sumber menggunakan driver Java Database Connectivity (JDBC) untuk membaca data, mengubahnya, dan memuatnya ke tujuan pilihan Anda (misalnya, BigQuery), tanpa harus menulis kode apa pun. Untuk melakukannya, Anda harus mengupload driver JDBC ke instance Cloud Data Fusion, dan mengonfigurasinya sehingga dapat digunakan dalam pipeline data. Untuk mengetahui detail selengkapnya, lihat panduan tentang menggunakan driver JDBC dengan Cloud Data Fusion.

Cloud Data Fusion mengekspos plugin untuk sumber, transformasi, agregat, sink, pengumpul error, penayang pemberitahuan, tindakan, dan tindakan pasca-operasi sebagai komponen yang dapat disesuaikan. Plugin yang telah dibangun sebelumnya menawarkan akses ke berbagai sumber data. Jika sebuah plugin tidak ada, Anda dapat membangun plugin sendiri menggunakan API plugin Cloud Data Fusion. Untuk informasi selengkapnya, lihat Ringkasan plugin.

Dengan pipeline Cloud Data Fusion, Anda dapat membuat pipeline data streaming dan batch. Dengan menyediakan akses ke log dan metrik, pipeline data juga menawarkan cara bagi administrator untuk mengoperasionalkan alur kerja pemrosesan data mereka tanpa memerlukan alat kustom.

Untuk memulai, lihat Ringkasan konseptual Cloud Data Fusion. Untuk contoh praktis, lihat panduan memulai dan tutorial tentang cara membuat pipeline kampanye penargetan.

Dataflow

Dataflow adalah layanan terkelola sepenuhnya untuk menjalankan tugas Apache Beam dalam skala besar. Apache Beam adalah framework open source yang kaya dengan rangkaian dasar windowing dan analisis sesi, serta ekosistem konektor sumber dan sink, termasuk konektor untuk BigQuery. Apache Beam memungkinkan Anda untuk mengubah dan memperkaya data baik secara streaming (real time) maupun batch (historis) dengan keandalan dan ekspresif yang sama.

Pendekatan serverless Dataflow menghilangkan overhead operasional dengan performa, penskalaan, ketersediaan, keamanan, dan kepatuhan ditangani secara otomatis. Dengan demikian, Anda dapat berfokus pada pemrograman, alih-alih mengelola cluster server.

Anda dapat mengirimkan tugas Dataflow dengan berbagai cara, baik melalui antarmuka command line, Java SDK, atau Python SDK. Selain itu, kami sedang mengembangkan framework portabilitas untuk menghadirkan interoperabilitas penuh antara semua SDK dan runner.

Jika Anda ingin memigrasikan kueri dan pipeline data dari framework lain ke Apache Beam dan Dataflow, baca tentang model pemrograman Apache Beam dan jelajahi dokumentasi Dataflow resmi.

Untuk mengetahui contoh praktis, lihat panduan memulai dan tutorial Dataflow.

Orkestrasi dan penjadwalan

Pada tingkat tinggi, orkestrasi adalah koordinasi otomatis beberapa sistem, sedangkan penjadwalan mengacu pada pemicuan pekerjaan orkestrasi secara otomatis.

  • Memperbesar: Pipeline data sendiri merupakan orkestrasi transformasi data yang dijelaskan oleh DAG, yang merupakan DAG pemrosesan data.
  • Memperkecil: Jika pipeline data bergantung pada output pipeline data lainnya, Anda memerlukan orkestrasi beberapa pipeline. Setiap pipeline membentuk sub-DAG dalam DAG yang lebih besar, yang merupakan DAG orkestrasi.

Penyiapan ini umum dilakukan dalam data warehousing. Gambar 1 di bagian ETL menunjukkan contoh penyiapan. Bagian berikut berfokus pada orkestrasi beberapa pipeline data.

Dependensi

Dependensi dapat bersifat fan-in, dengan beberapa pipeline data digabungkan ke dalam verteks DAG orkestrasi; fan-out, dengan satu pipeline data memicu beberapa pipeline data lainnya; atau sering kali keduanya, seperti yang ditampilkan dalam diagram berikut.

Beberapa pipeline berlabel A, B, dan C fan-in ke pipeline D. Pipeline D fan-out ke pipeline E, F, dan G. Semua ini diatur oleh DAG orkestrasi.

Gambar 10. Dependensi fan-in dan fan-out digunakan secara bersamaan.

Dalam lingkungan yang kurang optimal, beberapa dependensi adalah disebabkan oleh keterbatasan jumlah resource yang tersedia. Misalnya, pipelines data berjalan dan menghasilkan beberapa data umum sebagai produk sampingan. Pipeline data lainnya bergantung pada data umum ini hanya untuk menghindari penghitungan ulang, tetapi tidak terkait dengan pipeline data yang membuat data tersebut. Jika pipeline pertama ini mengalami masalah fungsional atau nonfungsional, kegagalan akan menurun ke pipeline data yang dependen ini. Paling tidak, pipeline tersebut harus menunggu, atau pada kasus terburuk, pipeline tersebut tidak bisa berjalan sama sekali, seperti yang ditunjukkan dalam diagram berikut.

Pipeline A mengalami kegagalan. Pipeline B dan C bergantung pada output dari pipeline A, sehingga kedua pipeline tersebut juga mengalami kegagalan.

Gambar 11. Kegagalan yang menurun pada pipeline data mencegah pipeline dependen berjalan.

Di Google Cloud, banyak resource komputasi dan alat khusus yang tersedia untuk memungkinkan Anda mengoptimalkan eksekusi pipeline dan orkestrasinya. Bagian lainnya membahas resource dan alat-alat ini.

Pekerjaan migrasi yang terlibat

Praktik terbaiknya adalah menyederhanakan kebutuhan orkestrasi Anda. Kompleksitas orkestrasi Anda akan meningkat seiring dengan jumlah dependensi di antara pipeline data Anda. Bermigrasi ke Google Cloud memberikan peluang untuk memeriksa DAG orkestrasi, mengidentifikasi dependensi, dan menentukan cara mengoptimalkan dependensi tersebut.

Sebaiknya optimalkan dependensi Anda secara bertahap, seperti berikut:

  1. Pada iterasi pertama, pindahkan orkestrasi Anda sebagaimana adanya ke Google Cloud.
  2. Pada iterasi selanjutnya, analisis dependensi Anda dan paralelkan dependensi tersebut jika memungkinkan.
  3. Terakhir, atur ulang orkestrasi Anda dengan mengekstrak tugas umum ke DAG-nya masing-masing.

Bagian berikutnya akan menjelaskan metode ini dengan contoh praktis.

Contoh praktis

Misalkan sebuah organisasi memiliki dua pipeline terkait:

  • Pipeline pertama menghitung laba dan kerugian (P&L) untuk keseluruhan organisasi. Ini adalah pipeline kompleks yang melibatkan banyak transformasi. Bagian dari pipeline tersebut terdiri dari penghitungan penjualan bulanan, yang digunakan pada langkah transformasi berikutnya dan pada akhirnya ditulis ke tabel.
  • Pipeline kedua menghitung pertumbuhan penjualan year over year dan bulanan untuk berbagai produk, sehingga departemen pemasaran dapat menyesuaikan upaya kampanye iklannya. Pipeline ini memerlukan data penjualan bulanan yang sebelumnya dihitung oleh pipeline data P&L.

Organisasi ini menganggap pipeline data P&L memiliki prioritas lebih tinggi daripada pipeline pemasaran. Sayangnya, karena P&L adalah pipeline data yang kompleks, P&L memakai sejumlah besar resource, sehingga mencegah pipeline lain berjalan secara serentak. Selain itu, jika pipeline P&L gagal, pipeline pemasaran dan pipeline dependen lainnya tidak memiliki data yang diperlukan agar dapat berjalan, dan harus menunggu percobaan ulang P&L. Diagram berikut menggambarkan situasi ini.

Pipeline P&L membuat artefak 'penjualan bulanan' yang diperlukan untuk pipeline pemasaran. Pipeline P&L dapat mengalami penundaan dan masalah lainnya.

Gambar 12. Pipeline data yang kompleks dapat mencegah pipeline dengan prioritas lebih rendah berjalan.

Organisasi ini bermigrasi ke BigQuery. Organisasi tersebut telah mengidentifikasi dua kasus penggunaan, yaitu P&L dan pertumbuhan penjualan pemasaran, serta menyertakannya dalam backlog migrasi. Saat merencanakan iterasi berikutnya, organisasi tersebut memprioritaskan kasus penggunaan P&L dan menyertakannya dalam backlog iterasi karena pipeline P&L sangat terbatas oleh resource lokal saat ini dan secara rutin menyebabkan penundaan. Beberapa kasus penggunaan dependennya juga disertakan, di antaranya adalah kasus penggunaan pemasaran.

Tim migrasi menjalankan iterasi pertama. Tim tersebut memilih untuk memindahkan kasus penggunaan P&L dan pemasaran ke Google Cloud dengan menggunakan pendekatan pengalihan. Mereka tidak membuat perubahan pada langkah atau orkestrasi pipeline. Perbedaan pentingnya adalah sekarang pipeline P&L dapat menggunakan daya komputasi yang hampir tidak terbatas, sehingga dapat mengeksekusi jauh lebih cepat daripada pipeline lokal. Pipeline tersebut menuliskan data penjualan bulanan ke tabel BigQuery yang digunakan oleh pipeline pertumbuhan pemasaran. Diagram berikut menggambarkan perubahan ini.

Pipeline P&L sama seperti sebelumnya, tetapi tidak mengalami penundaan.

Gambar 13. Mempercepat pipeline data yang kompleks menggunakan pendekatan pengalihan.

Meskipun Google Cloud telah membantu mengatasi masalah P&L nonfungsional, masalah fungsional masih tetap ada. Beberapa tugas tidak terkait yang mendahului penghitungan penjualan bulanan sering kali menyebabkan error yang mencegah penghitungan terjadi, dan mengakibatkan pipeline dependen tidak dapat dimulai.

Pada iterasi kedua, tim berharap dapat meningkatkan performa dengan menyertakan kedua kasus penggunaan ke dalam backlog iterasi. Tim mengidentifikasi langkah-langkah pipeline untuk menghitung penjualan bulanan di pipeline P&L. Langkah-langkah tersebut membentuk sub-DAG, seperti yang ditunjukkan pada diagram berikutnya. Tim migrasi menyalin sub-DAG ke dalam pipeline pemasaran sehingga pipeline tersebut dapat berjalan secara independen dari P&L. Memiliki daya komputasi yang memadai di Google Cloud memungkinkan kedua pipeline berjalan secara serentak.

Pipeline P&L dan pipeline pemasaran kini berjalan sebagai sub-DAG terpisah, sehingga pipeline pemasaran tidak lagi terpengaruh jika ada masalah di pipeline P&L.

Gambar 14. Pipeline berjalan secara serentak menggunakan sub-DAG.

Kelemahannya adalah menduplikasi logika sub-DAG akan menghasilkan overhead pengelolaan kode, karena sekarang tim perlu memastikan kedua salinan logika sub-DAG tetap sinkron.

Pada iterasi ketiga, tim meninjau kembali kasus penggunaan dan mengekstrak sub-DAG penjualan bulanan ke dalam pipeline independen. Jika pipeline penjualan bulanan baru selesai, pipeline tersebut akan memicu atau melakukan fan out ke P&L, pertumbuhan pemasaran, dan pipeline dependen lainnya. Konfigurasi ini akan membuat DAG orkestrasi keseluruhan yang baru, dengan setiap pipeline menjadi salah satu sub-DAG-nya.

Sekarang, pipeline penjualan bulananlah yang lebih dulu memasukkan data ke pipeline P&L dan pipeline pemasaran.

Gambar 15. DAG orkestrasi keseluruhan dengan setiap pipeline di sub-DAG-nya sendiri.

Pada iterasi berikutnya, tim migrasi dapat menyelesaikan masalah fungsional yang tersisa dan memigrasikan pipeline untuk menggunakan layanan yang dikelola Google Cloud berikut, antara lain:

  • Dataflow: Memungkinkan Anda menentukan setiap pipeline data sebagai DAG mandiri menggunakan Model Beam.
  • Cloud Composer: Memungkinkan Anda menentukan orkestrasi yang lebih luas sebagai satu atau beberapa DAG Airflow.

Meskipun Airflow mendukung sub-DAG secara native, fungsionalitas ini mungkin membatasi performanya, sehingga tidak direkomendasikan. Sebagai gantinya, gunakan DAG independen dengan operator TriggerDagRunOperator.

Langkah selanjutnya

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

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