Merencanakan pipeline Dataflow Anda

Halaman ini menjelaskan pertimbangan penting untuk merencanakan pipeline data Anda sebelum memulai pengembangan kode. Pipeline data memindahkan data dari satu sistem ke sistem lainnya dan sering kali merupakan komponen penting dari sistem informasi bisnis. Performa dan keandalan pipeline data Anda dapat memengaruhi sistem yang lebih luas ini dan seberapa efektif persyaratan bisnis Anda terpenuhi.

Jika merencanakan pipeline data sebelum mengembangkannya, Anda dapat meningkatkan performa dan keandalannya. Halaman ini menjelaskan berbagai pertimbangan perencanaan untuk pipeline Dataflow, termasuk:

• Ekspektasi performa untuk pipeline Anda, termasuk standar keterukuran
• Integrasi pipeline Anda dengan sumber data, sink, dan sistem terhubung lainnya
• Regionalisasi pipeline, sumber, dan sink
• Keamanan, seperti enkripsi data dan jaringan pribadi

Menentukan dan mengukur SLO

Ukuran performa yang penting adalah seberapa baik pipeline Anda memenuhi persyaratan bisnis. Tujuan tingkat layanan (SLO) memberikan definisi nyata performa yang dapat Anda bandingkan dengan nilai minimum yang dapat diterima. Misalnya, Anda dapat menentukan contoh SLO berikut untuk sistem Anda:

• Keaktualan data: menghasilkan 90% rekomendasi produk dari aktivitas situs pengguna yang terjadi paling lambat 3 menit yang lalu.

• Ketepatan data: dalam satu bulan kalender, kurang dari 0,5% invoice pelanggan berisi error.

• Isolasi data/load balancing: dalam satu hari kerja, proses semua pembayaran berprioritas tinggi dalam waktu 10 menit setelah penginapan, dan selesaikan pembayaran prioritas standar pada hari kerja berikutnya.

Anda dapat menggunakan indikator tingkat layanan (SLI) untuk mengukur kepatuhan SLO. SLI adalah metrik terukur yang menunjukkan seberapa baik sistem Anda memenuhi SLO tertentu. Misalnya, Anda dapat mengukur contoh SLO keaktualan data dengan menggunakan usia aktivitas pengguna yang terakhir diproses sebagai SLI. Jika pipeline Anda menghasilkan rekomendasi dari peristiwa aktivitas pengguna, dan jika SLI Anda melaporkan penundaan selama 4 menit antara waktu peristiwa dan waktu peristiwa diproses, rekomendasi tersebut tidak mempertimbangkan aktivitas situs pengguna lebih awal dari 4 menit. Jika pipeline yang memproses data streaming melebihi latensi sistem 4 menit, Anda tahu bahwa SLO tidak terpenuhi.

Karena komponen sistem di luar pipeline memengaruhi SLO, penting untuk menangkap berbagai SLI yang menjelaskan performa keseluruhan sistem di luar performa pipeline itu sendiri, termasuk metrik yang menjelaskan kondisi sistem Anda secara menyeluruh. Misalnya, pipeline Dataflow Anda mungkin menghitung hasil dengan penundaan yang dapat diterima, tetapi masalah performa mungkin terjadi pada sistem downstream yang memengaruhi SLO yang lebih luas.

Untuk mengetahui informasi selengkapnya tentang SLO penting yang perlu dipertimbangkan, lihat buku Site Reliability Engineering.

Keaktualan data

Keaktualan data mengacu pada kegunaan data dalam kaitannya dengan usianya. SLO keaktualan data berikut disebutkan dalam buku Site Reliability Engineering sebagai format SLO keaktualan data pipeline yang paling umum:

• X% data yang diproses dalam Y [detik, hari, menit]. SLO ini mengacu pada persentase data yang diproses dalam periode waktu tertentu. Ini biasanya digunakan untuk pipeline batch yang memproses sumber data terbatas. Metrik untuk jenis SLO ini adalah ukuran data input dan output pada langkah-langkah pemrosesan utama yang relatif terhadap runtime pipeline yang berlalu. Anda dapat memilih langkah yang membaca set data input dan langkah lain yang memproses setiap item input. Contoh SLO adalah "Untuk game Shave the Yak, 99% aktivitas pengguna yang memengaruhi skor pemain akan dihitung dalam 30 menit setelah pertandingan selesai".

