E-MapReduce:Skenario

Skenario data lake

Kluster EMR DataLake dirancang untuk tim yang perlu memusatkan penyimpanan, tata kelola, dan analisis data lake perusahaan yang dibangun di atas OSS-HDFS. Tiga kemampuan inti bekerja sama untuk mencakup seluruh siklus hidup, mulai dari ingesti data mentah hingga aplikasi downstream.

Diagram berikut menunjukkan alur data end-to-end untuk skenario EMR DataLake.

Langkah 1: Ingesti data dari berbagai sumber

Data dari berbagai sistem sumber masuk ke OSS-HDFS dalam format aslinya.

• Database relasional (MySQL, Oracle): Gunakan Sqoop atau DataX untuk mengekstraksi data lengkap atau inkremental sesuai jadwal reguler dan menuliskannya ke OSS-HDFS berdasarkan skema tabel bisnis.

• Database non-relasional (MongoDB, Redis): Gunakan skrip kustom atau konektor Spark untuk mengekspor data JSON atau biner ke OSS-HDFS.

• Data log: Gunakan Logstash atau Flume untuk mengumpulkan log inkremental — log perilaku pengguna, log sistem — dan menuliskannya ke OSS-HDFS dengan latensi tingkat menit.

• Data file: Gunakan JindoSDK dengan API HDFS untuk mengunggah file CSV, Parquet, dan lainnya ke OSS-HDFS secara massal, atau unggah file langsung dari Konsol OSS.

Langkah 2: Proses dan analisis data

Data mentah di OSS-HDFS disempurnakan menjadi metrik bisnis yang dapat dikueri.

• Pemrosesan batch: Jalankan pekerjaan Spark dan Hive untuk membersihkan, mengasosiasikan, dan mengagregasi log mentah serta data bisnis. Output khas mencakup pengguna aktif harian, tingkat retensi pengguna 30 hari, dan jumlah pesanan baru berdasarkan Stock Keeping Unit (SKU).

• Kueri interaktif: Gunakan Trino atau Presto dengan SQL standar untuk mengkueri data besar dengan waktu respons di bawah satu detik, mendukung analisis ad hoc bagi tim operasional.

Langkah 3: Terapkan data ke sistem downstream

Data yang telah diproses mendorong berbagai aplikasi bisnis.

• Ilmu data: Sediakan data yang telah diproses melalui layanan API ke sistem downstream seperti mesin pengendalian risiko dan sistem rekomendasi.

• Intelijen bisnis: Hubungkan melalui API Java Database Connectivity (JDBC) ke alat seperti Quick BI untuk membuat laporan interaktif.

• Analisis prediktif: Dorong hasil pemrosesan dan data fitur ke platform pembelajaran mesin untuk melatih model — misalnya, model prediksi penjualan SKU — dan simpan hasilnya kembali di data lake.

• Visualisasi data: Hubungkan melalui API JDBC ke alat visualisasi seperti DataV untuk menampilkan data kompleks pada dasbor.

Skenario analitik data

Kluster EMR Online Analytical Processing (OLAP) dirancang untuk tim yang menjalankan analitik data besar berkinerja tinggi. Kluster ini terintegrasi dengan mesin OLAP — StarRocks, Doris, dan ClickHouse — yang memiliki tiga karakteristik kinerja: kompresi data efisien, penyimpanan berorientasi kolom, dan eksekusi kueri paralel. Karakteristik ini menjadikan kluster OLAP sangat cocok untuk profil pengguna, pemilihan penerima, dan beban kerja intelijen bisnis.

Diagram berikut menggunakan mesin analitik StarRocks untuk menunjukkan alur data end-to-end untuk skenario EMR OLAP.

Langkah 1: Kumpulkan data

Data masuk ke StarRocks dari sumber real-time dan offline.

• Real-time: Flume menangkap data log; Message Queue for Apache Kafka menyangga aliran data dengan throughput tinggi dan latensi rendah untuk menstabilkan ingesti real-time.

