Buku "Bekerja dengan BigData di awan. Memproses dan menyimpan data dengan contoh-contoh dari Microsoft Azure »

Ini adalah buku berbahasa Rusia yang awalnya rahasia di mana rahasia memproses data besar (Big Data) di awan diperiksa dengan contoh nyata.

Fokusnya adalah pada solusi Microsoft Azure dan AWS. Semua tahapan pekerjaan dipertimbangkan - mendapatkan data yang disiapkan untuk diproses di cloud, menggunakan penyimpanan cloud, alat analisis data cloud. Perhatian khusus diberikan pada layanan SAAS, keunggulan teknologi cloud dibandingkan dengan solusi yang digunakan pada server khusus atau mesin virtual.

Buku ini dirancang untuk khalayak luas dan akan berfungsi sebagai sumber daya yang sangat baik untuk pengembangan Azure, Docker, dan teknologi tak terpisahkan lainnya, yang tanpanya perusahaan modern tidak terpikirkan.

Kami mengundang Anda untuk membaca bagian "Unduh langsung data streaming"

10.1. Arsitektur umum

Dalam bab sebelumnya, kami memeriksa situasi ketika banyak aplikasi klien harus mengirim sejumlah besar pesan yang perlu diproses secara dinamis, ditempatkan di repositori dan kemudian diproses lagi di dalamnya. Pada saat yang sama, perlu untuk dapat mengubah logika dari pemrosesan data dan aliran penyimpanan tanpa menggunakan mengubah kode klien. Dan akhirnya, dari sudut pandang alasan keamanan, klien harus memiliki hak untuk melakukan hanya satu hal - mengirim pesan atau menerimanya, tetapi sama sekali tidak membaca data atau menghapus basis data, dan mereka seharusnya tidak memiliki hak langsung untuk menulis data ini.

Tugas semacam itu sangat umum dalam sistem yang bekerja dengan perangkat IoT yang terhubung melalui koneksi Internet, serta dalam sistem analisis log online. Selain persyaratan yang tercantum di atas untuk layanan khusus kami, ada dua persyaratan lagi yang terkait dengan spesifikasi "Internet of things" dan untuk memastikan pemrosesan pesan yang andal. Pertama-tama, protokol interaksi antara klien dan penerima layanan harus sangat sederhana sehingga dapat diimplementasikan pada perangkat dengan kemampuan komputasi yang terbatas dan memori yang sangat terbatas (misalnya, Arduino, Intel Edison, STM32 Discovery, dan platform "tidak pantas" lainnya, seperti seperti sebelumnya RaspberryPi). Persyaratan berikutnya adalah pengiriman pesan yang andal, terlepas dari kemungkinan kegagalan layanan pemrosesan. Ini adalah persyaratan yang lebih kuat daripada persyaratan keandalan yang tinggi. Memang, untuk memastikan keandalan keseluruhan sistem, perlu bahwa keandalan semua komponennya cukup tinggi dan penambahan komponen baru tidak mengarah pada peningkatan nyata dalam jumlah kegagalan. Selain kegagalan dalam infrastruktur cloud, kesalahan dapat terjadi pada layanan yang dibuat oleh pengguna. Dan bahkan kemudian, pesan harus diproses segera setelah layanan pengguna dipulihkan. Untuk melakukan ini, layanan penerimaan aliran pesan harus dapat menyimpan pesan dengan andal hingga diproses atau hingga masa pakainya berakhir (ini diperlukan untuk mencegah memori berlebih selama aliran pesan berkelanjutan). Layanan dengan properti ini disebut Event Hub. Untuk perangkat IoT terdapat hub khusus (IoT Hub), yang memiliki sejumlah properti lain yang sangat penting untuk digunakan bersama dengan perangkat Internet of Things (misalnya, komunikasi dua arah dari satu titik, perutean pesan bawaan, “digital doubles” dari perangkat dan sejumlah lainnya). Namun, layanan ini masih terspesialisasi, dan kami tidak akan mempertimbangkannya secara rinci.

Sebelum beralih ke konsep konsentrasi pesan, mari kita beralih ke ide-ide yang melatarbelakanginya.

