Karakteristik performa pipeline Pub/Sub ke BigQuery

Halaman ini menjelaskan karakteristik performa untuk tugas streaming Dataflow yang membaca dari Pub/Sub dan menulis ke BigQuery. Benchmark ini memberikan hasil pengujian benchmark untuk dua jenis pipeline streaming:

  • Khusus peta (transformasi per pesan): Pipeline yang melakukan transformasi per pesan, tanpa melacak status atau mengelompokkan elemen di seluruh aliran. Contohnya mencakup ETL, validasi kolom, dan pemetaan skema.

  • Agregasi berwindow (GroupByKey): Pipeline yang melakukan operasi stateful dan mengelompokkan data berdasarkan kunci dan jendela waktu. Contohnya mencakup menghitung peristiwa, menghitung jumlah, dan mengumpulkan data untuk sesi pengguna.

Sebagian besar beban kerja untuk integrasi data streaming termasuk dalam dua kategori ini. Jika pipeline Anda mengikuti pola yang serupa, Anda dapat menggunakan tolok ukur ini untuk menilai tugas Dataflow Anda terhadap konfigurasi referensi yang berperforma baik.

Metodologi pengujian

Tolok ukur dilakukan menggunakan resource berikut:

  • Topik Pub/Sub yang telah disediakan sebelumnya dengan beban input yang stabil. Pesan dibuat menggunakan template Streaming Data Generator.

    • Kecepatan pesan: Sekitar 1.000.000 pesan per detik
    • Input Load: 1 GiB/dtk
    • Format pesan: Teks JSON yang dibuat secara acak dengan skema tetap
    • Ukuran pesan: Sekitar 1 KiB per pesan

  • Tabel BigQuery standar.

  • Pipeline streaming Dataflow berdasarkan template Pub/Sub ke BigQuery. Pipeline ini melakukan penguraian dan pemetaan skema minimum yang diperlukan. Tidak ada fungsi yang ditentukan pengguna (UDF) kustom yang digunakan.

Setelah penskalaan horizontal stabil dan pipeline mencapai kondisi stabil, pipeline diizinkan berjalan selama sekitar satu hari, setelah itu hasilnya dikumpulkan dan dianalisis.

Pipeline Dataflow

Dua varian pipeline diuji:

Pipeline khusus peta. Pipeline ini melakukan pemetaan dan konversi sederhana pesan JSON. Untuk pengujian ini, template Pub/Sub ke BigQuery digunakan tanpa modifikasi.

  • Semantik: Pipeline diuji menggunakan mode tepat satu kali dan mode minimal satu kali. Pemrosesan minimal sekali (at-least-once) memberikan throughput yang lebih baik. Namun, opsi ini hanya boleh digunakan jika kumpulan data duplikat dapat diterima atau sink hilir menangani penghapusan duplikat.

Pipeline agregasi berwindow. Pipeline ini mengelompokkan pesan berdasarkan kunci tertentu dalam jendela berukuran tetap dan menuliskan kumpulan data yang digabungkan ke BigQuery. Untuk pengujian ini, pipeline Apache Beam kustom berdasarkan template Pub/Sub to BigQuery digunakan.

  • Logika agregasi: Untuk setiap periode 1 menit tetap yang tidak tumpang-tindih, pesan dengan kunci yang sama dikumpulkan dan ditulis sebagai satu catatan gabungan ke BigQuery. Jenis penggabungan ini biasanya digunakan dalam pemrosesan log untuk menggabungkan peristiwa terkait, seperti aktivitas pengguna, menjadi satu catatan untuk analisis hilir.

  • Paralelisme kunci: Benchmark menggunakan 1.000.000 kunci yang didistribusikan secara seragam.

  • Semantik: Pipeline diuji menggunakan mode tepat satu kali. Agregasi memerlukan semantik tepat satu kali untuk memastikan kebenaran, dan untuk mencegah penghitungan ganda dalam grup dan jendela.

Konfigurasi tugas

Tabel berikut menunjukkan cara konfigurasi tugas Dataflow.

Setelan Hanya peta, tepat satu kali Hanya peta, minimal satu kali Agregasi berwindow, tepat satu kali
Jenis mesin pekerja n1-standard-2 n1-standard-2 n1-standard-2
vCPU mesin pekerja 2 2 2
RAM mesin pekerja 7,5 GiB 7,5 GiB 7,5 GiB
Persistent Disk mesin pekerja Persistent Disk Standar (HDD), 30 GB Persistent Disk Standar (HDD), 30 GB Persistent Disk Standar (HDD), 30 GB
Pekerja awal 70 30 180
Pekerja maksimum 100 100 250
Streaming Engine Ya Ya Ya
Penskalaan horizontal otomatis Ya Ya Ya
Model penagihan Penagihan berbasis resource Penagihan berbasis resource Penagihan berbasis resource
Storage Write API diaktifkan? Ya Ya Ya
Streaming Storage Write API 200 Tidak berlaku 500
Frekuensi pemicuan Storage Write API 5 detik Tidak berlaku 5 detik

