Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

Проблемы с традиционными системами

“мы начинаем сITТенденция времениDTэпоха(данныеэпоха)。ITиDTмежду,Не просто технологические изменения,Это также смена идеологии.,ИТ в основном обслуживает себя,Используется для лучшего самоконтроля и управления.,DT активирует производительность,Пусть другие живут лучше, чем вы» — Джек Ма, председатель совета директоров Alibaba.

Объем данных перешел с уровня M на уровень G, а теперь на уровень T и уровень P. По мере изменения объема данных незаметно меняются и система управления данными (СУБД) и система хранилища данных (СХД).

При проектировании архитектуры системы данных традиционных приложений приложение напрямую обращается к системе базы данных. Когда количество посещений пользователей увеличивается, база данных не может поддерживать растущую нагрузку пользовательских запросов, в результате чего сервер базы данных не может своевременно отвечать на запросы пользователей и вызывает ошибку тайм-аута. После возникновения такой ситуации архитектура системы принимается, как показано на рисунке (A), и между базой данных и приложением создается уровень изоляции буфера, чтобы уменьшить нагрузку на чтение и запись в базу данных. Однако, когда количество посещений пользователей продолжает увеличиваться, необходимо рассмотреть архитектуру технологии разделения чтения и записи (главный-подчиненный), как показано на (B), а также технологию подбаз данных и подтаблиц. Теперь архитектура становится все более и более сложной, добавляя логику обработки, такую ​​как очереди, разделы и репликация. Приложениям необходимо понимать схему базы данных, чтобы получить доступ к правильным данным.

Рисунок (А)

Рисунок (Б)

Предыстория лямбда-архитектуры

Технологии обработки больших данных должны учитывать эту масштабируемость и сложность. Прежде всего, мы должны осознавать распределенный характер и хорошо обрабатывать секционирование и репликацию, чтобы не вызывать сбоев запросов из-за неправильного секционирования. Вместо этого мы должны внедрить эту логику в базу данных. Когда систему необходимо расширить, узлы можно очень легко добавить, а также систему можно перебалансировать для новых узлов. Второй — сделать данные неизменяемыми. Исходные данные никогда не могут быть изменены, поэтому даже если допущена ошибка и записаны неправильные данные, исходные хорошие данные не будут уничтожены.

Платформа обработки больших данных в реальном времени (Лямбда-архитектура), предложенная автором Storm Натаном Марцем, удовлетворяет двум вышеуказанным пунктам. Марц разработал знаменитую платформу обработки больших данных в реальном времени Storm, работая в Twitter. Лямбда-архитектура была усовершенствована на основе его многолетнего опыта работы с распределенными системами больших данных.

Цель Лямбда-архитектуры — разработать архитектуру, которая удовлетворяет ключевым характеристикам системы больших данных реального времени.,В том числе: высокая отказоустойчивость, низкая задержка и масштабируемость и т. д. Лямбда-архитектура объединяет офлайн-вычисления и вычисления в реальном времени.,Иммунитет,Ряд архитектурных принципов, таких как разделение чтения и записи и изоляция сложности.,Может быть интегрирован с Hadoop.,Kafka,Storm,Spark,Hbase и другие компоненты больших данных.

Ключевые характеристики систем больших данных

Марц представляет атрибуты, которыми может обладать система BigData:

a. Надежность и отказоустойчивость (отказоустойчивость и надежность): в крупномасштабных распределенных системах машины ненадежны и могут выйти из строя, но система должна быть надежной и вести себя правильно, даже если она сталкивается с машинными ошибками. Помимо машинных ошибок, люди чаще допускают ошибки. При разработке программного обеспечения неизбежно будут возникать некоторые ошибки, и система должна иметь достаточную адаптируемость к ошибочным данным, написанным программами с ошибками. Поэтому отказоустойчивость, которая более важна, чем отказоустойчивость машины, - это отказоустойчивость операций человека. В крупномасштабных распределенных системах ошибки человека и машины могут возникать каждый день. Особенно важно бороться с ошибками человека и машины, чтобы система могла быстро восстанавливаться после ошибок.

б) Чтение и обновление с низкой задержкой (низкая задержка). Многие приложения предъявляют очень высокие требования к задержке для операций чтения и записи и требуют малой задержки ответов на обновления и запросы.

