Pemrosesan aliran dengan Azure 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 selengkapnya.

Implementasi referensi untuk arsitektur ini tersedia di GitHub.

Sistem

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 yang disimulasikan, yang membaca dari sekumpulan file statis 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 menganggap 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 yang 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.

Kemungkinan kasus penggunaan

Solusi ini dioptimalkan untuk skenario ritel.

Penyerapan data

Untuk menyimulasikan sumber data, arsitektur referensi ini menggunakan himpunan data Data Taksi Kota New York^[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 melakukan segmentasi data. Partisi memungkinkan konsumen membaca setiap partisi secara paralel. Saat 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 di partisi n data perjalanan akan cocok dengan catatan di partisi n data tarif.

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 aliran

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).

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 tenet 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:

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.

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.

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 adalah 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.

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

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

• Pertimbangkan untuk melakukan pentahapan beban kerja. Sebarkan ke berbagai tahap dan jalankan pemeriksaan validasi di setiap tahap sebelum melanjutkan 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.

Sumber daya terkait

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

• Deteksi penipuan real time