BigQuery Storage Write API direkomendasikan untuk pipeline streaming. Saat menggunakan mode tepat satu kali dengan Storage Write API, Anda dapat menyesuaikan setelan berikut:

  • Jumlah aliran penulisan. Untuk memastikan paralelisme kunci yang memadai pada tahap penulisan, tetapkan jumlah streaming Storage Write API ke nilai yang lebih besar daripada jumlah CPU pekerja, sambil mempertahankan tingkat throughput streaming penulisan BigQuery yang wajar.

  • Frekuensi pemicuan. Nilai detik satu digit cocok untuk pipeline throughput tinggi.

Untuk mengetahui informasi selengkapnya, lihat Menulis dari Dataflow ke BigQuery.

Hasil benchmark

Bagian ini menjelaskan hasil pengujian benchmark.

Throughput dan penggunaan resource

Tabel berikut menunjukkan hasil pengujian untuk throughput pipeline dan penggunaan resource.

Hasil Hanya peta, tepat satu kali Hanya peta, minimal satu kali Agregasi berwindow, tepat satu kali
Throughput input per pekerja Rata-rata: 17 MBps, n=3 Rata-rata: 21 MBps, n=3 Rata-rata: 6 MBps, n=3
Penggunaan CPU rata-rata di semua pekerja Rerata: 65%, n=3 Rerata: 69%, n=3 Rerata: 80%, n=3
Jumlah node pekerja Rerata: 57, n=3 Rata-rata: 48, n=3 Rerata: 169, n=3
Unit Komputasi Streaming Engine per jam Rerata: 125, n=3 Rata-rata: 46, n=3 Rata-rata: 354, n=3

Algoritma penskalaan otomatis dapat memengaruhi tingkat penggunaan CPU target. Untuk mencapai target penggunaan CPU yang lebih tinggi atau lebih rendah, Anda dapat menetapkan rentang penskalaan otomatis atau petunjuk penggunaan pekerja. Target pemanfaatan yang lebih tinggi dapat menghasilkan biaya yang lebih rendah, tetapi juga latensi ekor yang lebih buruk, terutama untuk beban yang bervariasi.

Untuk pipeline agregasi jendela, jenis agregasi, ukuran jendela, dan paralelisme kunci dapat berdampak besar pada penggunaan resource.

Latensi

Tabel berikut menunjukkan hasil tolok ukur untuk latensi pipeline.

Total latensi end-to-end tahap Hanya peta, tepat satu kali Hanya peta, minimal satu kali Agregasi berwindow, tepat satu kali
P50 Rerata: 800 md, n=3 Rerata: 160 md, n=3 Rata-rata: 3.400 md, n=3
P95 Rerata: 2.000 md, n=3 Rata-rata: 250 md, n=3 Rerata: 13.000 md, n=3
P99 Rerata: 2.800 md, n=3 Rata-rata: 410 md, n=3 Rerata: 25.000 md, n=3

Pengujian mengukur latensi end-to-end per tahap (metrik job/streaming_engine/stage_end_to_end_latencies) di tiga eksekusi pengujian yang berjalan lama. Metrik ini mengukur berapa lama Streaming Engine menghabiskan waktu di setiap tahap pipeline. Hal ini mencakup semua langkah internal pipeline, seperti:

  • Mengacak dan mengantrekan pesan untuk diproses
  • Waktu pemrosesan sebenarnya; misalnya, mengonversi pesan menjadi objek baris
  • Menulis status persisten, serta waktu yang dihabiskan untuk mengantre guna menulis status persisten

Metrik latensi lainnya adalah keaktualan data. Namun, keaktualan data dipengaruhi oleh faktor-faktor seperti penentuan jendela yang ditentukan pengguna dan penundaan di hulu dalam sumber. Latensi sistem memberikan tolok ukur yang lebih objektif untuk efisiensi dan kesehatan pemrosesan internal pipeline saat berada di bawah beban.

Data diukur selama sekitar satu hari per proses, dengan periode startup awal dihapus untuk mencerminkan performa yang stabil dan berkelanjutan. Hasilnya menunjukkan dua faktor yang menyebabkan latensi tambahan:

  • Mode tepat satu kali. Untuk mencapai semantik tepat satu kali, pengacakan deterministik dan pencarian status persisten diperlukan untuk penghapusan duplikat. Mode minimal sekali berjalan jauh lebih cepat, karena melewati langkah-langkah ini.

  • Agregasi berwindow. Pesan harus diacak, di-buffer, dan ditulis sepenuhnya ke status persisten sebelum penutupan jendela, sehingga menambah latensi end-to-end.

Tolok ukur yang ditampilkan di sini mewakili dasar pengukuran. Latensi sangat sensitif terhadap kompleksitas pipeline. UDF kustom, transformasi tambahan, dan logika windowing yang kompleks dapat meningkatkan latensi. Agregasi yang sederhana dan sangat mengurangi, seperti jumlah dan hitungan, cenderung menghasilkan latensi yang lebih rendah daripada operasi yang berat, seperti mengumpulkan elemen ke dalam daftar.