• Data terlama tidak lebih lama dari X [detik, hari, menit]. SLO ini mengacu pada usia data yang dihasilkan oleh pipeline. Ini biasanya digunakan untuk pipeline streaming yang memproses data dari sumber tak terbatas. Untuk jenis SLO ini, gunakan metrik yang menunjukkan berapa lama waktu yang dibutuhkan pipeline Anda untuk memproses data. Dua metrik yang mungkin adalah usia item terlama yang belum diproses, yaitu berapa lama item yang belum diproses berada dalam antrean, atau usia item yang terakhir diproses. Contoh SLO adalah "Rekomendasi produk dihasilkan dari aktivitas pengguna yang tidak lebih lama dari 5 menit".

• Tugas pipeline berhasil diselesaikan dalam X [detik, hari, menit]. SLO ini menetapkan batas waktu untuk penyelesaian yang berhasil dan umumnya digunakan untuk pipeline batch yang memproses data dari sumber data yang dibatasi. SLO ini memerlukan total waktu yang berlalu dalam pipeline dan status penyelesaian tugas, selain sinyal lain yang menunjukkan keberhasilan tugas, seperti persentase elemen yang diproses yang mengakibatkan error. Contoh SLO adalah "Pesanan pelanggan dari hari kerja saat ini diproses pada pukul 09.00 pada hari berikutnya".

Untuk mengetahui informasi tentang penggunaan Cloud Monitoring untuk mengukur keaktualan data, lihat Metrik tugas Dataflow.

Ketepatan data

Ketepatan data mengacu pada data yang tidak memiliki kesalahan. Anda dapat menentukan ketepatan data melalui berbagai cara, termasuk:

• Pengujian unit dan pengujian integrasi, yang dapat Anda otomatisasi menggunakan continuous integration.

• Pengujian pipeline end-to-end, yang dapat Anda jalankan di lingkungan praproduksi setelah pipeline berhasil lulus pengujian unit dan integrasi. Anda dapat mengotomatiskan pengujian pipeline end-to-end menggunakan continuous delivery.

• Pipeline yang berjalan dalam produksi, saat Anda menggunakan monitoring untuk mengamati metrik yang terkait dengan ketepatan data.

Untuk menjalankan pipeline, menentukan target ketepatan data biasanya melibatkan pengukuran ketepatan selama jangka waktu tertentu. Contoh:

• Per tugas, kurang dari X% item input yang berisi error data. Anda dapat menggunakan SLO ini untuk mengukur ketepatan data untuk pipeline batch. Contoh SLO adalah "Untuk setiap tugas batch harian untuk memproses pembacaan meteran listrik, kurang dari 3% pembacaan berisi error entri data."
• Selama periode bergerak X-menit, kurang dari Y% item input berisi error data. Anda dapat menggunakan SLO ini untuk mengukur ketepatan data untuk pipeline streaming. Contoh SLO adalah "Kurang dari 2% pembacaan meter listrik selama satu jam terakhir berisi nilai negatif".

Untuk mengukur SLO ini, gunakan metrik selama periode waktu yang sesuai untuk mengakumulasi jumlah error berdasarkan jenis. Contoh jenis error adalah data yang salah karena format skema yang salah, atau data berada di luar rentang yang valid.

Untuk mengetahui informasi tentang penggunaan Cloud Monitoring untuk mengukur ketepatan data, lihat Metrik tugas Dataflow.

Isolasi data dan load balancing

Isolasi data melibatkan segmentasi data berdasarkan atribut, yang dapat mempermudah load balancing. Misalnya, dalam platform pemrosesan pembayaran online, Anda dapat mengelompokkan data agar setiap pembayaran menjadi prioritas standar atau prioritas tinggi. Selanjutnya, pipeline Anda dapat menggunakan load balancing untuk memastikan bahwa pembayaran dengan prioritas tinggi diproses sebelum pembayaran prioritas standar.

