Mengapa streaming di Orleans?

Berbagai teknologi sudah ada untuk membangun sistem pemrosesan aliran. Ini termasuk sistem untuk menyimpan data aliran secara tahan lama (misalnya, Event Hubs dan Kafka) dan sistem untuk menjalankan operasi komputasi atas data aliran (misalnya, Azure Stream Analytics, Apache Storm, dan Apache Spark Streaming). Ini adalah sistem hebat yang memungkinkan Anda membangun alur pemrosesan aliran data yang efisien.

Batasan sistem yang ada

Namun, sistem ini tidak cocok untuk komputasi bentuk bebas halus melalui data streaming. Sistem komputasi streaming yang disebutkan di atas semuanya memungkinkan Anda menentukan grafik operasi aliran data terpadu yang diterapkan dengan cara yang sama ke semua item streaming. Ini adalah model yang kuat ketika data seragam dan Anda ingin mengekspresikan serangkaian operasi transformasi, pemfilteran, atau agregasi yang sama atas data ini. Tetapi kasus penggunaan lainnya mengharuskan mengekspresikan operasi yang secara mendasar berbeda atas item data yang berbeda. Dalam beberapa kasus ini, sebagai bagian dari pemrosesan, Anda mungkin kadang-kadang perlu melakukan panggilan eksternal, seperti memanggil REST API arbitrer. Mesin pemrosesan aliran data terpadu tidak mendukung skenario ini, mendukungnya dengan cara yang terbatas dan dibatasi, atau tidak efisien dalam mendukungnya. Ini karena secara inheren dioptimalkan untuk volume besar item serupa dan yang biasanya terbatas dalam hal daya ekspresi dan pemrosesan. Orleans Stream menargetkan skenario lain.

Motivasi

Semuanya dimulai dengan permintaan dari Orleans pengguna untuk mendukung pengembalian daftar item dari panggilan metode grain. Seperti yang dapat Anda bayangkan, itu hanya ujung gunung es; mereka membutuhkan lebih banyak.

Skenario umum untuk Orleans Stream adalah ketika Anda memiliki aliran per pengguna dan ingin melakukan pemrosesan yang berbeda untuk setiap pengguna dalam konteks pengguna individual tersebut. Anda mungkin memiliki jutaan pengguna, tetapi beberapa tertarik dengan cuaca dan berlangganan pemberitahuan cuaca untuk lokasi tertentu, sementara yang lain tertarik pada acara olahraga; orang lain mungkin melacak status penerbangan tertentu. Memproses peristiwa ini memerlukan logika yang berbeda, tetapi Anda tidak ingin menjalankan dua instans pemrosesan aliran independen. Beberapa pengguna mungkin hanya tertarik pada stok tertentu dan hanya jika kondisi eksternal tertentu berlaku—kondisi yang mungkin belum tentu menjadi bagian dari data aliran (dan dengan demikian perlu memeriksa secara dinamis pada runtime sebagai bagian dari pemrosesan).

Pengguna mengubah minat mereka setiap saat, sehingga langganan mereka ke aliran peristiwa tertentu datang dan berjalan secara dinamis. Dengan demikian, topologi streaming berubah secara dinamis dan cepat. Di atas itu, logika pemrosesan per pengguna berevolusi dan berubah secara dinamis berdasarkan status pengguna dan peristiwa eksternal. Peristiwa eksternal mungkin mengubah logika pemrosesan untuk pengguna tertentu. Misalnya, dalam sistem deteksi kecurangan game, ketika metode kecurangan baru ditemukan, logika pemrosesan perlu diperbarui dengan aturan baru untuk mendeteksi pelanggaran ini. Ini harus dilakukan, tentu saja, tanpa mengganggu alur pemrosesan yang sedang berlangsung. Mesin pemrosesan aliran aliran data massal tidak dibangun untuk mendukung skenario tersebut.

Hampir tanpa mengatakan bahwa sistem seperti itu harus berjalan pada beberapa komputer yang terhubung ke jaringan, bukan hanya satu simpul. Oleh karena itu, logika pemrosesan harus didistribusikan secara terukur dan elastis di seluruh kluster server.

Persyaratan baru

Empat persyaratan dasar diidentifikasi untuk sistem Pemrosesan Aliran untuk menargetkan skenario di atas:

1. Logika pemrosesan aliran fleksibel
2. Dukungan untuk topologi yang sangat dinamis
3. Granularitas aliran berbutir halus
4. Distribusi

Logika pemrosesan aliran fleksibel