в. Масштабируемость (горизонтальное расширение). Когда объем данных/нагрузки увеличивается, масштабируемая система поддерживает производительность за счет добавления дополнительных машинных ресурсов. То есть часто говорят, что система должна быть линейно масштабируемой, и вместо масштабирования (путем повышения производительности машины) обычно применяется масштабирование (путем увеличения количества машин).

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

e Расширяемость: когда необходимо добавить новые функции и возможности, расширяемая система может добавлять новые функции с минимальными затратами на разработку.

f. Позволяет выполнять специальные запросы: данные содержат ценность, и необходимо иметь возможность удобно и быстро запрашивать необходимые данные.

г. Минимальное обслуживание (простота обслуживания). Если система должна быть простой в обслуживании, ключевой момент — контролировать ее сложность. Чем сложнее система, тем более подвержена ошибкам и труднее ее поддерживать.

h. Возможность отладки (легкость отладки): при возникновении проблемы системе необходимо иметь достаточно информации для ее устранения и поиска основной причины проблемы. Ключевым моментом является возможность отслеживать источник каждой точки генерации данных.

Природа систем данных

Марц считает: Системы данных отвечают на вопросы, запрашивая прошлые (частичные или все) данные. Например: Какой он человек? Сколько у него друзей? Окупается ли этот счет? . Таким образом, общее определение DataSystem — это Query=Function(alldata). Разложив общее выражение, мы получаем: система данных = данные + запрос, благодаря чему мы можем понять суть системы больших данных с двух аспектов: данных и запроса.

данныесущность：When&What

Данные — это неделимая единица, и данные имеют две ключевые характеристики: когда и что.

Когда означает, что только данные связаны со временем, то есть данные генерируются в определенное время. Это очень важно. В базе данных с транзакционными характеристиками порядок операций имеет решающее значение для результата. Например, журнал Binlog базы данных. Таким образом, временная природа данных определяет глобальную последовательность появления данных и, следовательно, определяет результаты данных.

Чего только стоят сами данные. Поскольку данные относятся к определенному моменту времени, сами данные являются неизменяемыми (неизменяемыми). Прошлые данные стали фактом (Факт). Вы не можете вернуться к определенному моменту времени в прошлом, чтобы изменить факты данных. Это означает, что на самом деле с данными выполняются только две операции: чтение существующих данных и добавление новых данных. Используя нотацию базы данных, CRUD становится CR. Обновление и удаление — это, по сути, заново сгенерированная информация, которая записывается на языке C.

Хранение данных: StoreEverything Rawly и Immutable

На основании приведенного выше анализа характеристик данных метод, используемый для хранения данных в лямбда-архитектуре, следующий: данные неизменяемы, и все данные сохраняются.

Преимущества использования этих двух методов хранения:

а. Простой. Используя неизменяемую модель данных, при хранении данных вам нужно просто добавить данные в основной набор данных. По сравнению с использованием изменяемой модели данных для операций обновления данные обычно необходимо индексировать, чтобы можно было быстро найти обновляемые данные для операций обновления.

b. Устраняйте ошибки человека и машины. Люди и машины могут совершать ошибки каждый день. Чрезвычайно важно как справляться с ошибками людей и машин и обеспечивать быстрое восстановление системы данных. Неизменяемые и повторяемые вычисления — распространенные способы борьбы с человеческими и машинными ошибками. При использовании изменяемой модели данных данные, вызывающие ошибки, могут быть перезаписаны и потеряны. По сравнению с использованием неизменяемой модели данных, поскольку все данные присутствуют, там же находятся и данные, вызвавшие ошибку. Метод восстановления может заключаться в простом просмотре всех данных, хранящихся в наборе данных, удалении ошибочных данных и перерасчете представлений. Ключевым моментом пересчета является использование глобального порядка, определяемого временными характеристиками данных, и его повторное выполнение для получения правильного результата.

Сегодня в отрасли существует множество примеров использования неизменяемых моделей данных для хранения всех данных. Например, распределенная база данных Datomic хранит данные на основе неизменяемой модели данных, что упрощает проектирование. Промежуточное программное обеспечение распределенных сообщений Kafka основано на журнале и хранит сообщения только для добавления.

Лямбда-архитектура

Основная идея Лямбда-архитектура — структурировать большую систему данных на несколько уровней.,Это пакетный слой (batchlayer), Уровень обработки в реальном времени (speedlayer)、Serving Layer (сервировочный слой), например Рисунок (С).

