Pemrosesan aliran dengan Azure Stream Analytics

Cosmos DB
Event Hubs
Monitor
Stream Analytics

Arsitektur referensi ini menunjukkan alur pemrosesan aliran end-to-end. Alur menyerap data dari dua sumber, menghubungkan catatan di dua aliran, dan menghitung rata-rata bergulir selama periode waktu tertentu. Hasilnya disimpan untuk analisis lebih lanjut.

Logo GitHub Implementasi referensi untuk arsitektur ini tersedia di GitHub.

Arsitektur

Diagram memperlihatkan arsitektur referensi untuk membuat alur pemrosesan aliran dengan Azure Stream Analytics.

Unduh file Visio arsitektur ini.

Alur kerja

Arsitektur terdiri dari komponen-komponen berikut:

Sumber data. Dalam arsitektur ini, ada dua sumber data yang menghasilkan aliran secara real time. Aliran pertama berisi informasi perjalanan, dan aliran kedua berisi informasi tarif. Arsitektur referensi mencakup generator data simulasi, yang dibaca dari sekumpulan file statik dan mendorong data ke Azure Event Hubs. Dalam aplikasi nyata, sumber data akan menjadi perangkat yang dipasang di dalam taksi.

Azure Event Hubs. Azure Event Hubs merupakan layanan penyerapan kejadian. Arsitektur ini menggunakan dua instans event hub, satu untuk setiap sumber data. Setiap sumber data mengirimkan aliran data ke hub peristiwa terkait.

Azure Stream Analytics. Azure Stream Analytics adalah mesin pemrosesan peristiwa. Pekerjaan Azure Stream Analytics membaca aliran data dari dua hub peristiwa dan melakukan pemrosesan aliran.

Azure Cosmos DB. Output dari pekerjaan Azure Stream Analytics adalah serangkaian rekaman, yang ditulis sebagai dokumen JSON ke database dokumen Azure Cosmos DB.

Microsoft Power BI. Power BI adalah seperangkat alat analisis bisnis untuk menganalisis data sebagai wawasan bisnis. Dalam arsitektur ini, ia memuat data dari Azure Cosmos DB. Hal ini memungkinkan pengguna menganalisis kumpulan data riwayat lengkap yang telah dikumpulkan. Anda juga dapat mengalirkan hasil langsung dari Azure Stream Analytics ke Power BI untuk tampilan data secara real-time. Untuk informasi selengkapnya, lihat Streaming real-time di Power BI.

Azure Monitor. Azure Monitor mengumpulkan metrik performa tentang layanan Azure yang disebarkan dalam solusi. Dengan memvisualisasikannya di dasbor, Anda bisa mendapatkan wawasan tentang kesehatan solusinya.

Detail skenario

Skenario: Sebuah perusahaan taksi mengumpulkan data tentang setiap perjalanan taksi. Untuk skenario ini, kita berasumsi ada dua perangkat yang terpisah yang mengirim data. Taksi memiliki meteran yang mengirimkan informasi tentang setiap perjalanan — yakni durasi, jarak, serta lokasi penjemputan dan pengantaran. Perangkat terpisah menerima pembayaran dari pelanggan dan mengirimkan data tentang tarif. Perusahaan taksi ingin menghitung tip rata-rata per mil yang ditempuh, secara real time, untuk melihat tren.

Potensi penggunaan kasus

Solusi ini dioptimalkan untuk skenario ritel.

Penyerapan data

Untuk simulasi sumber data, arsitektur referensi ini menggunakan himpunan data New York City Taxi Data[1]. Himpunan data ini berisi data tentang perjalanan taksi di New York City selama periode empat tahun (2010–2013). Data ini berisi dua jenis catatan: Data perjalanan dan tarif. Data perjalanan mencakup durasi perjalanan, jarak perjalanan, dan lokasi penjemputan dan pengantaran. Data tarif mencakup tarif, pajak, dan jumlah tip. Bidang umum di kedua jenis catatan ini termasuk nomor medali, lisensi hack, dan ID vendor. Bersama-sama, ketiga bidang ini secara unik mengidentifikasi taksi serta pengemudi. Data disimpan dalam format CSV.

[1] Donovan, Brian; Work, Dan (2016): New York City Taxi Trip Data (2010-2013). Universitas Illinois di Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

Generator data adalah aplikasi .NET Core yang membaca catatan dan mengirimkannya ke Azure Event Hubs. Generator tersebut mengirimkan data perjalanan dalam format JSON dan data tarif dalam format CSV.

Azure Event Hubs menggunakan partisi untuk mensegmentasi data. Partisi memungkinkan konsumen untuk membaca setiap partisi secara paralel. Saat Anda mengirim data ke Azure Event Hubs, Anda dapat menentukan kunci partisi secara eksplisit. Jika tidak, catatan ditetapkan ke partisi secara round-robin.