Sistem harus mendukung berbagai cara untuk mengekspresikan logika pemrosesan aliran. Sistem yang ada yang disebutkan di atas mengharuskan pengembang untuk menulis grafik komputasi aliran data deklaratif, biasanya mengikuti gaya pemrograman fungsi. Ini membatasi ekspresi dan fleksibilitas logika pemrosesan. Orleans aliran tidak peduli dengan bagaimana logika pemrosesan dinyatakan. Ini dapat dinyatakan sebagai aliran data (misalnya, menggunakan Ekstensi Reaktif (Rx) di .NET), program fungsional, kueri deklaratif, atau logika imperatif umum. Logika dapat bersifat stateful atau stateless, dapat memiliki atau tidak memiliki efek samping, dan dapat memicu tindakan eksternal. Semua kekuasaan diberikan kepada pengembang.

Dukungan untuk topologi dinamis

Sistem harus memungkinkan topologi yang berkembang secara dinamis. Sistem yang ada yang disebutkan di atas biasanya terbatas pada topologi statis yang ditetapkan pada waktu penyebaran dan tidak dapat berkembang saat waktu run. Dalam contoh ekspresi aliran data berikut, semuanya bagus dan sederhana sampai Anda perlu mengubahnya:

Stream.GroupBy(x=> x.key).Extract(x=>x.field).Select(x=>x+2).AverageWindow(x, 5sec).Where(x=>x > 0.8) *

Ubah kondisi ambang dalam Where filter, tambahkan Select pernyataan, atau tambahkan cabang lain di grafik aliran data dan hasilkan aliran output baru. Dalam sistem yang ada, ini tidak dimungkinkan tanpa merobohkan seluruh topologi dan memulai ulang aliran data dari awal. Praktis, sistem ini memeriksa komputasi yang ada dan dapat memulai ulang dari titik pemeriksaan terbaru. Namun, memulai ulang seperti itu mengganggu dan mahal bagi layanan online yang menghasilkan hasil dalam waktu nyata. Pengulangan seperti itu menjadi sangat tidak praktis ketika menghadapi sejumlah besar ekspresi yang dijalankan dengan parameter yang serupa tetapi berbeda (seperti per pengguna, per perangkat, dll.) yang terus berubah.

Sistem harus memungkinkan mengembangkan grafik pemrosesan aliran saat runtime dengan menambahkan tautan atau simpul baru ke grafik komputasi atau mengubah logika pemrosesan dalam simpul komputasi.

Granularitas aliran berbutir halus

Dalam sistem yang ada, unit abstraksi terkecil biasanya adalah seluruh aliran (topologi). Namun, banyak skenario target memerlukan node/tautan individual dalam topologi untuk menjadi entitas logis itu sendiri. Dengan cara ini, setiap entitas berpotensi dapat dikelola secara independen. Misalnya, dalam topologi aliran besar yang terdiri dari beberapa tautan, tautan yang berbeda dapat memiliki karakteristik yang berbeda dan diimplementasikan melalui transportasi fisik yang berbeda. Beberapa tautan mungkin melewati soket TCP, sementara yang lain menggunakan antrean yang andal. Tautan yang berbeda dapat memiliki jaminan pengiriman yang berbeda. Simpul yang berbeda dapat memiliki strategi titik pemeriksaan yang berbeda, dan logika pemrosesannya dapat diekspresikan dalam model yang berbeda atau bahkan bahasa yang berbeda. Fleksibilitas seperti itu biasanya tidak dimungkinkan dalam sistem yang ada.

Unit argumen abstraksi dan fleksibilitas mirip dengan membandingkan SoA (Service Oriented Architectures) vs. Actor. Sistem aktor memungkinkan lebih banyak fleksibilitas karena setiap aktor pada dasarnya adalah "layanan kecil" yang dikelola secara independen. Demikian pula, sistem aliran harus memungkinkan kontrol halus seperti itu.

Distribusi

Dan tentu saja, sistem harus memiliki semua properti "sistem terdistribusi yang baik". Itu termasuk:

1. Skalabilitas: Mendukung sejumlah besar aliran dan elemen komputasi.
2. Elastisitas: Memungkinkan penambahan/penghapusan sumber daya untuk tumbuh/menyusut berdasarkan beban.
3. Keandalan: Tahan terhadap kegagalan.
4. Efisiensi: Menggunakan sumber daya yang mendasar secara efisien.
5. Responsivitas: Memungkinkan skenario mendekati real-time.

Ini adalah persyaratan untuk membangun Orleans Streaming.

Klarifikasi: Orleans saat ini tidak secara langsung mendukung penulisan ekspresi aliran data deklaratif seperti pada contoh di atas. API Streaming saat ini Orleans adalah blok penyusun tingkat yang lebih rendah, seperti yang dijelaskan di Orleans API streaming.

Lihat juga

Orleans API Pemrograman Streaming