Arhitectura Lambda este o arhitectură de prelucrare a datelor concepută pentru a gestiona cantități uriașe de date prin utilizarea metodelor de procesare a loturilor și de procesare a fluxului . Această abordare a arhitecturii încearcă să echilibreze latența, randamentul și toleranța față de eșecuri folosind procesarea batch pentru a oferi o vizualizare completă și exactă a datelor în loturi, în timp ce utilizează simultan tratamentul în timp real pentru a furniza vizualizări online ale datelor. Cele două ieșiri de vizualizare pot fi unite înainte de prezentare. Creșterea arhitecturii lambda este corelată cu creștereaBigData , către analiza în timp real și dorința de a atenua latențele mapreduce .
Arhitectura Lambda se bazează pe un model de date cu o sursă de date imuabilă, adăugată numai, care servește ca sistem de înregistrare. Este destinat achiziționării și prelucrării evenimentelor marcate cu timp care se adaugă la evenimentele existente în loc să le suprascrieți. Starea este determinată din ordinea naturală a datelor bazate pe timp.
Arhitectura Lambda este un sistem format din trei straturi: procesare batch, procesare rapidă (sau în timp real) și un strat server pentru a răspunde cererilor. . Straturile de procesare dobândesc întregul set de date dintr-o copie master imuabilă.
Stratul de procesare în serie precomputează rezultatele folosind un sistem de procesare distribuit capabil să proceseze cantități foarte mari de date. Stratul de procesare în serie are ca scop o precizie perfectă, permițând prelucrarea tuturor datelor disponibile la generarea vizualizărilor. Aceasta înseamnă că poate corecta erorile recalculând toate datele și apoi actualizând vizualizările existente. Ieșirea este stocată de obicei într-o bază de date numai în citire, actualizările înlocuind complet vizualizările precomputate existente.
Apache Hadoop este sistemul standard de procesare de serie, de facto, utilizat în majoritatea arhitecturilor cu randament ridicat.
Stratul în timp real procesează fluxurile de date în timp real și fără cerințele de remediere sau completitudine. Acest strat sacrifică randamentul, deoarece își propune să minimizeze latența, oferind vizualizări în timp real ale celor mai recente date. În esență, stratul în timp real este responsabil pentru umplerea „golului” cauzat de întârzierea stratului de procesare a lotului în furnizarea de vizualizări pe baza celor mai recente date. Vizualizările din acest strat pot să nu fie la fel de exacte sau complete ca cele produse de stratul de lot, dar sunt disponibile aproape imediat după primirea datelor și pot fi suprascrise atunci când vizualizările din stratul de lot devin disponibile.
Tehnologiile de procesare a fluxurilor utilizate în mod obișnuit în acest strat includ Apache Storm , SQLstream, Apache Spark sau Apache Flink . Ieșirea este de obicei stocată pe baze de date rapide NoSQL .
Ieșirea straturilor de lot și a straturilor în timp real este stocată în stratul de servicii, care răspunde solicitărilor ad hoc prin returnarea vizualizărilor precomputate sau prin crearea de vizualizări din datele procesate.
Ca exemplu de tehnologie utilizată în stratul de servicii putem cita Apache Druid , care oferă un singur cluster pentru a gestiona ieșirea ambelor straturi. Alte tehnologii pentru stratul de servicii includ Apache Cassandra , Apache HBase , MongoDB , VoltDB sau Elasticsearch pentru ieșirea stratului în timp real, și Elephant DB , Apache Impala , SAP HANA sau Apache Hive pentru ieșirea stratului de lot..
Pentru a optimiza setul de date și pentru a îmbunătăți eficiența interogării, diferite tehnici de acumulare și agregare sunt efectuate pe date brute, în timp ce tehnici de estimare sunt utilizate pentru a reduce și mai mult costurile de calcul. Și, deși este necesară o recalculare completă și costisitoare pentru toleranța la erori, algoritmii de calcul incrementali pot fi adăugați selectiv pentru a crește eficiența și tehnici precum calculul parțial și optimizarea utilizării. Resursele pot ajuta în mod eficient la reducerea latenței.
Critica arhitecturii lambda s-a concentrat asupra complexității sale inerente și asupra influenței sale limitative. Partile de lot și de streaming necesită fiecare o bază de cod diferită care trebuie gestionată și sincronizată astfel încât datele procesate să producă același rezultat în ambele căi. Cu toate acestea, încercarea de a scăpa de bazele de coduri într-un singur cadru nu pune la îndemână multe instrumente specializate în ecosisteme batch și în timp real.
În timpul unei discuții tehnice cu privire la beneficiile utilizării unei abordări de streaming pur, s-a observat că utilizarea unui cadru de streaming flexibil, cum ar fi Apache Samza, ar putea oferi aceleași beneficii ca și procesarea în serie, fără latență. O astfel de structură de streaming ar putea face posibilă colectarea și procesarea ferestrelor de date de dimensiuni arbitrare, adaptarea blocării și gestionarea stării.