• Offline: Sqoop atau DataX mengekstraksi data dari database relasional seperti MySQL dan Oracle sesuai jadwal reguler dan memuatnya ke StarRocks.

Langkah 2: Susun data dalam StarRocks

StarRocks mengorganisasi data ke dalam empat lapisan hierarkis — pola yang mirip dengan arsitektur medallion yang digunakan dalam data lakehouse modern — sehingga setiap lapisan membangun di atas lapisan sebelumnya dan dapat digunakan ulang secara independen.

• Lapisan DIM (lapisan dimensi): Menyimpan data dimensi seperti atribut pengguna dan kategori komoditas, serta mendukung analisis multi-granularitas.

• Lapisan ODS (lapisan gudang data operasional): Menyimpan data mentah dalam kondisi aslinya, memungkinkan analisis backtracking.

• Lapisan DWD (lapisan data rinci): Menerapkan pembersihan data, standarisasi format, dan asosiasi dasar untuk menghasilkan set data rinci.

• Lapisan DWS (lapisan ringkasan gudang data): Melakukan pra-agregasi metrik berdasarkan subjek bisnis — perilaku pengguna, konversi pesanan — untuk mengurangi latensi kueri.

Langkah 3: Terapkan data

Data berlapis mendorong tiga aplikasi bisnis utama.

• Profil pengguna: Gabungkan tag atribut lapisan DIM dengan data perilaku lapisan DWS untuk membangun profil pengguna guna pemasaran presisi.

• Pemilihan penerima: Saring pengguna berdasarkan beberapa kondisi, seperti pengguna yang sangat aktif tetapi tidak melakukan pembelian dalam 30 hari terakhir.

• Intelijen bisnis: Hubungkan melalui API JDBC ke Quick BI untuk menghasilkan laporan harian, laporan mingguan, dan dasbor real-time.

Skenario streaming data real-time

Kluster EMR Dataflow dirancang untuk beban kerja yang memerlukan ingesti dan analisis data berkelanjutan dengan latensi rendah — seperti pengendalian risiko real-time dan dasbor real-time. Kluster ini mengintegrasikan tiga komponen inti yang mencakup penyimpanan, pemrosesan aliran, dan manajemen data inkremental.

• OSS-HDFS: Lapisan penyimpanan yang dapat diskalakan dan kompatibel dengan protokol HDFS. Mendukung penyimpanan persisten data real-time dalam skala petabyte, penulisan tingkat milidetik, serta tiering data dingin dan panas berbiaya rendah.

• Flink: Melakukan ETL pada aliran data (penguraian log, asosiasi dimensi), agregasi jendela (pengukuran Gross Merchandise Volume (GMV) tingkat menit), dan pemrosesan peristiwa kompleks (evaluasi aturan pengendalian risiko).

• Paimon: Mengelola data inkremental real-time dan snapshot historis dalam data lake streaming. Mendukung sinkronisasi change data capture (CDC), transaksi ACID (atomicity, consistency, isolation, and durability), dan kueri time-travel.

Diagram berikut menunjukkan bagaimana Flink, Paimon, dan OSS-HDFS bekerja sama membangun data lakehouse streaming yang mendukung dasbor real-time.

Langkah 1: Ingesti data secara real-time dari berbagai sumber

Gunakan konektor Flink untuk mengumpulkan perubahan database, log, dan data pelacakan event dari berbagai sistem upstream secara simultan.

Langkah 2: Bangun data lakehouse streaming

Flink dan Paimon memproses dan menyimpan data dalam lakehouse terstruktur yang dapat dikueri.

• Flink: Sebagai mesin komputasi data batch dan stream terpadu, Flink mengonsumsi aliran data secara real-time dan melakukan pembersihan, transformasi (penguraian log, standarisasi titik pelacakan event), serta asosiasi dimensi.