Bayangkan Anda menentukan SLO berikut untuk pemrosesan pembayaran:

• Pembayaran berprioritas tinggi diproses dalam waktu 10 menit.
• Pembayaran prioritas standar diproses pada pukul 09.00 di hari kerja berikutnya.

Jika platform pembayaran mematuhi SLO ini, pelanggan dapat melihat pembayaran prioritas tinggi yang diselesaikan di dasbor pelaporan saat selesai. Sebaliknya, pembayaran standar mungkin tidak muncul di dasbor hingga hari berikutnya.

Dalam contoh skenario ini, Anda memiliki opsi berikut:

• Jalankan satu pipeline untuk memproses pembayaran berprioritas standar dan prioritas tinggi.
• Pisahkan dan lakukan load balancing pada data berdasarkan prioritas di beberapa pipeline.

Bagian berikut menjelaskan setiap opsi secara mendetail.

Gunakan satu pipeline untuk mengirim solusi terhadap SLO campuran

Diagram berikut mengilustrasikan satu pipeline yang digunakan untuk memproses pembayaran prioritas tinggi dan prioritas standar. Pipeline ini menerima notifikasi pembayaran baru dari sumber data streaming, seperti topik Pub/Sub atau topik Apache Kafka. Selanjutnya, API ini akan langsung memproses pembayaran dan menulis peristiwa ke BigQuery menggunakan streaming insert.

Keuntungan dari satu pipeline adalah menyederhanakan persyaratan operasional, karena Anda hanya perlu mengelola satu sumber data dan pipeline. Dataflow menggunakan fitur penyesuaian otomatis untuk membantu menjalankan tugas Anda secepat dan seefisien mungkin.

Kekurangan dari pipeline tunggal adalah pipeline bersama tidak dapat memprioritaskan pembayaran prioritas tinggi daripada pembayaran prioritas standar, dan resource pipeline digunakan bersama di kedua jenis pembayaran. Dalam skenario bisnis yang dijelaskan sebelumnya, pipeline Anda harus mempertahankan kedua SLO yang lebih ketat. Artinya, pipeline harus menggunakan SLO untuk pembayaran prioritas tinggi, terlepas dari prioritas sebenarnya dari pembayaran yang diproses. Kekurangan lainnya adalah jika terjadi backlog pekerjaan, pipeline streaming tidak dapat memprioritaskan pemrosesan backlog berdasarkan urgensi pekerjaan.

Menggunakan beberapa pipeline yang disesuaikan untuk SLO tertentu

Anda dapat menggunakan dua pipeline untuk mengisolasi resource dan mengirimkan SLO tertentu. Diagram berikut mengilustrasikan pendekatan ini.

Pembayaran prioritas tinggi diisolasi ke pipeline streaming untuk pemrosesan yang diprioritaskan. Pembayaran prioritas standar diproses oleh pipeline batch yang berjalan setiap hari dan menggunakan tugas pemuatan BigQuery untuk menulis hasil yang diproses.

Mengisolasi data dalam pipeline yang berbeda memiliki keuntungan. Untuk memberikan pembayaran prioritas tinggi saat SLO yang lebih ketat, Anda dapat mempersingkat waktu pemrosesan dengan menetapkan lebih banyak resource ke pipeline yang dikhususkan untuk pembayaran prioritas tinggi. Konfigurasi resource mencakup menambahkan pekerja Dataflow, menggunakan mesin yang lebih besar, dan mengaktifkan penskalaan otomatis. Mengisolasi item berprioritas tinggi ke antrean pemrosesan terpisah juga dapat mengurangi penundaan pemrosesan jika pembayaran prioritas standar masuk secara tiba-tiba.

Jika Anda menggunakan beberapa pipeline untuk mengisolasi dan melakukan load balancing pada data dari sumber streaming dan batch, model pemrograman Apache Beam memungkinkan pipeline prioritas tinggi (streaming) dan prioritas standar (batch) untuk menggunakan kode yang sama. Satu-satunya pengecualian adalah transformasi baca awal, yang membaca dari sumber terbatas untuk pipeline batch. Untuk mengetahui informasi selengkapnya, lihat Membuat library transformasi yang dapat digunakan kembali.

Membuat rencana untuk sumber data dan sink

Untuk memproses data, pipeline data perlu diintegrasikan dengan sistem lain. Sistem tersebut disebut sebagai sumber dan sink. Pipeline data membaca data dari sumber dan menulis data ke sink. Selain sumber dan sink, pipeline data dapat berinteraksi dengan sistem eksternal untuk pengayaan, pemfilteran, atau memanggil logika bisnis eksternal dalam langkah pemrosesan.

Untuk skalabilitas, Dataflow menjalankan tahap pipeline Anda secara paralel di beberapa pekerja. Faktor-faktor yang berada di luar kode pipeline dan layanan Dataflow juga memengaruhi skalabilitas pipeline Anda. Faktor-faktor tersebut dapat mencakup hal berikut:

• Skalabilitas sistem eksternal: sistem eksternal yang berinteraksi dengan pipeline Anda dapat membatasi performa dan dapat membentuk batas atas skalabilitas. Misalnya, topik Apache Kafka yang dikonfigurasi dengan jumlah partisi yang tidak mencukupi untuk throughput baca yang Anda butuhkan dapat memengaruhi performa pipeline. Untuk membantu memastikan bahwa pipeline dan komponennya memenuhi target performa, lihat dokumentasi praktik terbaik untuk sistem eksternal yang Anda gunakan. Anda juga dapat menyederhanakan perencanaan kapasitas infrastruktur menggunakan layanan Google Cloud yang menyediakan skalabilitas bawaan. Untuk mengetahui informasi selengkapnya, lihat Menggunakan sumber dan sink yang dikelola Google Cloud di halaman ini.

• Pilihan format data: format data tertentu mungkin lebih cepat dibaca daripada yang lain. Misalnya, menggunakan format data yang mendukung pembacaan yang dapat diparalelkan, seperti Avro, biasanya lebih cepat daripada menggunakan file CSV yang telah menyematkan baris baru dalam kolom, dan lebih cepat daripada menggunakan file terkompresi.

• Lokasi data dan topologi jaringan: kedekatan geografis dan karakteristik jaringan sumber data dan sink dalam kaitannya dengan pipeline data dapat memengaruhi performa. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan regional di halaman ini.

Panggilan layanan eksternal

Memanggil layanan eksternal dari pipeline akan menimbulkan overhead per panggilan yang dapat mengurangi performa dan efisiensi pipeline Anda. Jika pipeline data Anda memanggil layanan eksternal, untuk mengurangi overhead, kelompokkan beberapa elemen data menjadi satu permintaan jika memungkinkan. Banyak transformasi I/O Apache Beam native secara otomatis menjalankan tugas ini, termasuk BigQueryIO dan operasi penyisipan streaming. Selain batas kapasitas, beberapa layanan eksternal juga menerapkan kuota yang membatasi jumlah total panggilan selama jangka waktu tertentu, seperti kuota harian, atau membatasi frekuensi panggilan, seperti jumlah permintaan per detik.

Karena Dataflow memparalelkan pekerjaan di beberapa pekerja, traffic yang terlalu banyak dapat membebani layanan eksternal atau menghabiskan kuota yang tersedia. Saat penskalaan otomatis digunakan, Dataflow mungkin mencoba memberi kompensasi dengan menambahkan worker untuk menjalankan langkah lambat seperti panggilan eksternal. Menambahkan pekerja dapat menambah tekanan lebih lanjut pada sistem eksternal. Pastikan sistem eksternal dapat mendukung persyaratan beban yang Anda antisipasi, atau membatasi traffic dari pipeline Anda ke tingkat yang berkelanjutan. Untuk mengetahui informasi selengkapnya, lihat Membatasi ukuran batch dan panggilan serentak ke layanan eksternal.

Menggunakan sumber dan sink yang dikelola Google Cloud

Penggunaan layanan terkelola Google Cloud dengan pipeline Dataflow menghilangkan kerumitan pengelolaan kapasitas dengan menyediakan skalabilitas bawaan, performa konsisten, serta kuota dan batas yang mengakomodasi sebagian besar persyaratan. Anda tetap harus mengetahui kuota dan batas yang berbeda untuk operasi pipeline. Dataflow sendiri menerapkan kuota dan batas. Anda dapat meningkatkan beberapa parameter ini dengan menghubungi dukungan Google Cloud.

Dataflow menggunakan instance VM Compute Engine untuk menjalankan tugas, sehingga Anda memerlukan kuota Compute Engine yang cukup. Kuota Compute Engine yang tidak mencukupi dapat menghambat penskalaan otomatis pipeline atau mencegah tugas dimulai.

Bagian lainnya menjelaskan bagaimana kuota dan batas Google Cloud yang berbeda dapat memengaruhi cara Anda mendesain, mengembangkan, dan memantau pipeline Anda. Pub/Sub dan BigQuery digunakan sebagai contoh sumber dan sink pipeline.

Contoh 1: Pub/Sub

Saat Anda menggunakan Pub/Sub dengan Dataflow, Pub/Sub menyediakan layanan penyerapan peristiwa yang skalabel dan tahan lama untuk mengirim pesan ke dan dari pipeline data streaming Anda. Anda dapat menggunakan Google Cloud Console untuk melihat pemakaian kuota Pub/Sub dan meningkatkan batas kuota. Sebaiknya Anda meminta penambahan kuota jika memiliki satu pipeline yang melebihi kuota dan batas per project.

Kuota dan batas Pub/Sub didesain berdasarkan penggunaan level project. Secara khusus, penayang dan pelanggan di project yang berbeda diberi kuota throughput data independen. Jika beberapa pipeline memublikasikan atau berlangganan satu topik, Anda bisa mendapatkan throughput maksimum yang diizinkan pada topik tersebut dengan men-deploy setiap pipeline ke dalam project-nya sendiri. Dalam konfigurasi ini, setiap pipeline menggunakan akun layanan berbasis project yang berbeda untuk memakai dan memublikasikan pesan.

Dalam diagram berikut, Pipeline 1 dan Pipeline 2 menggunakan kuota throughput pelanggan dan penayang yang sama dengan yang tersedia untuk Project A. Sebaliknya, Pipeline 3 dapat menggunakan seluruh kuota throughput pelanggan dan penayang yang disertakan ke Project B.

Beberapa pipeline dapat membaca dari satu topik Pub/Sub menggunakan langganan terpisah ke topik, yang memungkinkan pipeline Dataflow menarik dan menerima pesan secara terpisah dari pelanggan lain, seperti pipeline lainnya. Fitur ini memudahkan clone pipeline dengan membuat langganan Pub/Sub tambahan. Membuat langganan tambahan berguna untuk membuat pipeline replika guna ketersediaan tinggi (biasanya untuk kasus penggunaan streaming), untuk menjalankan pipeline pengujian tambahan terhadap data yang sama, dan untuk mengaktifkan update pipeline.

Contoh 2: BigQuery

Membaca dan menulis data BigQuery didukung oleh Apache Beam SDK untuk beberapa bahasa, termasuk Java, Python, dan Go. Saat Anda menggunakan Java, class BigQueryIO menyediakan fungsi ini. BigQueryIO mendukung dua metode untuk membaca data: EXPORT (ekspor tabel) dan DIRECT_READ. Berbagai metode pembacaan menggunakan kuota BigQuery yang berbeda.

Ekspor tabel adalah metode baca default. Ini berfungsi seperti yang ditunjukkan dalam diagram berikut:

Diagram menunjukkan alur berikut:

1. BigQueryIO memanggil permintaan ekspor BigQuery untuk mengekspor data tabel. Data tabel yang diekspor akan ditulis ke lokasi Cloud Storage sementara.
2. BigQueryIO membaca data tabel dari lokasi Cloud Storage sementara.

