Документ обсуждает архитектуру Lambda для реального времени аналитики, выделяя ее риски и преимущества. Основное внимание уделяется различиям между потоковой агрегацией и пакетной обработкой данных, а также проблемам, связанным с фильтрацией не человечьей активности и обработкой ошибок. В заключение описаны недостатки архитектуры Lambda, включая дублирование логики и необходимость упрощения процессов в скоростном слое.

1. Lambda
architecture
для RealTime-аналитики:
риски и преимущества
Николай Голов

3. • Redshift
• Vertica
• MongoDB
• Hadoop
• HDFS
• MapReduce
• Hive/Pig

4. Streaming VS Batching
• Batching – анализ полной совокупности собранных данных
• например, SQL-запросы к собранной базе;
• например, MapReduce-запрос к данным Hadoop;
• Streaming – живая агрегация на потоке
• RealTime-счетчики на потоке
queryresult
aggregation result

5. Преимущества и недостатки
• Streaming
• + агрегация на лету, очень быстро;
• + объем обрабатываемых данных не ограничен дисками,
«boundless data»
• - тяжело реализовать сложную логику;
• - очень тяжело исправить ошибку задним числом.
• Batching
• +можно сделать сложную логику;
• +легко пересчитывать;
• -существенные временные задержки;
• -объем анализируемых данных ограничен местом на дисках.

6. Lambda Architecture

7. Задача – сервис счетчиков
• Нужно считать подневное количество определенных событий:
• Просмотры объявления;
• Просмотры телефона объявления;
• Просмотры объявлений пользователя;
• …. .
• Фильтрация – считать только людей, без ботов/парсеров;
• Изменчивость – в любой момент могут добавить новые счетчики,
изменить фильтрацию;
• Скорость – в идеале реальное время. Секунды отставания;
• Стабильность – цифры за прошлое не должны сильно «прыгать».

8. Primitive approach
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Stream of web-site actions: clicks, views,searches
In-memory storage (Redis, Tarantool)
Streaming aggregation of item 0X views
Streaming aggregation of item 0X phone views
Web-servers

9. Problem 01 – new aggregates
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
In-memory storage (Redis, Tarantool)
Streaming aggregation of item 0X views
Streaming aggregation of item 0X phone views
Streaming aggregation of user 0Y profile views
Stream of web-site actions: clicks, views,searches
Web-servers

10. Problem 02 – filtering of non-human activity
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Stream of web-site actions: clicks, views, searches
In-memory storage (Redis, Tarantool)
Streaming aggregation of item 0X views
Streaming aggregation of item 0X phone views
Streaming aggregation of user 0Y profile views
Web-servers

11. Problem 03 – errors in the past
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Stream of web-site actions: clicks, views, searches
In-memory storage (Redis, Tarantool)
Streaming aggregation of item 0X views
Streaming aggregation of item 0X phone views
Streaming aggregation of user 0Y profile views
-wrong filter/wrong code/… some fail
Web-servers
Wrong/empty aggregates

12. Lambda as a solution
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming aggregation of item 0X views
Streaming aggregation of phone views
Web-servers
Batch
aggregation

13. Problem 01 – new aggregates
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming aggregation of item 0X views
Streaming aggregation of phone views
Web-servers
Batch
aggregation
Streaming aggregation of user 0Y p. views

14. Problem 02 – filtering of non-human activity
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming aggregation of item 0X views
Streaming aggregation of phone views
Web-servers
Batch
aggregation
Streaming aggregation of user 0Y p. views
with filtering

15. Problem 03 – errors in the past
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming aggregation of item 0X views
Streaming aggregation of phone views
Web-servers
Batch
Re-
aggregation
Streaming aggregation of user 0Y p. views
-wrong filter/wrong code/… some fail

16. Problem 04 – logic duplication
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming aggregation of item 0X views
Streaming aggregation of phone views
Web-servers
Batch
aggregation

17. Lambda as a solution
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming aggregation of item 0X views
Streaming aggregation of phone views
Web-servers
Batch
aggregation

18. Software/hardware of stat counter
• Speed layer:
• Redis ………… (but can be … Tarantool)
• 64 nodes master <-> 64 nodes slave
• Up to 1.3 Tb of RAM for master (2.6 Tb total )
• Start from 2, up to 8 servers
• Batch layer:
• Vertica …… (but can be … ClickHouse)
• Cluster of 14 servers, 512 GB Ram each.
• ~ 50 Tb of data

19. One more thing! –how to do filtering?
Filter non-human cookies/devices
In-memory storage of human cookies/devices
(Redis, Tarantool)

20. Lambda again! (lambda 2)
13:00 14:008:00 9:00 10:00 11:00 12:00 Processing
Time
Streaming checks of cookies/devices
Web-serversBatch
checks
of cookies/devices
In-memory storage of human cookies/devices
(Redis, Tarantool)

21. Software/hardware of white cookies storage
• Speed layer:
• Tarantool (hash index, much more efficient than Redis)
• 25Gb of RAM for master (50 Gb total )
• Batch layer:
• Vertica …… (you need heavy joins, no ClickHouse)
• Cluster of 14 servers, 512 GB Ram each.
• ~ 50 Tb of data
500 mln. of white cookie/devices

22. Conclusions - недостатки lambda
architecture
• Logic duplication:
• -> логика, дублируемая в speed layer, должна быть предельно простой
• -> логику лучше расширять не как монолит, а согласно микросервисной
архитектуре. Тогда можно «играть» базами.
• -> данные speed layer должны поддерживать полное перетирание из
batch layer
• -> batch layer должен поддерживать сложную логику (в идеале полный
SQL), чтобы компенсировать ограничения speed layer

23. Всем
спасибо!
Thanks!
谢谢Tack!