ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 143
Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 53
Abonament PDF

Să fim inventivi cu procesarea și colectarea de date

Radu Vunvulea
Solution Architect
@iQuest



PROGRAMARE

În acest articol vă propun să descoperim o altă abordare în colectarea și transformarea informaţiei care este transmisă de dispozitive.

În lumea dispozitivelor inteligente, acestea au devenit din ce în ce mai vorbăreţe.  Să presupunem că avem un dispozitiv inteligent care trebuie să trimită, la fiecare 30 de secunde, un impuls de locaţie (Location Heartbeat) care conţine \. Avem, la nivel global, 1.000.000 de dispozitive care trimit această informaţie în backendul nostru.

La nivel global, backendul rulează pe 4 Regiuni Azure diferite, cu o distribuţie egală a dispozitivelor. Acest lucru presupune că pe fiecare instanţă a backendului vom avea 250.000 de dispozitive care trimit impulsuri (informaţii) cu locaţiile lor.

Din perspectiva încărcării datelor, se estimează că pentru fiecare Regiune Azure avem aproximativ 8.300 de interogări de impulsuri pe secundă. Mesaje cu dimensiunea de 8K pe secundă ar putea să se poată încărca sau nu. Totul depinde de acţiunile pe care trebuie să le facem pentru fiecare interogare.

Cerinţe

Utilizatorul final trebuie să îndeplinească două cerinţe în mod obligatoriu:

Prima cerinţă nu pune dificultăţi. Din punctul de vedere al implementării, trebuie să păstrăm toate locaţiile impulsurilor într-o zonă de depozitare (repository). Zona de depozitare poate să fie bazată pe fișiere.

A doua cerinţă este mai dificilă din cauza complexităţii sale. Aceasta presupune ca ultima locaţie a dispozitivului să fie disponibilă în permanenţă.

Soluţia clasică

Soluţia pentru această situaţie este de a avea un sistem de mesaje, bazat pe evenimente, care reunește toate impulsurile de locaţie de pe dispozitive. Pe Azure, putem folosi Azure Event Hub, care poate accepta volume mari de date.

În spate, avem nevoie de o unitate de computare care să poată fi scalată ușor. Principalul scop al acestei unităţi va fi să proceseze fiecare impuls de locaţie, trimiţând informaţia într-o zonă de depozitare pentru audit și să actualizeze ultima locaţie a dispozitivului.

Pentru procesare, putem folosi Worker Roles sau Azure Service Fabric. În ambele situaţii, trebuie să vă așteptaţi ca timpul de procesare să fie între 0.4-0.5s (stocarea datelor și actualizarea ultimei locaţii). Vei avea nevoie de cel puţin 16 instanţe de Worker Roles care să facă acest lucru.

Auditul locaţiei dispozitivului poate fi stocat în bloburi. Dacă nu vreţi să faceţi acest lucru de mână, puteţi folosi Azure Event Hubs Archive. Acest feature nou oferit de Azure, poate să facă asta pentru voi, depozitând toate evenimentele direct în bloburi. Această soluţie este aplicabilă atâta timp cât nu trebuie să operate transformări asupra mesajelor.  

Există multe opţiuni pentru stocarea ultimei locaţii. Cea mai rapidă este de a avea in-memory cache precum NCache și de a actualiza ultima locaţie. Dezavantajul acestei abordări este că va trebui să accesaţi această informaţie și un API să fie disponibil, sau, la anumite intervale, să se realizeze depozitare în Azure Table și să se lucreze cu SQL.

Poate vă întrebaţi de ce nu am propus Azure Redis Cache sau alt serviciu cache. Când scrii mult, un sistem cache nu se comportă după cum v-aţi așepta. În trecut, am avut probleme cu astfel de soluţii unde latenţa citire-scriere este de 2-5s datorită influxului mare de date scrise (da, au existat multe operaţii de scriere).

Azure Tables reprezintă o soluţie mai bună. Fiecare rând stochează ultima locaţie a dispozitivului. De fiecare dată când se primește o nouă locaţie, informaţia este actualizată. Puteţi înlocui Azure Table cu SQL dacă rapoartele pe care trebuie să le faceţi sunt complexe sau trebuie să generaţi rapoartele pe loc (Azure Table poate fi un prieten bun, chiar și în aceste situaţii).

Costuri

Chiar dacă încercăm să optimizăm codul, înregistrarea și scrierea ultimei locaţii a unui dispozitiv este scumpă. Trebuie să identificaţi dispozitivul, să preluaţi tabela, să editaţi/scrieţi conţinutul. Prin urmare, chiar dacă reduceţi timpul de la 0.4-0.5s la 0.2-0.3s, tot va fi scump.

Pentru a consuma și a procesa 8.300 de impulsuri de locaţie pe secundă, tot va fi scump. Să presupunem că puteţi procesa 500 de impulsuri în cadrul unui Worker Role. Acest fapt presupune cel puţin 17-18 instanţe de Worker Role.

Identificare blocajului

Acum trebuie să vedem cum putem folosi Azure Services în avantajul nostru. Trebuie să ne reducem codul customizat. Pe termen lung, acest lucru presupune un cost mic pentru mentenanţă și suport, iar numărul de buguri va fi și el mai mic.

Presupunerea noastră este că nu putem utiliza Azure Event Hub Archive deoarece există transformări care trebuie stocate în formatul convenit de audit.

Primul lucru pe care îl vom face este să separăm aceste două cerinţe în module diferite. Primul modul ar crea datele de audit, iar celălalt ar stoca ultima locaţie a dispozitivului.

Remarci

Orice veţi face, veţi folosi Event Processor Host pentru a consuma mesajele din Event Hub. Acest lucru vă asigură că aveţi:

Dacă rulăm aceste două module separat, observăm că procesarea impulsurilor de locaţie doar pentru audit este extrem de rapidă. Pe un singur Worker Role, putem procesa 4000-5000 de impulsuri de locaţie pe secundă. Comparativ cu acţiunea de a actualiza ultima locaţie a dispozitivului, aceasta este o acţiune cu cost ridicat.

Problema nu provine din Azure Table, unde latenţa este mică. Diferenţa este că, pentru audit, doar transformaţi mesajele și le stocaţi. Strategii precum buffering pot optimiza aceste acţiuni. Orice facem, nu putem procesa mai mult de 600 de impulsuri de locaţie pe secundă pe fiecare instanţă de computare.

Să fim inventivi

Am observat că crearea datelor de audit este o acţiune cu consum scăzut. Stocarea ultimei locaţii a dispozitivului este scumpă. Dacă ne uităm la ultima locaţie a dispozitivului, din nou, ne dăm seama că această acţiune ar putea fi făcută direct de dispozitiv.

De ce să nu facem ca dispozitivul să își actualizeze rândurile din Azure Table direct, cu ultima locaţie cunoscută? Astfel, nu trebuie să procesăm datele și să actualizăm ultima locaţie folosind resursele backend.

Din perspectiva accesului, Azure Table Shared Access Signature (SAS) ne permite să oferim acces granular la partiţie și la cheia de la nivelul de rând. Fiecare dispozitiv poate avea acces doar la propriul rând din tabelă.

Fiecare dispozitiv interoghează Azure Table pentru a actualiza ultima locaţie cunoscută. O altă interogare este trimisă către Azure Event Hub pentru a împinge impulsul de locaţie la audit. Pe partea de backend, elementele ce trebuie încărcate descresc drastic. Avem nevoie doar de instanţe de Worker Roles care creează datele de audit. În Azure Tables vom avea ultima locaţie a fiecărui dispozitiv disponibil pentru raportare sau alte tipuri de acţiuni.

La nivel de dispozitiv, lucrurile arată diferit. Pentru fiecare impuls de locaţie, un dispozitiv trebuie să facă două interogări. Aceasta înseamnă că dispozitivul va consuma mai multă bandă, puţin mai mult CPU și mai multă lungime de bandă. Această abordare este validă pentru dispozitive care au o conexiune bună la Internet (ieftină) și care nu au limitări stricte de CPU.

Astfel, datele ce trebuie încărcate sunt mutate dintr-un loc în altul, fapt ce duce la creșterea zgomotului pe Internet.

O altă abordare este a avea un Azure Table pentru fiecare dispozitiv, unde dispozitivele adaugă rânduri noi permanent. Nu vom explora această soluţie care este interesantă atâta timp cât nu avem nevoie de rapoarte complexe.

Concluzie

Pentru a rezolva o problemă de business, există mereu soluţii și abordări multiple. Sunt situaţii când abordarea potrivită este să se facă un pas înapoi și a se vedea cum pot fi folosite serviciile de pe piaţă pentru a rezolva probleme diferite.

Apelarea directă a serviciilor ar putea fi o soluţie mai bună, dar nu uitaţi de costul acelei interogări la nivel de dispozitiv.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects

INTERVIURI VIDEO