Permintaan ekspor BigQuery dibatasi oleh kuota ekspor. Permintaan ekspor juga harus selesai sebelum pipeline dapat mulai memproses data, yang menambahkan waktu proses tambahan untuk tugas tersebut.

Sebaliknya, pendekatan baca langsung menggunakan BigQuery Storage API untuk membaca data tabel langsung dari BigQuery. BigQuery Storage API memberikan performa pembacaan throughput tinggi untuk data baris tabel menggunakan gRPC. Penggunaan BigQuery Storage API membuat langkah ekspor tidak diperlukan, sehingga menghindari pembatasan kuota ekspor dan berpotensi mengurangi waktu proses tugas.

Diagram berikut menunjukkan alur jika Anda menggunakan BigQuery Storage API. Berbeda dengan flow yang menggunakan permintaan ekspor BigQuery, alur ini lebih sederhana karena hanya memiliki satu langkah pembacaan langsung untuk memindahkan data dari tabel ke pipeline.

Menulis data ke tabel BigQuery juga memiliki implikasi kuota sendiri. Pipeline batch yang menggunakan tugas pemuatan BigQuery menggunakan kuota tugas pemuatan BigQuery yang berbeda-beda yang berlaku di level tabel dan project. Demikian pula, pipeline streaming yang menggunakan penyisipan streaming BigQuery menggunakan kuota penyisipan streaming BigQuery.

Untuk menentukan metode yang paling tepat untuk membaca dan menulis data, pertimbangkan kasus penggunaan Anda. Misalnya, hindari penggunaan tugas pemuatan BigQuery untuk menambahkan data ribuan kali per hari ke dalam tabel. Gunakan pipeline streaming untuk menulis data mendekati real-time ke BigQuery. Pipeline streaming Anda harus menggunakan streaming insert atau Storage Write API untuk tujuan ini.

Pertimbangan regional

Dataflow ditawarkan sebagai layanan terkelola di beberapa region Google Cloud Saat memilih region yang akan digunakan untuk menjalankan tugas Anda, pertimbangkan faktor-faktor berikut:

• Lokasi sumber data dan sink
• Preferensi atau pembatasan terkait lokasi pemrosesan data
• Fitur Dataflow yang hanya ditawarkan di region tertentu
• Region yang digunakan untuk mengelola eksekusi tugas tertentu
• Zona yang digunakan untuk pekerja yang melakukan tugas

Untuk tugas tertentu, setelan region yang Anda gunakan untuk tugas dan pekerja dapat berbeda. Untuk mengetahui informasi selengkapnya, termasuk kapan harus menentukan region dan zona, lihat dokumentasi region Dataflow.

Dengan menentukan region untuk menjalankan tugas Dataflow, Anda dapat merencanakan pertimbangan regional untuk ketersediaan tinggi dan pemulihan dari bencana (disaster recovery). Untuk informasi selengkapnya, lihat Ketersediaan tinggi dan redundansi geografis.

Region

Region Dataflow menyimpan dan menangani metadata yang terkait dengan tugas Anda, seperti informasi tentang grafik Apache Beam itu sendiri, seperti nama transformasi. Alat tersebut juga mengontrol perilaku pekerja seperti penskalaan otomatis. Menentukan region akan membantu Anda memenuhi kebutuhan keamanan dan kepatuhan, lokalitas data, dan penempatan regional dari suatu tugas. Untuk menghindari dampak performa dari panggilan jaringan lintas region, sebaiknya gunakan region yang sama untuk tugas dan untuk pekerja, jika memungkinkan.

Pekerja Dataflow

Tugas Dataflow menggunakan instance VM Compute Engine, yang disebut pekerja Dataflow, untuk menjalankan pipeline Anda. Tugas Dataflow dapat menggunakan zona Compute Engine apa pun untuk pekerja, termasuk region yang tidak memiliki lokasi Dataflow. Dengan menentukan wilayah pekerja untuk pekerjaan, Anda dapat mengontrol penempatan regional pekerja Anda. Untuk menentukan region atau zona pekerja, lakukan hal berikut:

• Jika Anda menggunakan gcloud CLI untuk membuat tugas dari template Dataflow, gunakan flag --worker-region untuk mengganti region pekerja, atau gunakan flag --worker-zone untuk mengganti zona pekerja.
• Jika Anda menggunakan Apache Beam Java SDK untuk membuat tugas, tetapkan region dan zona untuk pekerja menggunakan opsi pipeline. Gunakan workerRegion untuk mengganti region pekerja atau workerZone untuk mengganti zona pekerja.

Untuk meningkatkan latensi dan throughput jaringan, sebaiknya buat pekerja di region yang secara geografis dekat dengan sumber data dan sink Anda. Jika Anda tidak menentukan region atau zona untuk pekerja saat membuat tugas, Dataflow akan otomatis ditetapkan secara default ke zona yang berada di region yang sama dengan tugas tersebut.

Jika Anda tidak menggunakan layanan Dataflow Shuffle atau Streaming Engine, data yang diproses oleh tugas (data yang disimpan dalam objek PCollection apa pun) berada di pekerja tugas, dengan asumsi bahwa tidak ada kode pengguna yang mengirimkan data di luar pekerja. Jika layanan Dataflow Shuffle atau Streaming Engine diaktifkan, set data terdistribusi yang diwakili oleh objek PCollection dapat ditransmisikan antara pekerja dan layanan ini.

Pertimbangan enkripsi data

Sebagai layanan terkelola sepenuhnya, Dataflow secara otomatis mengenkripsi data yang bergerak melalui pipeline data Anda menggunakan kunci enkripsi yang dikelola Google untuk data yang sedang beroperasi dan data dalam penyimpanan. Daripada menggunakan kunci enkripsi yang dikelola Google, Anda dapat memilih untuk mengelola kunci enkripsi Anda sendiri. Untuk itu, Dataflow mendukung kunci enkripsi yang dikelola pelanggan (CMEK) menggunakan Cloud Key Management Service (KMS). Anda juga dapat menggunakan Cloud HSM, layanan modul keamanan hardware (HSM) yang dihosting di cloud, yang memungkinkan Anda menghosting kunci enkripsi dan melakukan operasi kriptografi di cluster HSM tersertifikasi FIPS 140-2 Level 3.

Saat Anda menggunakan CMEK, Dataflow menggunakan kunci Cloud KMS untuk mengenkripsi data, kecuali untuk operasi berbasis kunci data seperti windowing, pengelompokan, dan penggabungan. Jika kunci data berisi data sensitif, seperti informasi identitas pribadi (PII), Anda harus melakukan hashing atau mengubah kunci tersebut sebelum memasuki pipeline Dataflow.

Pertimbangan jaringan pribadi

Persyaratan jaringan dan keamanan Anda mungkin mewajibkan agar workload berbasis VM, seperti tugas Dataflow, hanya menggunakan alamat IP pribadi. Dataflow memungkinkan Anda menentukan bahwa pekerja menggunakan alamat IP pribadi untuk semua komunikasi jaringan. Jika IP publik dinonaktifkan, Anda harus mengaktifkan Akses Google Pribadi di subnetwork sehingga pekerja Dataflow dapat menjangkau Google API dan layanan Google.

Sebaiknya nonaktifkan IP publik untuk pekerja Dataflow, kecuali jika tugas Dataflow Anda memerlukan IP publik untuk mengakses resource jaringan di luar Google Cloud. Menonaktifkan IP publik akan mencegah pekerja Dataflow mengakses resource di luar subnetwork atau mengakses jaringan VPC peer. Demikian pula, akses jaringan ke pekerja VM dari luar jaringan VPC atau subnetwork akan dicegah.

Untuk mengetahui informasi selengkapnya tentang penggunaan opsi pipeline --usePublicIps guna menentukan apakah pekerja hanya boleh memiliki IP pribadi, lihat Opsi pipeline.

Langkah selanjutnya

• Mengembangkan dan menguji pipeline Anda.
• Pelajari cara mendesain alur kerja pipeline yang lengkap.
• Baca lebih lanjut praktik Site Reliability Engineering (SRE) Google untuk pipeline pemrosesan data.