• Paimon: Menyimpan hasil pemrosesan dalam data lake streaming dengan dua mekanisme utama:

  • Changelog: Mencatat penyisipan, pembaruan, dan penghapusan data untuk menjamin integritas transaksi ACID dan sinkronisasi inkremental real-time.

  • Pemodelan hierarkis: Menggabungkan Paimon dengan lapisan ODS, DWD, dan DWS untuk membangun arsitektur data berlapis guna akumulasi dan penggunaan ulang data inkremental.

• OSS-HDFS: Menyimpan log mentah, snapshot inkremental Paimon, dan data arsip historis secara persisten.

Langkah 3: Sampaikan insight bisnis

Data lakehouse yang telah diproses memberi masukan ke alat pelaporan dan pengambilan keputusan real-time.

• Gunakan StarRocks untuk menghasilkan laporan bisnis real-time seperti pemantauan GMV dan analisis retensi pengguna.

• Hubungkan ke Quick BI untuk membangun dasbor yang memungkinkan pengambilan keputusan T+0.

Skenario penyajian data

Kluster EMR DataServing dirancang untuk beban kerja yang memerlukan penyimpanan dan pengkuerian set data masif dengan latensi tingkat milidetik. Kluster ini mengintegrasikan OSS-HDFS, HBase, dan Phoenix untuk mencakup seluruh jalur mulai dari penyimpanan data mentah hingga eksekusi kueri kompleks — mendukung kasus penggunaan seperti analisis perilaku pengguna dan pemasaran presisi.

• HBase: Database terdistribusi berorientasi kolom yang menyediakan pembacaan dan penulisan real-time throughput tinggi untuk set data berskala besar, termasuk kueri titik tingkat milidetik untuk status pesanan dan catatan perilaku pengguna. HBase menyimpan HFile secara persisten ke OSS-HDFS, melakukan penguraian keterkaitan antara penyimpanan dan komputasi, serta memungkinkan pembuatan ulang kluster yang cepat.

• Phoenix: Mesin kueri SQL untuk HBase. Phoenix memetakan data NoSQL ke tabel relasional standar dan mendukung analisis SQL kompleks — asosiasi multi-tabel dan komputasi agregat — dengan waktu respons di bawah satu detik bahkan untuk ratusan miliar catatan. Indeks sekunder dan query pushdown mempercepat pemilihan berbasis tag dan pengelompokan pengguna, sehingga mengurangi upaya pengembangan bagi tim bisnis.

Diagram berikut menunjukkan bagaimana kluster EMR DataServing menggunakan arsitektur penyimpanan HBase + OSS-HDFS dan mesin kueri Phoenix untuk mendukung analisis perilaku pengguna.

Langkah 1: Proses data

Dua jalur pemrosesan — stream dan batch — memasukkan data ke kluster HBase.

• Pemrosesan stream (Flink): Mengonsumsi aliran data log secara real-time, menerapkan pembersihan data (penghilangan derau, standarisasi format), agregasi jendela (jumlah unique visitor (UV) real-time), dan peringatan event (deteksi trafik abnormal), lalu menuliskan hasilnya ke HBase melalui API HBase.

• Pemrosesan batch (Spark): Menjalankan pekerjaan batch periodik pada data database relasional, melakukan operasi ETL seperti perhitungan tag pengguna dan deduplikasi data, serta menuliskan output ke HBase.

Langkah 2: Simpan data dalam skala besar

Dua lapisan penyimpanan menangani pola akses yang berbeda.

• OSS-HDFS: Menyimpan log mentah dan HFile HBase secara persisten. JindoCache mengurangi latensi baca dan tulis OSS-HDFS.

• Kluster HBase: Menangani penulisan real-time (catatan perilaku pengguna) dan kueri titik frekuensi tinggi (pencarian status pesanan).

Langkah 3: Kueri perilaku pengguna

Tim bisnis menjalankan kueri SQL Phoenix terhadap HBase untuk mengekstraksi insight perilaku guna pemasaran presisi — misalnya, menemukan pengguna yang membeli kategori produk dan mengklik iklan terkait dalam tujuh hari terakhir.