Perkirakan biaya

Anda dapat memperkirakan biaya dasar pipeline Anda sendiri yang sebanding dengan Penagihan berbasis resource menggunakan kalkulator harga Google Cloud Platform, sebagai berikut:

  1. Buka kalkulator harga.
  2. Klik Tambahkan ke estimasi.
  3. Pilih Dataflow.
  4. Untuk Jenis layanan, pilih "Dataflow Klasik".
  5. Pilih Setelan lanjutan untuk menampilkan semua opsi.
  6. Pilih lokasi tempat tugas berjalan.
  7. Untuk Job type, pilih "Streaming".
  8. Pilih Aktifkan Streaming Engine.
  9. Masukkan informasi untuk jam eksekusi tugas, worker node, mesin pekerja, dan penyimpanan Persistent Disk.
  10. Masukkan perkiraan jumlah Unit Komputasi Streaming Engine.

Penggunaan resource dan biaya meningkat secara linear dengan throughput input, meskipun untuk tugas kecil dengan hanya beberapa pekerja, total biaya didominasi oleh biaya tetap. Sebagai titik awal, Anda dapat mengekstrapolasi jumlah node pekerja dan konsumsi resource dari hasil tolok ukur.

Misalnya, Anda menjalankan pipeline khusus peta dalam mode tepat satu kali, dengan kecepatan data input 100 MiB/s. Berdasarkan hasil tolok ukur untuk pipeline 1 GiB/s, Anda dapat memperkirakan persyaratan resource sebagai berikut:

  • Faktor Penskalaan: (100 MiB/dtk) / (1 GiB/dtk) = 0,1
  • Node pekerja yang diproyeksikan: 57 pekerja × 0,1 = 5,7 pekerja
  • Perkiraan jumlah Unit Komputasi Streaming Engine per jam: 125 × 0,1 = 12,5 unit per jam

Nilai ini hanya boleh digunakan sebagai perkiraan awal. Throughput dan biaya sebenarnya dapat sangat bervariasi, berdasarkan faktor-faktor seperti jenis mesin, distribusi ukuran pesan, kode pengguna, jenis agregasi, paralelisme kunci, dan ukuran jendela. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk pengoptimalan biaya Dataflow.

Menjalankan pipeline pengujian

Bagian ini menunjukkan perintah gcloud dataflow flex-template run yang digunakan untuk menjalankan pipeline khusus peta.

Mode tepat satu kali 

gcloud dataflow flex-template run JOB_ID \
  --template-file-gcs-location gs://dataflow-templates-us-central1/latest/flex/PubSub_to_BigQuery_Flex \
  --enable-streaming-engine \
  --num-workers 70 \
  --max-workers 100 \
  --parameters \
inputSubscription=projects/PROJECT_IDsubscriptions/SUBSCRIPTION_NAME,\
outputTableSpec=PROJECT_ID:DATASET.TABLE_NAME,\
useStorageWriteApi=true,\
numStorageWriteApiStreams=200 \
storageWriteApiTriggeringFrequencySec=5

Mode minimal satu kali 

gcloud dataflow flex-template run JOB_ID \
  --template-file-gcs-location gs://dataflow-templates-us-central1/latest/flex/PubSub_to_BigQuery_Flex \
  --enable-streaming-engine \
  --num-workers 30 \
  --max-workers 100 \
  --parameters \
inputSubscription=projects/PROJECT_ID/subscriptions/SUBSCRIPTION_NAME,\
outputTableSpec=PROJECT_ID:DATASET.TABLE_NAME,\
useStorageWriteApi=true \
  --additional-experiments streaming_mode_at_least_once

Ganti kode berikut:

  • JOB_ID: ID tugas Dataflow
  • PROJECT_ID: the project ID
  • SUBSCRIPTION_NAME: nama langganan Pub/Sub
  • DATASET: nama set data BigQuery
  • TABLE_NAME: nama tabel BigQuery

Membuat data pengujian

Untuk membuat data pengujian, gunakan perintah berikut untuk menjalankan template Streaming Data Generator:

gcloud dataflow flex-template run JOB_ID \
  --template-file-gcs-location gs://dataflow-templates-us-central1/latest/flex/Streaming_Data_Generator \
  --num-workers 70 \
  --max-workers 100 \
  --parameters \
topic=projects/PROJECT_ID/topics/TOPIC_NAME,\
qps=1000000,\
maxNumWorkers=100,\
schemaLocation=SCHEMA_LOCATION

Ganti kode berikut:

  • JOB_ID: ID tugas Dataflow
  • PROJECT_ID: the project ID
  • TOPIC_NAME: nama topik Pub/Sub
  • SCHEMA_LOCATION: jalur ke file skema di Cloud Storage

Template Streaming Data Generator menggunakan file JSON Data Generator untuk menentukan skema pesan. Pengujian benchmark menggunakan skema pesan yang mirip dengan berikut:

{
  "logStreamId": "{{integer(1000001,2000000)}}",
  "message": "{{alphaNumeric(962)}}"
}

Langkah berikutnya