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. Halaman 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 streaming. Contohnya mencakup ETL, validasi kolom, dan pemetaan skema.

  • Agregasi berjendela (GroupByKey): Pipeline yang melakukan operasi stateful dan mengelompokkan data berdasarkan kunci dan periode waktu. Contohnya mencakup penghitungan peristiwa, penghitungan jumlah, dan pengumpulan data untuk sesi pengguna.

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

Metodologi pengujian

Benchmark dilakukan menggunakan resource berikut:

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

    • Frekuensi pesan: Sekitar 1.000.000 pesan per detik
    • Beban Input: 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 status 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 pesan JSON sederhana. Untuk pengujian ini, template Pub/Sub ke BigQuery digunakan tanpa modifikasi.

  • Semantik: Pipeline diuji menggunakan mode tepat satu kali dan minimal satu kali. Pemrosesan minimal satu kali memberikan throughput yang lebih baik. Namun, pemrosesan ini hanya boleh digunakan jika data duplikat dapat diterima atau sink hilir menangani deduplikasi.

Pipeline agregasi berjendela. Pipeline ini mengelompokkan pesan berdasarkan kunci tertentu dalam jendela berukuran tetap dan menulis data yang diagregasi ke BigQuery. Untuk pengujian ini, pipeline Apache Beam kustom berdasarkan template Pub/Sub ke BigQuery digunakan.

  • Logika agregasi: Untuk setiap jendela 1 menit tetap yang tidak tumpang-tindih, pesan dengan kunci yang sama dikumpulkan dan ditulis sebagai satu data yang diagregasi ke BigQuery. Jenis agregasi ini biasanya digunakan dalam pemrosesan log untuk menggabungkan peristiwa terkait, seperti aktivitas pengguna, ke dalam satu data 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 Khusus peta, tepat satu kali Khusus peta, minimal satu kali Agregasi berjendela, 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 otomatis horizontal Ya Ya Ya
Model penagihan Penagihan berbasis resource Penagihan berbasis resource Penagihan berbasis resource
Storage Write API (gRPC) diaktifkan? Ya Ya Ya
Streaming Storage Write API (gRPC) 200 Tidak berlaku 500
Frekuensi pemicuan Storage Write API (gRPC) 5 detik Tidak berlaku 5 detik

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

  • Jumlah streaming tulis. Untuk memastikan paralelisme kunci yang memadai pada tahap tulis, tetapkan jumlah streaming Storage Write API (gRPC) ke nilai yang lebih besar dari jumlah CPU pekerja, sambil mempertahankan tingkat throughput streaming tulis 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 Khusus peta, tepat satu kali Khusus peta, minimal satu kali Agregasi berjendela, 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 Rata-rata: 65%, n=3 Rata-rata: 69%, n=3 Rata-rata: 80%, n=3
Jumlah worker node Rata-rata: 57, n=3 Rata-rata: 48, n=3 Rata-rata: 169, n=3
Unit Komputasi Streaming Engine per jam Rata-rata: 125, n=3 Rata-rata: 46, n=3 Rata-rata: 354, n=3

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

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

Latensi

Tabel berikut menunjukkan hasil benchmark untuk latensi pipeline.

Total latensi end-to-end tahap Khusus peta, tepat satu kali Khusus peta, minimal satu kali Agregasi berjendela, tepat satu kali
P50 Rata-rata: 800 md, n=3 Rata-rata: 160 md, n=3 Rata-rata: 3.400 md, n=3
P95 Rata-rata: 2.000 md, n=3 Rata-rata: 250 md, n=3 Rata-rata: 13.000 md, n=3
P99 Rata-rata: 2.800 md, n=3 Rata-rata: 410 md, n=3 Rata-rata: 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 waktu yang dihabiskan Streaming Engine di setiap tahap pipeline. Metrik ini mencakup semua langkah internal pipeline, seperti:

  • Mengacak dan mengantrekan pesan untuk diproses
  • Waktu pemrosesan sebenarnya; misalnya, mengonversi pesan ke 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 penjendelaan yang ditentukan pengguna dan penundaan upstream di sumber. Latensi sistem memberikan dasar yang lebih objektif untuk efisiensi dan kondisi pemrosesan internal pipeline di bawah beban.

Data diukur selama sekitar satu hari per operasi, dengan periode startup awal dihapus untuk mencerminkan performa status stabil yang stabil. 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 deduplikasi. Mode minimal satu kali berjalan jauh lebih cepat, karena mode ini melewati langkah-langkah tersebut.

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

Benchmark yang ditampilkan di sini mewakili dasar. Latensi sangat sensitif terhadap kompleksitas pipeline. UDF kustom, transformasi tambahan, dan logika penjendelaan yang kompleks dapat meningkatkan latensi. Agregasi sederhana yang sangat mengurangi, seperti jumlah dan penghitungan, cenderung menghasilkan latensi yang lebih rendah daripada operasi yang sangat bergantung pada status, seperti mengumpulkan elemen ke dalam daftar.

Perkirakan biaya

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

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

Penggunaan resource dan skala biaya kira-kira 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 worker node dan konsumsi resource dari hasil benchmark.

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

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

Nilai ini hanya boleh digunakan sebagai perkiraan awal. Throughput dan biaya sebenarnya dapat bervariasi secara signifikan, 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: 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: 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 ini:

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

Langkah berikutnya