17
технологических парадигм мира Big Data является распараллеливание
ввода/вывода (I/O) для повышения производительности.
Данные на нескольких узлах.
По определению большой данные – это данные, которые не могут быть
обработаны с использованием ресурсов одной машины. Одним из факторов
популярности Big Data послужило использование массово выпускаемых
вычислительных средств. Обычная массовая ЭВМ располагает диском 2–4 ТБ. Так
как на практике подход Big Data связан с обработкой гораздо больших выборок, то
данные будут распределены между несколькими узлами. Следует обратить
внимание, что не обязательно иметь в наличии десятки терабайт данных, чтобы
реализовать распределенную обработку на нескольких узлах. Большинство узлов
обрабатывают небольшую порцию данных локально. Так как в обработке данных
участвует большое количество узлов, то основная трудность – распределение
данных по узлам. Таким образом, даже набор в 500 ГБ будет распределяться по
нескольким узлам, даже если обработку такого небольшого набора данных
способна реализовать одна ЭВМ. Такое распределение преследует следующие
цели: 1) каждый блок данных реплицируются (распределяется) на более чем один
узел (фактор репликации в Hadoop по умолчанию равен 3). Это делает систему
более гибкой по отношению к сбоям. При сбое одного узла, другие узлы содержат
копии данных, размещенных на сбойном узле; 2) для параллельной обработки в
процессе участвуют несколько узлов. Таким образом, когда 50 ГБ данных
совместно обрабатываются на 10 узлах, каждый из которых реализует вычисления
на своем локальном наборе данных, может быть достигнуто улучшение
производительности в 5–10 раз. Может возникнуть вопрос о том, почему все
данные – не в сетевой файловой системе (NFS), где каждый узел может читать
свою часть данных. Ответ в том, что чтение с локального диска значительно
быстрее, чем чтение из сети. Системы Big Data нацелены на локальные
вычисления, потому что библиотеки приложений копируются на каждый узел
кластера перед запуском задания (экземпляр приложения). Эти процессы будут
рассмотрены в следующем подразделе.
Доставка приложений к данным.
18
Еще одни ключевой принцип Big Data. Для тех, кто хорошо знаком с
архитектурой корпоративных приложений Java EE, очевидны принципы
построения многоуровневых приложений. В трехуровневой модели
программирования данные обрабатываются централизовано на уровне
приложений; данные доставляются на уровень приложений с уровня данных по
сети. В рамках такого подхода общепринята централизованная обработка данных,
хотя сами данные могут быть распределены. В области Big Data такая загрузка сети
недопустима. Перемещение терабайт данных на уровне приложений будет
перегружать сеть и вести к появлению серьёзных недостатков, вплоть до сбоя
системы. В мире Big Data сами данные распределены по узлам, а приложение
доставляется к данным. Важно отметить, что подобный процесс технологически
реализуется очень сложно. Необходимо осуществить доставку не только
приложения к данным, но и всех библиотек. Если кластер имеет сотни узлов, то
легко понять, почему процесс обслуживания и развертывания становится очень
затратным. Поэтому системы Big Data проектируются для централизованного
развертывания кода, а сама система обладает механизмом для перемещения
программного кода на каждый узел кластера до начала выполнения задания.
Локальная обработка данных на узле кластера.
Эта особенность систем Big Data является естественным следствием
предыдущих двух. Все модели программирования в Big Data являются
ориентированными на распределенную и параллельную обработку. Сетевой
ввод/вывод происходит на порядок медленнее, чем ввод/вывод с использованием
локального диска. Так как данные были распространены по узлам, а библиотеки
приложений доставлены к данным, то основная цель заключается в реализации
локальной обработки. Несмотря на то, что обработка данных локально на узле
является предпочтительной, в системах Big Data не всегда удается реализовать
такое поведение. Правильнее говорить, что система Big Data планирует задания
таким образом, чтобы код приложения оказался как можно ближе к данным.
Некоторые решения предполагают выборки данных между узлами, по меньшей
мере, результатов с каждого узла (MapReduce). Передача небольшого объема
агрегированных данных оптимальна по сравнению с работой с исходным массивом
данных. Поэтому загрузка сети будет незначительна (но не всегда).
19
Последовательное чтение и прямой доступ.
Во-первых, необходимо определиться с механизмом чтения данных с диска.
Головка диска должна располагаться в месте физического расположения данных на
диске. Процесс позиционирования требует времени и известен как операция
поиска. Как только голова диска установила стартовую позицию, данные
считываются с диска последовательно. Это называется операцией передачи. Время
операции поиска составляет приблизительно 10 миллисекунд; время операции
передачи данных составляет порядка 20 миллисекунд (за 1 МБ). Это означает, что
при чтении 100 МБ данных фрагментами по 1 МБ из различных секций, весь
процесс займет 10 × 100 = 1 секунда (на поиск), 20 ×100 = 2 секунды (на передачу).
Таким образом, чтобы считать 100 МБ уйдет в общей сложности 3 секунды.
Однако, если 100 MB читаются последовательно с диска, то это займет 2,01 секунд.
Следует обратить внимание, что в расчетах использовались характеристики дисков
2009 года. Очевидно, что за прошедшие года они поменялись, но временные
пропорции остаются. Большинство моделей Big Data, ориентированы на
использование этой особенности. Данные последовательно считываются диска и
фильтруются в основной памяти. Для сравнения, обычные модели РСУБД
являются ориентированными на чтение с произвольным доступом. Пример.
Предположим, что вам необходимо получить общее количество продаж за 2000 год
в разрезе регионов, при этом данные о продажах распределяются случайным
образом на нескольких узлах.
Технология Big Data для достижения этой цели может быть реализована
несколькими этапами.
1. Каждый узел считывает все данные по продажам локально и производит
фильтрацию всех операций, оставляя только данные за 2000 год. Данные
распределяются случайным образом во всех узлах и считываются с диска
последовательного. Фильтрация происходит в основной памяти, чтобы избежать
расходов на время дискового поиска.
2. Каждый узел строит гистограмму продаж для каждого региона, добавляя в
выборку новый элемент-регион по мере его нахождения в исходных данных
(приложение присутствует на каждом узле и производит обработку локальных
данных).
20
3. Когда все узлы завершили процесс подсчета продаж для каждого региона, они
посылают соответствующий сигнал зарезервированному узлу (узел сборки),
который определяется предварительно перед началом вычислительного процесса.
4. Узел сборки получает данные о продажах от каждого узла и складывает
соответствующие значения, полученные от каждого узла для каждого региона.
5. Узел сборки выполняет сортировку полученной выборки по региону и отдает
результирующий набор.
Этот вычислительный процесс демонстрирует типичный принцип Big Data:
требование максимизации пропускной способности (объем работ за единицу
времени) превалирует над требованием минимизации латентности (как быстро
выполняется ответ на запрос).
1.2.2 Определение места проектируемой задачи в комплексе задач, ее описание
Для разработки каждого элемента AIS необходимо выполнение нескольких
технических операций. Каждая операция согласуется с исходными условия,
ограничениями, а в свою очередь выбранными средстави разработки, методологией
(рисунок №2).
Рисунок №2. Схема разработки элемента AIS.
Определим перечень ограничений в угоду данной системы.
Проектные ограничения по причине программному обеспечению
Проектные ограничения по причине информационному обеспечению
21
Проектные ограничения по причине техническому обеспечению
Проектные ограничения по причине технологическому обеспечению
Данные ограничения являются результатом исполнения требований по причине
этим видам обеспечения.
Проектные ограничения по причине программному обеспечению
Программная реализация AIS обязана отличатся надежностью.
Эффективным использованием системных ресурсов.
Обеспечивать безопасность хранимых данных
Проектные ограничения по причине информационному обеспечению
Информационное обеспечение рабочей станции должно включать машину с
установленной ОС семейства Windows NT. в угоду работы системы необходим
ODBC провайдер в угоду к записям.
Проектные ограничения по причине техническому обеспечению
Техническая составляющая обязана обеспечивать работоспособность по
причине из предыдущего пункта, соответствовать минимальным системным
условиям в угоду комфортной работы с записям ПО. Поскольку сама AIS является
не требовательной к системным ресурсам системные условия возможно оставить
на минимальном уровне в угоду ОС семейства Windows NT.
• Процессор Pentium на 133 МГц или же мощный (P5 или же совместимый).
Система Windows 2000 Professional может работать на компьютерах, до двух
процессоров.
• Минимально возможный объем ОЗУ 64Мбайт. Рекомендуется иметь не менее
256Мбайт ОЗУ.
• HDD емкостью 2Гбайт, имеющий не менее 650Мбайт свободного места.
• Монитор SVGA или же с высоким разрешением.
• Клавиатура. Мышь или же совместимое указывающее устройство.
• Устройство в угоду чтения компактдисков или же дисков DVD.
Проектные ограничения по причине технологическому обеспечению
Наибольшее число ошибок возникает в вводе данных в систему.
Человеческий фактор является наиболее уязвимым звеном в автоматизации бизнес-
процессов. в угоду предотвращения внесения ошибок существует проверка
22
вносимых данных на предмет соответствия типу, характеру данных, ожидаемых
системой. В ошибке вносимых данных или же невозможности исполнения
запрашиваемой операции система обязана сообщить причину, попытаться ее
устранить, если это возможно,, корректно продолжить работу.
1.2.3 Обоснование необходимости использования вычислительной техники в
угоду решения задачи
На современном этапе развития корпоративных информационных систем
(ИС) продолжаются поиски гибких методологий, процессов раз работки,
проектирования. Подобные технологии сами непрерывно эволюционируют, имеют
огромное значение в угоду бизнеса, государственных учреждений. Важнейшим
этапом проектирования ИС является создание своеобразной дорожной карты,
которая определяет приоритетные этапы реализации проекта, имеющие
критическое значение в угоду проекта в целом. Организации, успешно
разрабатывающие, проектирующие решения нового поколения в области IT,
следуют передовым методологиям проектирования, основываясь на собственном
опыте внедрения, развертывания ИС. Отдельные методологии проектирования ИС
будут рассмотрены в данном разделе. С другой стороны, предприятия,
использующие передовые технологии из области Big Data или же Internet of hings
(IoT) в рамках инициативных проектов, экспериментов или же тестовых заданий,
очень часто затрудняются обнаружить реальную выгоду ввиду подобных проектов
или же ввиду непосредственного внедрения новых решений. Многие пользователи
не должны выявить устойчивых связей промеж разрозненными условиями к
эффективности внутри предприятия. В таком условии передовые IT проекты рано
или же поздно достигают стадии, когда необходимо принять решение о
прекращении их финансирования или же о неприменимости подобных решений в
рамках конкретного предприятия. К сожалению, подобные ситуации встречается на
практике, но, они лишены своих положительных моментов. В данном разделе
учебного пособия мы рассмотрим передовые технологии Big Data, которые, в
общепринятом случае, включают технологии традиционных хранилищ,
основанных на реляционных системах руководства базами данных (РСУ БД),
23
кластерах Hadoop, базах данных NoSQL, прочих решениях в угоду руководства
данными. Эта модель, в соответствии с предлагаемой методикой, строится
следующим образом: в угоду выделенных ресурсов определяется их ценность, как
с точки зрения ассоциированных с ними возможных финансовых потерь, так, с
точки зрения ущерба репутации организации, дезорганизации ее деятельности,
нематериального ущерба ввиду разглашения конфиденциальной данных, т.д.
впоследствии описываются взаимосвязи ресурсов, рассчитываются угрозы
безопасности, оцениваются вероятности их реализации.
Развитие вычислительных технологий, стратегии их реализации
В начале данного раздела рассмотрим каким образом технологии больших
данных (Big Data) влились в исторический процесс развития информационных
технологий.
Начнем изложение со времени, когда подобные технологии даже не были
реализованы в виде проектов. На рисунке №3 демонстрируется схема,
отражающая эволюцию технологий обработки данных.
Рисунок №3 Эволюция технологий обработки данных
Краткая история. Существует много мнений о том, каким образом описывать
развитие вычислительных технологий. Данное историческое описание начинается
в то время, когда технологии уже вышли за рамки механических вычислителей.
Начнем с рассмотрения решений в угоду обработки данных, ориентированных на
24
предоставление данных в определенном формате. Многие считают, как основной
предпосылкой к появлению табличного формата данных, стало широ кое
распространение оборудования на перфокартах, предложенного Германом
Холлери. Первое применение подобной технологии было реализовано в
автоматизации переписи населения в США. Принципы организации данного
процесса были хорошо изучены, когда в 1880 г. Холлери пред ложил его решение.
Многие века государственные структуры произ водили накопление данных о
всевозможных аспектах жизни людей, в про цессе чего стала проявляться
структура массива данных, требуемая в угоду хранения, обработки данных,
содержащая следующие поля: имя гражданина, пол, адрес, возраст, собственность,
место рождения, уровень образования, т. д. Постепенное увеличение ключевых
показателей (KPI) с одновременным увеличение численности населения привели к
необходимости внедрения автоматизированного подхода к хранению, обработке
данных. Перфокарты Холлери обеспечивали подобную автоматизацию. В 1930 г.
данная технология стала популярной по причине всему миру, ши роко применялась
в угоду автоматизации всевозможных процессов во всех областях. В 1940 г., в
период Второй мировой войны, перед учеными встали сложные проблемы военной
направленности, связанные с ускорением вычислений. К подобным проблемам
относились шифрование, рас чет баллистических траекторий. Необходимость
автоматизации подобных решений привела к появлению электронно
вычислительных устройств, состоящих из переключателей, вакуумных трубок,
проводников, заключенных в шкафы, которые заполняли комнату или же даже
целое здание. впоследствии войны в исследованиях военной сферы стали по
причине являться компьютеры в угоду автоматизации коммерческих предприятий
в области финансов, др. Следующие десятилетия были связаны с развитием,
распространением современных операционных систем, программного обеспечения,
языков программирования (для упрощения, ускорения разработки приложений),
баз данных (для быстрого, простого хранения данных). Базы данных
эволюционировали ввиду иерархических к гибким реляционным, хранящим
данные в табличном виде. Таблицы связаны внешним ключом посредством
введения дублирующихся столбцов. Структурированный язык запросов (SQL)
вскоре стал стандартным средством доступа к реляционной базе данных. В начале
25
1970х годов разработка приложений была сфокусирована на обработке, построении
отчетов по причине часто изменяющимся дан ным; подобные технологии получили
название «оперативная обработка транзакций» (OLTP). Разработка программного
обеспечения была основана на предположении о необходимости достижения
ключевых бизнес показателей (показателей эффективности) или же об удовлетво
рении текущих экономических потребностей предприятия. Несмотря на то, как
транзисторы, интегральные микросхемы существенно увеличили эффективность
таких систем, цена вычислительных си стем, мэйнфреймов, программного
обеспечения оставалась слишком высокой, являлась основным сдерживающим
фактором развития IT. Ситуация изменилась с появлением дешевых миниЭВМ, а
затем персональных компьютеров в конце 1970х начале 1980х годов.
Электронные таблицы, реляционные базы данных сделали доступ ным
гибкий анализ данных, как привело к появлению систем поддержки принятия
решений. С течением времени данные стали распределенными, появлялось
понимание того, как различные подходы к сбору данных привели к
противоречивым результатам в области исследования данных. На современном
этапе развития технологий обработки данных возникла объективная
необходимость в новых под ходах к архитектуре информационных систем.
Хранилища данных. Билла Инмона часто называют человеком, который
первым предложил технологию «хранилище данных». Он описывал хранилище
данных как «предметно ориентированная, интегрированная, энергонезависимая,,
изменяемая во времени коллекция данных, предназначенная в угоду обеспечения
поддержки принятия решений». В начале 1990х, он разработал концепцию
корпоративного хранилища данных (КХД). Корпоративное хранилище
рассматривалось как централизованное решение в угоду всех исторических данных
в угоду компании. КХД представлено моделью данных в третьей нормальной
форме (3НФ), где все атрибуты являются атомарными, содержат уни кальные
значения. Аналогичные схемы использовались в базах данных OLTP. Рисунок №4
демонстрирует небольшой фрагмент модели в третьей нор мальной форме в угоду
информационного хранилища компании по причине про даже авиабилетов.
26
Рисунок №4. Схема третьей нормальной форме
Очевидно, как такая схема позволяет анализировать независимо транзакции
отдельного покупателя, статистику мест (seat), статистику сегментов, цен, скидки в
угоду постоянных клиентов. В КХД загружаются данные из таблиц OLTPсистемы
через пред варительные подсистемы преобразования. Преобразование
используются в угоду обеспечения согласованности данных в их извлечении из
источников различного типа, а в свою очередь в угоду обеспечения поддержки
бизнесправил качества данных, стандартов. В первых хранилищах процессы
извлечения, преобразования, загрузки данных промеж источниками, целевым
хранилищем, часто выполнялась на регулярной базе (еженедельно, ежемесячно) в
пакетном режиме. Но из за потребности бизнеса видеть изменяющиеся данные в
режиме реального времени наблюдалась тенденция к все частой загрузке данных в
хранили ща. Современные технологии обеспечивают загрузку данных в непре
рывном режиме, без задержек (наличие задержки может быть связано со сложными
алгоритмами преобразования данных). Многие организации обнаружили, как
единственный способ уменьшения задержки, вызванной преобразованием данных,
это применение жестких правил к данным в первичных OLTPсистемах. Этим
обеспечивается качество, согласованность данных источника, а в свою очередь
уменьшается сложность процедур преобразования. Изначально большинство
практических решений были ориентированы на сбор всех данных, которые могли
быть размещены в хранилище, полагая, как бизнесаналитики должны определить,
как с ней делать впоследствии. Такой подход часто приводит к негативным
последствиям, когда бизнесаналитики не могли легко манипулировать
необходимыми данными. Многие бизнесаналитики просто выгружали данные из
корпоративных хранилищ в электронные таблицы, уже впоследствии обрабатывали