Документ описывает практическое применение ламбда архитектуры в проекте компании Idexx Laboratories для обработки больших объемов ветеринарных данных в реальном времени. Основное внимание уделяется использованию технологий, таких как Twitter Storm, Redis и Hadoop для достижения масштабируемости и надежности системы. В документе также упоминаются бизнес-цели, проблемы с данными и ключевые компоненты системы.

1. Ламбда Архитектура на Практике
Кирилл Алешин
IDEXX Laboratories
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

2. План Доклада
• Что такое Ламбда Архитектура?
• Описание проекта
• Характеристики масштабной аналитической системы
данных
• Суп технологий: Твиттер Сторм, Редис, Хадуп.
• Выученые уроки
• Ответы на вопросы
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

3. Ламбда Архитектура
• Инвентор – Натан Марц
(Твиттер)
• Обещание –
«неограниченная
масштабируемость данных
в реальном времени»
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

4. Copyright © 2013 Kyrill Alyoshin. All rights reserved.

5. Описание Проекта
• Несколько слов об Айдексе
• Глобальный лидер в ветеринарной сфере
• Рыночная капитализация - $5.5 млрд.
• Самые высокие расходы на R&D во всей вет. индустрии
– как реальные, так и пропорцианальные обороту
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

6. Описание Проекта
• Циклическое импортирование тысяч баз данных из
ветеринарных клиник в реальном времени
• Складирование этих данных в хорошо масштабируемой
системе
• Открытие центрального доступа к этим данным как
внутри, так и вне компании
• Научная аналитика
• ...и все это должно быть не сильно дорого 
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

7. Какие данные?
• Финансовые:
• Ветеринарные платежи
• Медицинские:
• Результаты лабораторных тестов
• Вакцинации
• Истории болезни
• Медицинский нарратив (неструктурированные данные)
• Общие:
• Клиентские визиты
• Напоминания о визитах
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

8. Бизнес Цели – Данные Это Продукт
• Сопоставление итогов маркетинговых компаний
• Определение характеристик лучших клиентов
• Упреждающая детекция эпидемий
• Превентивная медицина
• Перепродажа данных крупным фармацевтическим
компаниям
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

9. Проблемы...
• Импортируемые базы данных не позволяют определять
новые или измененные значения
• Каждая база данных должна обрабатываться каждый
раз заново
• ... четыре раза в день
• 10 тысяч баз данных х 4 раза в день = 1 база в 2
секунды
• Средняя база данных содержит в себе 4-5 млн рядов.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

10. Задачи
Наша система данных должна:
• Быстро сохранять и обрабатывать огромное количество данных
(масштабируемость).
• Делать это относительно недорого (стоимость).
• Быть настоящей системой данных – представлять данные на
протяжении всего временного континуума (особая модель
данных).
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

11. Фундаментальный принцип:
Неизменяемость (Immutability)
• Неизменяемые данные никогда не обновляются.
• Как следствие, неизменяемые системы данных
предствляют собой полнyю репрезентацию фактов на
временном континууме.
• Как следствие, неизменяемые системы данных гораздо
более устойчивы к человеческим ошибкам, так как
ошибочные данные могут быть просто удалены без
всяких усилий на восстановление правдивых значений.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

12. Пример: Изменяемые Данные
id
name
gender
color
species
1
Sam
male
brown
canine
2
Rover
male
yellow
canine
3
Fluffy
female
white
feline
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

13. Пример: Изменяемые Данные
id
name
gender
color
species
1
Sam
male
brown
canine
2
Rover
neutered male
yellow
canine
3
Fluffy
female
white
feline
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

14. Пример: Неизменяемые Данные
Name Data
id
1
2
3
name
Sam
Rover
Fluffy
Timestamp
4/3/2011 10:25:44
7/4/2010 16:35:20
10/12/2012 19:45:45
id
1
2
3
Sex Data
id
name
timestamp
1
Male
4/3/2011 10:25:44
2
Male
7/4/2010 16:35:20
3
Female
10/12/2012 19:45:45
Sex Data
id
name
timestamp
1
Male
4/3/2011 10:25:44
2
Male
7/4/2010 16:35:20
3
Female
10/12/2012 19:45:45
2
Neutered Male
04/02/2013 22:34:56
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Species Data
Species
timestamp
canine
4/3/2011 10:25:44
canine
7/4/2010 16:35:20
feline
10/12/2012 19:45:45