Dalam skenario khusus ini, data perjalanan dan data tarif harus berakhir dengan ID partisi yang sama untuk taksi tertentu. Hal ini memungkinkan Azure Stream Analytics menerapkan tingkat paralelisme ketika menghubungkan dua aliran. Catatan dalam partisi n data perjalanan akan cocok dengan catatan dalam partisi n data tarif.

Diagram pemrosesan aliran dengan Azure Stream Analytics dan Azure Event Hubs

Di generator data, model data umum untuk kedua jenis catatan memiliki properti PartitionKey yang merupakan perangkaian dari Medallion, HackLicense, dan VendorId.

public abstract class TaxiData
{
    public TaxiData()
    {
    }

    [JsonProperty]
    public long Medallion { get; set; }

    [JsonProperty]
    public long HackLicense { get; set; }

    [JsonProperty]
    public string VendorId { get; set; }

    [JsonProperty]
    public DateTimeOffset PickupTime { get; set; }

    [JsonIgnore]
    public string PartitionKey
    {
        get => $"{Medallion}_{HackLicense}_{VendorId}";
    }

Properti ini digunakan untuk menyediakan kunci partisi eksplisit saat mengirim ke Azure Event Hubs:

using (var client = pool.GetObject())
{
    return client.Value.SendAsync(new EventData(Encoding.UTF8.GetBytes(
        t.GetData(dataFormat))), t.PartitionKey);
}

Pemrosesan streaming

Pekerjaan pemrosesan aliran ditentukan menggunakan kueri SQL dengan beberapa langkah berbeda. Dua langkah pertama cukup memilih rekaman dari dua aliran input.

WITH
Step1 AS (
    SELECT PartitionId,
           TRY_CAST(Medallion AS nvarchar(max)) AS Medallion,
           TRY_CAST(HackLicense AS nvarchar(max)) AS HackLicense,
           VendorId,
           TRY_CAST(PickupTime AS datetime) AS PickupTime,
           TripDistanceInMiles
    FROM [TaxiRide] PARTITION BY PartitionId
),
Step2 AS (
    SELECT PartitionId,
           medallion AS Medallion,
           hack_license AS HackLicense,
           vendor_id AS VendorId,
           TRY_CAST(pickup_datetime AS datetime) AS PickupTime,
           tip_amount AS TipAmount
    FROM [TaxiFare] PARTITION BY PartitionId
),

Langkah selanjutnya menggabungkan dua aliran input untuk memilih pencocokan rekaman dari setiap aliran.

Step3 AS (
  SELECT tr.TripDistanceInMiles,
         tf.TipAmount
    FROM [Step1] tr
    PARTITION BY PartitionId
    JOIN [Step2] tf PARTITION BY PartitionId
      ON tr.PartitionId = tf.PartitionId
     AND tr.PickupTime = tf.PickupTime
     AND DATEDIFF(minute, tr, tf) BETWEEN 0 AND 15
)

Kueri ini menggabungkan rekaman pada sekumpulan bidang yang secara unik mengidentifikasi rekaman yang cocok (PartitionId dan PickupTime).

Catatan

Kami menginginkan aliran TaxiRide dan TaxiFaredigabungkan dengan kombinasi unik Medallion, HackLicense, VendorId, dan PickupTime. Dalam hal ini, PartitionId mencakup bidang Medallion, HackLicense, dan VendorId, tetapi ini tidak boleh dianggap sebagai kasus pada umumnya.

Di Azure Stream Analytics, gabungan bersifat sementara, yang berarti rekaman digabungkan dalam periode waktu tertentu. Jika tidak, pekerjaan mungkin perlu menunggu tanpa batas waktu untuk pencocokan. Fungsi DATEDIFF menentukan sejauh mana dua rekaman yang cocok dapat dipisahkan tepat waktu untuk dicocokkan.

Langkah terakhir dalam pekerjaan menghitung tip rata-rata per mil, dikelompokkan berdasarkan periode lompatan 5 menit.

SELECT System.Timestamp AS WindowTime,
       SUM(tr.TipAmount) / SUM(tr.TripDistanceInMiles) AS AverageTipPerMile
  INTO [TaxiDrain]
  FROM [Step3] tr
  GROUP BY HoppingWindow(Duration(minute, 5), Hop(minute, 1))

Azure Stream Analytics menyediakan beberapa fungsi periode. Periode lompatan bergerak maju tepat waktu dengan periode tertentu, dalam hal ini 1 menit per lompatan. Hasilnya adalah menghitung rata-rata bergerak selama 5 menit terakhir.

Dalam arsitektur yang ditampilkan di sini, hanya hasil pekerjaan Azure Stream Analytics yang disimpan ke Azure Cosmos DB. Untuk skenario data besar, pertimbangkan juga untuk menggunakan Event Hubs Capture untuk menyimpan data peristiwa mentah ke penyimpanan Azure Blob. Menyimpan data mentah akan memungkinkan Anda menjalankan kueri batch atas data historis Anda di lain waktu, untuk mendapatkan wawasan baru dari data.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian prinsip panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Skalabilitas

Event Hubs

Kapasitas throughput Azure Event Hubs diukur dalam unit throughput. Anda dapat menskalakan hub peristiwa secara otomatis dengan mengaktifkan perluas otomatis, yang secara otomatis memperluas skala unit throughput berdasarkan lalu lintas, hingga jumlah maksimum yang dikonfigurasi.

Stream Analytics

Untuk Azure Stream Analytics, sumber daya komputasi yang dialokasikan untuk pekerjaan diukur dalam Unit Streaming. Pekerjaan Azure Stream Analytics lebih tepat diskalakan jika pekerjaan disejajarkan. Dengan begitu, Azure Stream Analytics dapat mendistribusikan pekerjaan di beberapa simpul komputasi.

Untuk input Azure Event Hubs, gunakan kata kunci PARTITION BY untuk mempartisi pekerjaan Azure Stream Analytics. Data akan dibagi menjadi subset berdasarkan partisi Azure Event Hubs.

Fungsi jendela dan gabungan temporal memerlukan SU tambahan. Jika memungkinkan, gunakan PARTITION BY agar setiap partisi diproses secara terpisah. Untuk mengetahui informasi selengkapnya, lihat Memahami dan menyesuaikan Unit Streaming.

Jika tidak mungkin menyejajarkan seluruh pekerjaan Azure Stream Analytics, coba untuk membagi pekerjaan menjadi beberapa langkah, dimulai dengan satu langkah paralel atau lebih. Dengan begitu, langkah pertama bisa dijalankan secara paralel. Misalnya, dalam arsitektur referensi ini:

  • Langkah 1 dan 2 adalah pernyataan SELECT sederhana yang memilih rekaman dalam satu partisi.
  • Langkah 3 melakukan gabungan yang dipartisi di dua aliran input. Langkah ini mengambil manfaat dari fakta bahwa catatan yang cocok berbagi kunci partisi yang sama, sehingga dijamin memiliki ID partisi yang sama di setiap aliran input.
  • Langkah 4 digabungkan di semua partisi. Langkah ini tidak dapat disejajarkan.

Gunakan diagram pekerjaan Azure Stream Analytics untuk melihat banyaknya partisi yang ditetapkan untuk setiap langkah dalam pekerjaan. Diagram berikut menunjukkan diagram pekerjaan untuk arsitektur referensi ini:

Diagram memperlihatkan pekerjaan Azure Stream Analytics.

Azure Cosmos DB

Kapasitas throughput untuk Azure Cosmos DB diukur dalam Unit Permintaan (RU). Untuk menskalakan kontainer Azure Cosmos DB melewati 10.000 RU, Anda harus menentukan kunci partisi saat membuat kontainer, dan menyertakan kunci partisi di setiap dokumen.

Dalam arsitektur referensi ini, dokumen baru dibuat hanya sekali per menit (interval periode lompatan), sehingga persyaratan throughput cukup rendah. Oleh karena itu, tidak perlu menetapkan kunci partisi dalam skenario ini.

Pemantauan

Dengan solusi pemrosesan aliran apa pun, performa dan kesehatan sistem harus dipantau. Azure Monitor mengumpulkan metrik dan log diagnostik untuk layanan Azure yang digunakan dalam arsitektur. Azure Monitor dibangun ke dalam platform Azure dan tidak memerlukan kode tambahan dalam aplikasi Anda.

Salah satu sinyal peringatan berikut menunjukkan bahwa Anda harus menskalakan sumber daya Azure yang relevan:

  • Azure Event Hubs membatasi permintaan atau mendekati kuota pesan harian.
  • Pekerjaan Azure Stream Analytics secara konsisten menggunakan lebih dari 80% Unit Streaming (SU) yang dialokasikan.
  • Azure Cosmos DB mulai membatasi permintaan.

Arsitektur referensi mencakup dasbor kustom, yang disebarkan ke portal Azure. Setelah menyebarkan arsitektur, Anda dapat melihat dasbor dengan membuka portal Azure dan memilih TaxiRidesDashboard dari daftar dasbor. Untuk informasi selengkapnya tentang membuat dan menyebarkan dasbor kustom di portal Azure, lihat Membuat Azure Dashboards secara terprogram.

Gambar berikut menunjukkan dasbor setelah pekerjaan Azure Stream Analytics dijalankan selama sekitar satu jam.

Cuplikan layar dasbor Perjalanan Taksi

Panel di kiri bawah menunjukkan bahwa konsumsi SU untuk pekerjaan Azure Stream Analytics naik selama 15 menit pertama dan kemudian turun level. Ini adalah pola yang khas saat pekerjaan mencapai keadaan stabil.

Perhatikan bahwa Azure Event Hubs membatasi permintaan, yang ditampilkan di panel kanan atas. Permintaan yang dibatasi sesekali tidak menjadi masalah, karena SDK klien Azure Event Hubs otomatis mencoba kembali saat menerima kesalahan pembatasan. Namun, jika Anda melihat kesalahan pembatasan yang konsisten, berarti hub peristiwa membutuhkan lebih banyak unit throughput. Grafik berikut menunjukkan pengujian yang dijalankan menggunakan fitur perluas otomatis Azure Event Hubs, yang secara otomatis menskalakan unit throughput sesuai kebutuhan.

Cuplikan layar penskalaan otomatis Azure Event Hubs.

Perluas otomatis diaktifkan pada sekitar 06.35. Anda dapat melihat penurunan p dalam permintaan yang dibatasi, karena Azure Event Hubs otomatis ditingkatkan skalanya hingga 3 unit throughput.

Menariknya, ini memiliki efek samping peningkatan penggunaan SU dalam pekerjaan Azure Stream Analytics. Dengan pembatasan, Azure Event Hubs secara artifisial mengurangi tingkat penyerapan untuk pekerjaan Azure Stream Analytics. Menyelesaikan satu masalah performa biasanya mengungkap masalah yang lain. Dalam hal ini, mengalokasikan SU tambahan untuk pekerjaan Azure Stream Analytics telah menyelesaikan masalah.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Berikut beberapa pertimbangan untuk layanan yang digunakan dalam arsitektur referensi ini.

Azure Stream Analytics

Azure Stream Analytics diberi harga sebesar jumlah unit streaming ($ 0,11/jam) yang diperlukan untuk memproses data ke dalam layanan.

Azure Stream Analytics bisa mahal jika Anda tidak memproses data dalam data real-time atau kecil. Untuk kasus penggunaan tersebut, pertimbangkan untuk menggunakan Azure Functions atau Logic Apps untuk memindahkan data dari Azure Event Hubs ke penyimpanan data.

Azure Event Hubs dan Azure Cosmos DB

Untuk pertimbangan biaya tentang Azure Event Hubs dan Azure Cosmos DB, lihat Pertimbangan biaya lihat Pemrosesan aliran dengan arsitektur referensi Azure Databricks.

DevOps

  • Buat grup sumber daya terpisah untuk lingkungan produksi, pengembangan, dan pengujian. Grup sumber daya yang terpisah akan mempermudah pengelolaan penyebaran, penghapusan penyebaran pengujian, dan penetapan hak akses.

  • Gunakan template Azure Resource Manager untuk menyebarkan sumber daya Azure dengan mengikuti Proses infrastruktur sebagai Kode (IaC). Dengan template, melakukan otomatisasi penyebaran menggunakan Azure DevOps, atau solusi CI/CD lainnya menjadi lebih mudah.

  • Masukkan setiap beban kerja ke dalam templat penyebaran terpisah dan simpan sumber daya dalam sistem kontrol sumber. Anda dapat menyebarkan templat secara bersama-sama atau sendiri-sendiri sebagai bagian dari proses CI/CD, sehingga proses otomatisasi menjadi lebih mudah.

    Dalam arsitektur ini, Azure Event Hubs, Analitik Log, dan Azure Cosmos DB diidentifikasi sebagai beban kerja tunggal. Sumber daya ini disertakan dalam satu template ARM.

  • Pertimbangkan untuk melakukan pentahapan beban kerja. Terapkan ke berbagai tahap dan jalankan pemeriksaan validasi pada setiap tahap sebelum pindah ke tahap berikutnya. Dengan begitu, Anda dapat menerapkan pembaruan ke lingkungan produksi dengan cara yang sangat terkontrol dan meminimalkan masalah penyebaran yang tidak terduga.

  • Pertimbangkan untuk menggunakan Azure Monitor untuk menganalisis performa alur pemrosesan aliran Anda. Untuk informasi selengkapnya, lihat Memantau Azure Databricks.

Untuk informasi selengkapnya, lihat pilar keunggulan operasional di Microsoft Azure Well-Architected Framework.

Menyebarkan skenario ini

Untuk menyebarkan dan menjalankan penerapan referensi, ikuti langkah-langkah dalam pembacaan GitHub.

Anda mungkin ingin meninjau skenario contoh Azure berikut yang menunjukkan solusi spesifik menggunakan beberapa teknologi yang sama: