(lambda)-архитектура
Изобретатель --- Натон Марц, 2011 г.
(lambda)-архитектура предполагает, что данные проходят через две системы.
              ---------------
	    /|New data stream|\
            v ---------------  v
+------------+                 +------------------+
|Speed Layer |                 |Batch Layer       |
|  (STORM)   |                 |(_Hadoop_)        |
| ---------- |                 |                  |
||Stream    ||                 |    (All data)    |
||Processing||                 |         |        |
| ---------- |                 |         v        |
|     |      |                 |(Precompute Views)|
|     v      |                 +------+---------+-+
| ---------- |                        |         |
||Realtime  ||                 +------+---------+--------+
||View      ||                 |      v      ServingLayer|
| ---------- |                 |(Batch View) (Batch View)|
+------------+                 ^-------------------------+
              ^--[Query]------/
Speed Layer --- скоростной слой
Stream Processing --- обработка потока (данные находятся непродолжительное время (несколько часов), определённые функции над этими данными обрабатывают их в realtime-времени; данные хранятся либо в памяти, либо в промежуточной базе данных)
Batch Layer --- пакетный слой (данные обрабатываются по какой-то функции, MapReduce'ы обрабатывают эти данные, работают с этими данными и прогоняют функции, которые определены для работы с этими данными; результаты обработки сохраняются в ServingLayer)
Serving Layer --- уровень подачи данных, представления данных
Query --- запрос (может идти в обе подсистемы и результаты, которые возвращаются, должен соединить именно сам программный клиент)

(lambda)-архитектура предназначена для высокоскоростной обработки неограниченного количества данных.
Преимущества (lambda)-архитектуры:
 1) жёсткий акцент на неизменяемость входящих данных
 2) возможность анализа на протяжении всего временного интервала
 3) (lambda) акцентирована на сохранение "сырых" данных, что открывает возможность постоянного репроцессинга
Недостатки:
 1) огромная сложность и цена реализации (lambda)-архитектуры: логика работы всей системы распределена в разнородных системах, двойная кодировка всей логики системы
 2) проблемы PageLayer'а (пакетного уровня):
  а) данные складируются прямо на файловой системе HDFS в обыкновеных файлах (flat files) и, как следствие, появляется проблема: уменьшается эффективность работы Hadoop
   Плоский файл --- это набор функций к драйверу, который обеспечивает простейшие операции перемещения, записи в файл и извлечения из него
   в данном случае файлы образуют примитивную базу данных и работа с ними производится как с набором строк
   Shreding Process --- процесс пошагового измельчения данных, осуществляется через многошаговый MapReduce, однако в этом процессе принимает участие не только MapReduce, но и весь Hadoop. В результате работы этого процесса мы получаем огромное количество файлов, которое "не любит" экосистема Hadoop. После работы этого процесса возникает следующая проблема: измельчённые данные в маленьких файлах "абсорбируются" в уже существующие файлы в MasterDataSet на HDFS через отдельный MapReduce. Это вызывает цепочку проблем: в Hadoop данные являются неизменяемыми; в случае "абсорбации" (Consolidation Process) файлов они уже могут находиться в работе и читаться какими-то MapReduce'ами; выход --- эксклюзивный статус консолидатора (ему предоставляется информация о том, какие работы сейчас выполняются MapReduce'ом, и пока эти работы не закончатся --- другие работы не запускаются; нужно написать свой job scheduler); проблема складирования информации в плоских файлах: невозможность лёгкой коррекции данных: "плохие" плоские файлы обязательно попадут в MasterSet и возникает проблема того, как изменить эти данные в Hadoop, если данные в HDFS не изменяются; решение --- необходимо переписать файлы в новую директорию, убрав все "плохие" значения и потом переименовать её на месте старой с помощью команды `hadoop fs-cp /master-data-set /new-master-data-set`; эта операция может занять огромное количество времени (чтобы исправить одно значение, необходимо порядка 30 ч: 2-ТБ Хадуп-сервер (узел): теория --- 100 Mb/s=35 мин; практика --- 200 Mb/s=3h; онлайн --- 20 Mb/s=30h), при данной операции выполняется остановка рабочего кластера; в файловой системе HDFS отсутствуют индексы => отсутствует идемпотентность (независимость результата от прихода сообщений)
 3) проблемы уровня запросов (Query)
  а) обеспечение консистентности для запрашивающего клиента (поддержка консистентности клиентом означает то, что нельзя предоставить клиенту частичное представление (часть View), по факту не может быть удалён запрос, т. к. клиенты в данном случае могут оставаться в статусе подключённых клиентов), невозможно удалить запрос, т. к. некоторые клиенты могут быть ещё подключены к нему. Решение Натана --- ElephantDB
  б) отсутствие хорошей рабочей БД для уровня запросов (должна поддерживать консистентность клиента); решения --- использование HBase и MapR-DB; HBase поддерживает ключевое требование (lambda)-архитектуры --- неизменяемость данных, полностью избавляет от проблемы корректировки данных, предоставляет идемпотентность за счёт мгновеных запросов по rowKey-индексу; MapR-DB --- фирменная версия HBase, решает все описанные проблемы с уровнем запроса через т. н. snapshoting functionality: файловая система делится на файловые блоки и внутри системы происходит отслеживание того, какие блоки изменились; когда определяется команда snapshot, ни в один из определённых блоков писаться новые данные не будут и данные удаляются при создании нового View
  в) синхронизация данных разных уровней (SpeedLayer и BatchLayer)