15. Еще раз о плюсах такой модели данных
• Позволяет осуществлять запрос в любой временной момент
• Толерантна к человеческой ошибке
• Фундаментальна столбчата – минимизирует усилия на чтение
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

16. Основные Компоненты
• Клиент для выкачивания данных из ветеринарных практик
• Твиттер Сторм – как высокоскорстная ETL система
• Редис – как высокоскоростная система фильтрации
• Хадуп – как аналитическая система
• Системы материализованных представлений – serving layer.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

17. Клиент для выкачки данных
• Софт, который устанавливается в клинике и:
• Переодически выкачивает все данные
• Сохраняет их в «облаке»
• Посылает сигнал готовности
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

18. Сторм – потоковая система обработки данных
• Любые потоковые вычисления
• Источником данных может быть что угодно: обычно
какая-то очередь.
• Ключевые абстракции (spouts and bolts)
конфигурируются в топологии и распределяются по
серверам (supervisors) и Ява процессам (workers).
• Легкая горизонтальная масштабируемость.
• Сторм предоставляет гарантированную доставку
данных. Akka, Erlang – отдыхают. 
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

19. Редис: фильтр для неизмененных рядов
• Для каждого ряда, который будет сохраняться в Хадупе,
мы сцепляем все значения в единую строку и
вычисляем ее 128 битный хэш.
• Этот хэш сохраняется в Редисе вместе с первичным
ключом каждого для каждого ряда.
• Точно также мы вычисляем этот хэш для каждого ряда
из пришедшей базы данных и сравниваем его со
значением в Редисе.
• Если оно одно и то же, то ряд отфильтровывается.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

20. Хадуп – Ключевые Идеи
• HDFS – данные сохраняются на распределенной
файловой системе.
• Код выполняется прямо на узлах данных (локальность).
• Распределение данных и кода автоматическое и
незаметное.
• Падение узлов незаметно для приложения.
• Масштабируемость достигается простым добавлением
узлов без остановки кластера.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

21. Уроки Хадупа: Часть 2
• Общая оркестровка рабочего процесса пока слаба –
используем Spring Batch.
• Если нужны быстрые результаты,то надо много узлов.
• Никогда не используйте MapReduce напрямую – пользуйтесь
высокоуровневыми библиотеками – Cascading, JCascalog –
особенно, когда данные структурированы.
• dfs-datastores – неплохая библиотека для прямого
складирования и чтения структурированных данных прямо на
HDFS.
• Легко интегрируется с S3, что позволяет использование
Amazon EMR, для особо тяжелых процессов.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

22. Как читать данные?
• Ламбда архитектура говорит, что они должны поставляться из
некоторого дополнительного уровня материализованных
представлений – the serving layer.
• Фактически это может быть что угодно. Основное требование –
скорость обновления и консистенция чтения на клиенте в момент
обновления.
• Можно делать и в реляционной базе данных через
материализованные представления (если обем данных не сильно
большой)
• Есть и специализированные базы данных: ElephantDB, Voldemort
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

23. Общие Заметки
• Твиттер Сторм оказался чрезвычайно стабильной системой –
работает фактически на автопилоте.
• Редис также невероятно стабильная высокоскоростная система.
Мы буквально не можем его перегрузить.
• Хадуп – требует заботы и внимания, но тем не менее легко
масштабируется и позволяет обрабатывать огромное колличество
данных.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

24. Реализованная Ламбда Архитектура
• Горизонтально масштабируемая система на всех уровнях.
• Неизменная модель данных, позволяющая любой уровень
аналитики данных.
• Поскольку данные никогда не удаляются (кроме человеческих
ошибок) и сохраняются «сырыми», то ошибки в анализе легко
исправляются – новый код и получите новое представление
данных (view) на уровне, на котором данные читаются.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

25. Вопросы Пожалуйста!
Кирилл Алешин
kyrill@alyoshin-consulting.com
Twitter: kyrill007
Copyright © 2013 Kyrill Alyoshin. All rights reserved.