Misalkan kita memiliki sumber pesan (misalnya, permintaan dari klien) dan layanan yang harus menanganinya. Memproses satu permintaan membutuhkan waktu dan membutuhkan sumber daya komputasi (CPU, memori, IOPS). Selain itu, selama pemrosesan satu permintaan, sisa permintaan tidak dapat diproses. Agar aplikasi klien tidak membeku saat menunggu layanan akan dirilis, perlu untuk memisahkannya dengan bantuan layanan tambahan yang akan bertanggung jawab untuk menyimpan pesan saat mereka sedang menunggu pemrosesan saat dalam antrian. Pemisahan ini juga diperlukan untuk meningkatkan keandalan keseluruhan sistem. Memang, klien mengirim pesan ke sistem, tetapi layanan pemrosesan mungkin "jatuh", tetapi pesan tidak boleh hilang, harus disimpan dalam layanan yang lebih dapat diandalkan daripada layanan pemrosesan. Versi paling sederhana dari layanan semacam itu disebut antrian (Gbr. 10.1).


Layanan antrian berfungsi sebagai berikut: klien mengetahui URL antrian dan memiliki kunci akses untuk itu. Menggunakan SDK atau API dari antrian, klien menempatkan pesan di dalamnya yang berisi timestamp, pengidentifikasi dan badan pesan dengan muatan dalam format JSON, XML atau biner.

Kode program layanan termasuk siklus yang "mendengarkan" antrian, mengambil pesan berikutnya di setiap langkah, dan jika ada pesan dalam antrian, itu diekstraksi dan diproses. Jika layanan berhasil memproses pesan, itu dihapus dari antrian. Jika kesalahan terjadi selama pemrosesan, itu tidak dihapus dan dapat diproses lagi ketika versi baru dari layanan, dengan kode yang diperbaiki, diluncurkan. Antrian dirancang untuk menyinkronkan satu klien (atau sekelompok klien serupa) dan tepat satu layanan pemrosesan (meskipun yang terakhir dapat ditemukan di server cluster atau pada server farm). Layanan Antrian Cloud termasuk Antrian Penyimpanan Azure, Antrian Bus Layanan Azure, dan AWS SQS. Layanan yang dihosting di mesin virtual termasuk RabbitMQ, ZeroMQ, MSMQ, IBM MQ, dll.

Layanan antrian yang berbeda menjamin berbagai jenis pengiriman pesan:

• Setidaknya satu kali pengiriman pesan
• pengiriman ketat satu kali;
• pengiriman pesan dengan tetap menjaga pesanan;
• pengiriman pesan tanpa mempertahankan pesanan.

Antrian menyediakan pengiriman pesan yang andal dari satu sumber ke satu layanan pemrosesan, yaitu interaksi satu-ke-satu. Tetapi bagaimana jika perlu menyediakan pengiriman pesan ke beberapa layanan? Dalam hal ini, Anda perlu menggunakan layanan yang disebut "topik" (topik) (Gbr. 10.2).


Elemen penting dari arsitektur ini adalah "langganan". Ini adalah jalur yang terdaftar di bagian di mana pesan dikirim. Pesan diterbitkan dalam topik oleh klien dan ditransfer ke salah satu langganan, dari mana mereka diekstraksi oleh salah satu layanan dan diproses olehnya. Topik menyediakan arsitektur interaksi layanan pelanggan satu-ke-banyak. Contoh layanan tersebut termasuk Topik Bus Layanan Azure dan AWS SNS.

Sekarang anggaplah bahwa ada sejumlah besar klien heterogen yang perlu mengirim banyak pesan ke berbagai layanan, yaitu, kita perlu membangun sistem interaksi banyak-ke-banyak. Tentu saja, arsitektur seperti itu dapat dibangun menggunakan beberapa bagian, tetapi konstruksi seperti itu tidak dapat diskalakan dan membutuhkan upaya untuk administrasi dan pemantauan. Namun, ada layanan terpisah - konsentrator pesan (Gbr. 10.3).


Hub menerima pesan dari banyak klien. Semua klien dapat mengirim pesan ke satu titik akhir layanan umum atau terhubung secara terpisah ke titik akhir yang berbeda melalui tombol khusus. Tombol-tombol ini memungkinkan Anda untuk mengelola klien secara fleksibel: lepaskan beberapa, sambungkan yang baru, dll. Di dalam hub ada juga partisi. Tetapi dalam kasus ini, mereka dapat didistribusikan di antara semua klien untuk meningkatkan produktivitas (round robin - "dengan penambahan siklik") atau klien dapat mempublikasikan pesan di salah satu bagian. Di sisi lain, layanan pemrosesan digabungkan ke dalam kelompok konsumen. Satu atau beberapa layanan dapat dihubungkan ke satu grup. Dengan demikian, konsentrator pesan adalah layanan paling fleksibel yang dapat dikonfigurasi sebagai antrian, bagian atau grup antrian, atau sekumpulan bagian. Secara umum, konsentrator pesan menyediakan hubungan banyak-ke-banyak antara klien dan layanan. Hub ini termasuk Apache Kafka, Azure Event Hub, dan AWS Kinesis Stream.

Sebelum melihat layanan PaaS berbasis cloud, kami akan memperhatikan layanan yang sangat kuat dan terkenal - Apache Kafka. Dalam lingkungan cloud, ini dapat diakses sebagai distribusi yang disebarkan langsung ke kluster mesin virtual atau menggunakan layanan HDInsight. Jadi, Apache Kafka adalah layanan yang menyediakan fitur-fitur berikut:

• Posting dan berlangganan aliran pesan
• penyimpanan pesan yang andal;
• Aplikasi layanan pemrosesan pesan streaming pihak ketiga.

Secara fisik, Kafka berjalan dalam satu cluster dari satu atau lebih server. Kafka menyediakan API untuk berinteraksi dengan klien eksternal (Gbr. 10.4).


Pertimbangkan API ini secara berurutan.

• API Vendor memungkinkan aplikasi klien untuk mempublikasikan aliran pesan dalam satu atau lebih topik Kafka.
• API Pelanggan memberi aplikasi klien kemampuan untuk berlangganan satu atau lebih topik dan memproses aliran pesan yang disampaikan oleh topik ke klien.
• API prosesor aliran memungkinkan aplikasi untuk berinteraksi dengan kluster Kafka sebagai prosesor streaming. Sumber untuk satu prosesor mungkin satu atau lebih topik. Dalam hal ini, pesan yang diproses juga ditempatkan dalam satu atau beberapa topik.
• API konektor membantu untuk menghubungkan sumber data eksternal (misalnya, RDB) sebagai sumber pesan (misalnya, dimungkinkan untuk mencegat peristiwa perubahan data dalam database) dan sebagai penerima.

Di Kafka, interaksi antara klien dan cluster berlangsung melalui TCP, yang difasilitasi oleh SDK yang ada untuk berbagai bahasa pemrograman, termasuk .Net. Tetapi bahasa dasar SDK adalah Java dan Scala.

Dalam sebuah cluster, penyimpanan aliran pesan (dalam terminologi Kafka juga disebut sebagai entri) terjadi secara logis pada objek yang disebut topik (Gbr. 10.5). Setiap catatan terdiri dari kunci, nilai, dan cap waktu. Intinya, topik adalah urutan catatan (pesan) yang telah diterbitkan oleh pelanggan. Topik Kafka mendukung dari 0 hingga beberapa pelanggan. Setiap topik secara fisik direpresentasikan sebagai log yang dipartisi. Setiap bagian adalah urutan catatan yang terurut, dimana yang baru tiba di input Kafka terus ditambahkan.


Setiap entri di bagian sesuai dengan nomor dalam urutan, juga disebut offset, yang secara unik mengidentifikasi pesan ini dalam urutan. Tidak seperti antrian, Kafka menghapus pesan tidak setelah memproses layanan, tetapi setelah masa pakai pesan. Ini adalah properti yang sangat penting, memberikan kemampuan membaca dari satu topik ke konsumen yang berbeda. Selain itu, bias dikaitkan dengan masing-masing konsumen (Gambar 10.6). Dan setiap tindakan membaca hanya mengarah pada peningkatan nilai untuk setiap klien secara individual dan ditentukan secara tepat oleh klien.


Dalam kasus normal, offset ini bertambah satu setelah berhasil membaca satu pesan dari topik. Tetapi jika perlu, klien dapat menggeser offset ini dan mengulangi operasi baca.

Menggunakan konsep bagian memiliki tujuan sebagai berikut.

Pertama, bagian memberikan kemampuan untuk skala topik ketika satu topik tidak cocok dalam simpul yang sama. Pada saat yang sama, setiap bagian memiliki satu simpul memimpin (jangan bingung dengan simpul kepala dari seluruh kluster) simpul dan nol atau beberapa simpul pengikut. Node kepala bertanggung jawab atas pemrosesan operasi baca / tulis, sementara pengikut adalah salinan pasifnya. Jika master node gagal, salah satu node penerus secara otomatis akan menjadi simpul kepala. Setiap simpul kluster adalah pengarah untuk beberapa bagian dan pengikut untuk yang lain. Kedua, replikasi tersebut meningkatkan kinerja pembacaan karena kemungkinan operasi pembacaan paralel.

Produser dapat menempatkan pesan dalam topik apa pun pilihannya secara eksplisit atau dalam mode round robin secara implisit (yaitu, dengan pengisian seragam). Konsumen disatukan dalam apa yang disebut kelompok konsumen, dan setiap pesan yang diterbitkan dalam topik disampaikan kepada satu pelanggan di setiap kelompok konsumen. Klien dalam hal ini dapat di-host secara fisik di satu atau lebih server / mesin virtual. Secara lebih rinci, pengiriman pesan adalah sebagai berikut. Untuk semua pelanggan yang termasuk dalam kelompok konsumen yang sama, pesan dapat didistribusikan antar pelanggan untuk mengoptimalkan pemuatan. Jika pelanggan termasuk kelompok konsumen yang berbeda, maka setiap pesan akan dikirim ke masing-masing kelompok. Pemisahan pesan dari bagian oleh kelompok konsumen yang berbeda ditunjukkan pada Gambar. 10.7.

Sekarang saya akan menjelaskan secara singkat parameter utama pengiriman dan penyimpanan pesan yang dijamin oleh Kafka.

• Pesan yang dikirim oleh produsen ke topik tertentu akan ditambahkan secara ketat sesuai urutan pengirimannya.
• Klien melihat urutan pesan dalam topik yang diterima saat pesan disimpan. Akibatnya, pesan dikirim dari produsen ke konsumen secara ketat sesuai urutan penerimaannya.
• Replikasi topik N-lipat memastikan stabilitas topik terhadap kegagalan N-1 node tanpa kehilangan kinerja.

Jadi, layanan Apache Kafka dapat digunakan dalam mode berikut.

• Layanan - broker pesan (antrian) atau layanan publikasi - berlangganan pesan (topik). Memang, Kafka didasarkan pada sekelompok topik yang dapat dikonversi menjadi antrian dengan satu pelanggan. (Harus diingat: berbeda dengan layanan pialang pesan biasa, yang dibangun berdasarkan prinsip antrian, dalam pesan Kafka dihapus hanya setelah masa pakainya berakhir, sementara pialang menerapkan prinsip Peek-Delete, yaitu pengambilan dan penghapusan setelah pemrosesan berhasil. ) Prinsip kelompok konsumen merangkum dua konsep ini, dan kemampuan untuk mempublikasikan pesan dalam semua topik dengan distribusi round robin menjadikan Kafka sebagai pialang pesan multi-mode universal.
• Layanan untuk analisis pesan streaming. Ini dimungkinkan berkat API untuk prosesor streaming yang termasuk dalam Kafka, yang memungkinkan Anda membangun sistem yang kompleks, dibuat berdasarkan Event Driven, dengan layanan yang memfilter pesan atau meresponsnya, serta layanan yang menggabungkan pesan.

Semua properti ini memungkinkan untuk menggunakan Kafka sebagai komponen utama platform yang bekerja dengan streaming data dan memiliki kemampuan hebat untuk membangun sistem pemrosesan pesan yang kompleks. Tetapi pada saat yang sama, Kafka cukup rumit dalam hal penempatan dan konfigurasi sekelompok beberapa node, yang membutuhkan upaya administrasi yang signifikan. Tetapi, di sisi lain, karena ide-ide yang mendasari Kafka sangat cocok untuk membangun sistem, streaming pesan dan menerima pesan, penyedia cloud menyediakan layanan PaaS yang mengimplementasikan ide-ide ini dan menyembunyikan semua kesulitan membangun dan mengelola cluster Kafka. Tetapi karena layanan ini memiliki sejumlah batasan dalam hal kustomisasi dan ekspansi di luar batas yang dialokasikan untuk layanan, penyedia cloud menyediakan layanan IaaS / PaaS khusus untuk penyebaran fisik Kafka dalam kelompok mesin virtual. Dalam hal ini, pengguna memiliki kebebasan hampir lengkap untuk konfigurasi dan ekspansi. Layanan ini termasuk Azure HDInsight. Sudah disebutkan di atas. Itu dibuat untuk, di satu sisi, menyediakan pengguna dengan layanan dari ekosistem Hadoop sendiri, tanpa pembungkus eksternal, dan di sisi lain, untuk meringankan kesulitan yang timbul dari instalasi langsung, administrasi dan konfigurasi IaaS. Hosting Docker agak terpisah. Karena ini adalah topik yang sangat penting, kami akan mempertimbangkannya, tetapi pertama-tama berkenalan dengan layanan PaaS yang diimplementasikan menggunakan konsep dasar Kafka.

10.2. Pusat acara Azure

Pertimbangkan layanan hub pesan Pusat Acara Azure. Ini adalah layanan yang dibangun pada model PaaS. Berbagai grup klien dapat bertindak sebagai sumber pesan untuk Azure Event Hub (Gambar 10.8). Pertama-tama, ini adalah kelompok layanan cloud yang sangat besar yang output atau pemicunya dapat dikonfigurasikan untuk mengirim pesan langsung ke Event Hub. Ini bisa berupa Stream Analytics Job, Event Grid dan sekelompok layanan signifikan yang mengarahkan kembali peristiwa - log di Hub Acara (terutama dibangun menggunakan AppService: Aplikasi Api, Aplikasi Web, Aplikasi Seluler, dan Aplikasi Fungsi).


Pesan yang dikirim ke hub dapat langsung ditangkap dan disimpan di Blob Storage atau Data Lake Store.

Kelompok sumber berikutnya adalah klien atau perangkat lunak eksternal yang tidak ada Azure Event Hub SDK dan yang tidak dapat diintegrasikan langsung dengan layanan Azure. Klien-klien ini terutama termasuk perangkat IoT. Mereka dapat mengirim pesan ke Event Hub melalui HTTPS atau AMQP. Pertimbangan tentang bagaimana menghubungkan perangkat-perangkat ini berada di luar cakupan buku kami.

Akhirnya, klien perangkat lunak yang menghasilkan pesan dan mengirimkannya ke Event Hub menggunakan Azure Event Hub SDK. Grup ini mencakup Azure PowerShell dan Azure CLI.
Sebagai penerima pesan (konsumen - "konsumen") dari Hub Peristiwa, Pekerjaan Stream Analytics atau layanan integrasi Grid Peristiwa dapat digunakan. Selain itu, dimungkinkan untuk menerima pesan oleh klien perangkat lunak menggunakan Azure Event Hub SDK. Konsumen terhubung ke Event Hub menggunakan protokol AMQP 1.0.

Pertimbangkan konsep dasar dari Azure Event Hub yang diperlukan untuk memahami cara menggunakannya dan mengkonfigurasinya. Sumber apa pun (juga disebut penerbit dalam dokumentasi) yang mengirim pesan ke hub harus menggunakan HTTPS atau AMQP 1.0. Pilihan protokol ditentukan oleh jenis klien, jaringan komunikasi dan persyaratan untuk tingkat pesan. AMQP membutuhkan koneksi permanen antara dua soket TCP dua arah. Itu dilindungi dengan menggunakan protokol enkripsi lapisan transport TLS atau SSL / TLS. , , AMQP , HTTPS, . HTTPS.

, SAS (Shared Access Signature) tokens. SAS- SAS . SAS-, ( ).

256 . , .

, Event Hub. , , , -. EventHub (partitions). EventHub — , « — » (FIFO) (. 10.9).


— Event Hub. Event Hub 2 32 , Event Hub. , .

( ) , ( , — . ), (retention period), . . . , Azure Event Hub (offset). — , , , , . . Azure Event Hub SDK , , . -, .


, , , , . Azure Event Hub SDK , . , Storage Account. Azure, Event Hub, .

Event Hub (partition key), . — . , ( ) . , (round robin).

. , (consumer group) (. 10.11). . (view) ( ) , , . , . — 20, , .

. , . , (throughput unit). :

• — 1 M 1000 ( , );
• — 2 M .

. , . . . Berhati-hatilah! , , , Event Hub.


(namespace) (. 10.12).



»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit
» Isi
» Kutipan

Kupon diskon 20% untuk penjaja - BigData