В идеале любой доступ к данным должен осуществляться с помощью выражения Query= function(alldata) запускается. Однако, если данные достигают очень большого уровня (например, PB) и требуют поддержки запросов в реальном времени, они будут потреблять очень огромные ресурсы. Одним из решений является функция предварительно вычисленного запроса (precomputedquery funciton）。Эта функция запроса предварительного вычисления называется в книгеBatch View（A）,Таким образом, когда вам нужно выполнить запрос,Результаты можно прочитать из BatchView. Такое предварительно вычисленное представление может быть проиндексировано,Таким образом, может поддерживаться случайное чтение (B). Таким образом, система становится:

（A）batchview = function(all data)；

（B）query =function(batch view)。

Рисунок (С)

BatchLayer

существовать Лямбда-архитектурасередина,Внедрить (A) партию view =function(all data) называется BatchLayer. У него две обязанности:

a. Храните MasterDataset, который представляет собой неизмененный и постоянно растущий набор данных.

б. Предварительно вычислить этот набор основных данных.

Запуск функции запроса в режиме онлайн для всего набора данных слишком дорог для получения результатов, а обработка запроса занимает слишком много времени, что приводит к ухудшению пользовательского опыта. Если мы предварительно вычислим и сохраним предварительно вычисленные результаты в наборе данных, предварительно вычисленные результаты будут возвращены непосредственно при запросе без необходимости повторять трудоемкие вычисления. Очевидно, что пакетное представление — это процесс пакетной обработки, например, с использованием метода уменьшения карты, поддерживаемого Hadoop или Spark. Каждое рассчитанное таким образом представление поддерживает перерасчет, и результат каждого расчета один и тот же.

Рисунок (Д)

Понимание представления:

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

Batch Модель неизменяемых данных слоя и представления

Как показано на рисунке (E), агент (agentid=50023) имеет статус вызова в 10:00:06 и статус ожидания в 10:00:10. В традиционной конструкции базы данных записи, находящиеся непосредственно за ней, перезаписывают предыдущие записи. В неизменяемой модели данных исходные данные не будут изменены, но исторические записи будут изменены путем вставки записей модификации.

Рисунок (Е)

Упомянутое выше представление представляет собой связанное представление, предварительно рассчитанное на рисунке (E), например: количество всех онлайн-агентов на 21 июня 2016 г., количество онлайн-агентов для каждой горячей линии и компании. Результаты предварительно рассчитываются исходя из потребностей бизнеса. Этот процесс эквивалентен прикладному уровню традиционного моделирования хранилища данных. Прикладной уровень также представляет собой предварительно обработанное представление на основе бизнес-сценариев.

SpeedLayer

BatchLayer очень хорошо обрабатывает автономные данные, но во многих сценариях данные генерируются постоянно, а бизнес-сценарии требуют запросов в реальном времени. SpeedLayer предназначен для обработки дополнительных данных в реальном времени.

SpeedLayer похож на BatchLayer. Он рассчитывает данные и генерирует RealtimeView. Основное отличие:

a. Данные, обработанные SpeedLayer, представляют собой последний инкрементальный поток данных, а данные, обработанные BatchLayer, — это весь набор данных.

б. Для повышения эффективности SpeedLayer своевременно обновляет RealtimeView после получения новых данных, а BatchLayer напрямую получает BatchView на основе всех автономных данных. SpeedLayer — это инкрементальный расчет, а не повторный расчет.

c. SpeedLayer использует инкрементальные вычисления, поэтому задержка невелика, в то время как BatchLayer вычисляет весь набор данных, что занимает много времени.

Подводя итог, можно сказать, что SpeedLayer — это дополнение BatchLayer, работающее в режиме реального времени. Как показано на рисунке (F)

Фигура (F)

SpeedLayer можно резюмировать следующим образом: (C) RealtimeView = функция (RealtimeView, новые данные);

LambdaArchitecture разбивает обработку данных на BatchLayer и SpeedLayer и имеет следующие преимущества:

a. Отказоустойчивость: данные, обработанные в SpeedLayer, непрерывно записываются в BatchLayer. Если пересчитанный набор данных в BatchLayer содержит набор данных, обработанный SpeedLayer, текущий RealtimeView может быть отброшен. Это означает, что ошибки, возникшие при обработке SpeedLayer, не будут отражены. в BatchLayer Акт ремонта можно получить при перерасчете. Это также можно рассматривать как проявление эвентуальной непротиворечивости (Eventual Consistency) в теории CAP.

б. Изоляция сложности. BatchLayer обрабатывает автономные данные и легко контролируется. Speed ​​Layer использует инкрементные алгоритмы для обработки данных в реальном времени, и его сложность намного выше, чем Batch Layer. Разделив BatchLayer и Speed ​​Layer и изолировав сложность от Speed ​​Layer, можно значительно повысить надежность и надежность всей системы.

ServingLayer

BatchLayer получает BatchView, Speed ​​путем выполнения запроса к MasterDataset Layer предоставляет RealtimeView посредством инкрементальных вычислений. ServingLayer Лямбда-архитектуры используется для ответа на запросы пользователей и объединения BatchView и Realtime. Набор результирующих данных в View преобразуется в окончательный набор данных, как показано на рисунке (G). Таким образом, в обязанности ServingLayer входит:

а. Произвольный доступ к BatchView и RealTimeView.

б. Обновить BatchVeiw и RealTimeView и нести ответственность за объединение данных из них для предоставления пользователям единого интерфейса.

Фигура (Г)

Вкратце, ServingLayer представлен следующим уравнением (D): Query = функция (BatchViews, RealtimeView).

Выбор компонентов Лямбда-архитектура

На рисунке ниже показаны общие компоненты каждого компонента Лямбда-архитектуры в экосистеме больших данных и Alibaba Group. Хранилище dataStream использует Kafa, распределенную систему с неизменяемыми журналами.、TT、Metaq; набор данных BatchLayer хранится с использованием HDFS Hadoop или ODPS Alibaba Cloud; BatchView обрабатывается с помощью MapReduce; данные BatchView сохраняются с использованием Mysql (запрашивается небольшое количество данных последних результатов).、Hbase (запрос большого количества данных исторических результатов). SpeedLayer использует дополнительные данные для обработки Storm、Flink; инкрементальный набор данных результатов RealtimeView использует библиотеку данных Redis в памяти.

Фигура (Н)

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

Лямбда-архитектураоценка

преимущество:

а. Неизменяемость данных. Приведенная там модель передачи данных создает экземпляры данных на этапе инициализации, что может принести большую пользу. Он позволяет отслеживать большое количество заданий MapReduce, тем самым облегчая независимую отладку на разных этапах.

б. Подчеркнута проблема пересчета данных. Перерасчет при потоковой обработке является серьезной проблемой, но ее часто упускают из виду. Например, если выходные данные определенного рабочего процесса определяются входными, после изменения кода нам придется выполнить повторный расчет, чтобы проверить достоверность изменения. При каких обстоятельствах код будет изменен? Например, меняются требования, необходимо корректировать вычисляемые поля или программа выдает ошибку и ее необходимо отладить.

недостаток:

а Джей Крепс считает, что Lambda имеет присущие ей сложности разработки, эксплуатации и обслуживания. Lambda необходимо реализовать все алгоритмы дважды: один раз для системы пакетной обработки, а другой раз для системы реального времени. Также требуется, чтобы результаты запроса представляли собой объединение результатов двух систем.

Из-за вышеуказанных недостатков Джейкрепс из Linkedin предложил архитектуру Каппа, как показано на рисунке (I):

Картинка (Я)

1. Используйте Kafka или другие системы для регистрации данных, которые необходимо пересчитать, и предоставления их множеству подписчиков. Например, если нам нужно пересчитать данные в течение 30 дней, мы можем установить 30-дневное значение хранения данных в Kafka.

2. Когда требуется пересчет, запустите второй экземпляр задания потоковой обработки для обработки ранее полученных данных, а затем непосредственно поместите данные результата в новую таблицу вывода данных.

3. Когда задание будет завершено, позвольте приложению напрямую прочитать новую таблицу записей данных.

4. Остановите историческое задание и удалите старую таблицу вывода данных.

Архитектура Каппы еще не полностью изучена и не будет здесь оцениваться. Лично я считаю, что разные архитектуры данных имеют свои преимущества и недостатки. Когда мы их используем, мы можем только выбрать более подходящую архитектуру в зависимости от сценария приложения, чтобы максимизировать наши сильные стороны и избежать слабостей.

Ссылки:

Big Data:Principles and best practices of scalable real-time data systems——Nathan Marz

http://blog.csdn.net/brucesea/article/details/45937875

https://zhuanlan.zhihu.com/p/20510974

http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/152818.html Исходная ссылка: https://javaforall.cn