В какой архитектуре пользователь для обработки получает файлы таблицы базы данных
Обновлено: 04.07.2024
Архитектура для обработки больших данных позволяет принимать, обрабатывать и анализировать данные, которые являются слишком объемными или слишком сложными для традиционных систем баз данных. Время, когда организации начинают использовать большие данные, зависит от возможностей пользователей и их средств. Для некоторых это могут быть сотни гигабайт данных, а для других — сотни терабайт. По мере совершенствования средств для работы с большими наборами данных изменяется и значение больших данных. Зачастую этот термин связан со значением, которое можно извлечь из наборов данных с помощью расширенной аналитики, а не исключительно с размером данных. Хотя в этих случаях они обычно достаточно большие.
С годами ландшафт данных изменился. Кроме того, появились новые возможности для работы с данными. Стоимость хранилища значительно снизилась, в то время как стоимость средств для сбора данных продолжает расти. Некоторые данные поступают в ускоренном темпе, их постоянно нужно собирать и просматривать. Другие данные поступают более медленно, но в очень больших блоках. Они часто содержат данные журналов за десятилетия. Вы может сталкиваться c проблемой расширенной аналитики или проблемой, для решения которой требуется использовать машинное обучение. Это задачи, которые архитектура для обработки больших данных предназначена решить.
Решения для обработки больших данных обычно предназначены для одного или нескольких из следующих типов рабочей нагрузки:
- пакетная обработка источников неактивных больших данных;
- обработка больших данных в динамике в режиме реального времени;
- интерактивное изучение больших данных;
- прогнозная аналитика и машинное обучение.
Используйте архитектуру для обработки больших данных для следующих сценариев:
- хранение и обработка данных в объемах, слишком больших для традиционной базы данных.
- преобразование неструктурированных данных для анализа и создания отчетов;
- запись, обработка и анализ непривязанных потоков данных в режиме реального времени или с низкой задержкой;
Компоненты архитектуры для обработки больших данных
На схеме ниже показаны логические компоненты, которые входят в архитектуру для обработки больших данных. Отдельные решения могут не содержать все компоненты в этой схеме.
Большинство архитектур для обработки больших данных включают некоторые или все перечисленные ниже компоненты.
Источники данных. Все решения для обработки больших данных начинаются с одного или нескольких источников данных. Примеры приведены ниже:
- Хранилища данных приложений, например реляционные базы данных.
- Статические файлы, которые создаются приложениями, например файлы журнала веб-сервера.
- Источники данных с передачей в режиме реального времени, например устройства Интернета вещей.
Хранилище данных. Данные для пакетной обработки обычно хранятся в распределенном хранилище файлов, где могут содержаться значительные объемы больших файлов в различных форматах. Этот тип хранилища часто называют озером данных. Такое хранилище можно реализовать с помощью Azure Data Lake Store или контейнеров больших двоичных объектов в службе хранилища Azure.
Пакетная обработка. Так как наборы данных очень велики, часто в решении обрабатываются длительные пакетные задания. Для них выполняется фильтрация, статистическая обработка и другие процессы подготовки данных к анализу. Обычно в эти задания входит чтение исходных файлов, их обработка и запись выходных данных в новые файлы. Варианты: выполнение заданий U-SQL в Azure Data Lake Analytics, использование пользовательских заданий Hive, Pig или Map/Reduce в кластере HDInsight Hadoop и применение программ Java, Scala или Python в кластере HDInsight Spark.
Хранилище аналитических данных. Во многих решениях для обработки больших данных данные подготавливаются к анализу. Затем обработанные данные структурируются в соответствии с форматом запросов для средств аналитики. Хранилище аналитических данных, используемое для обработки таких запросов, может быть реляционной базой данных типа Kimball, как можно увидеть в большинстве традиционных решений бизнес-аналитики (BI). Кроме того, данные можно представить с помощью технологии NoSQL с низкой задержкой, такой как HBase или интерактивная база данных Hive, которая предоставляет абстракцию метаданных для файлов данных в распределенном хранилище. Azure Synapse Analytics — это управляемая служба для хранения больших объемов данных в облаке. HDInsight поддерживает Interactive Hive, HBase и Spark SQL, которые также можно использовать, чтобы предоставлять данные для анализа.
Анализ и создание отчетов. Большинство решений по обработке больших данных предназначены для анализа и составления отчетов, что позволяет получить важную информацию. Чтобы расширить возможности анализа данных, можно включить в архитектуру слой моделирования, например модель таблицы или многомерного куба OLAP в Azure Analysis Services. Также можно включить поддержку самостоятельной бизнес-аналитики с использованием технологий моделирования и визуализации в Microsoft Power BI или Microsoft Excel. Анализ и создание отчетов также может выполняться путем интерактивного изучения данных специалистами по их анализу и обработке. Для таких сценариев многие службы Azure поддерживают функции аналитического блокнота, например Jupyter, который позволяет пользователям применять свои навыки работы с Python или R. Для крупномасштабного изучения данных можно использовать Microsoft R Server (отдельно или со Spark).
Оркестрация. Большинство решений для обработки больших данных состоят из повторяющихся рабочих процессов, во время которых преобразуются исходные данные, данные перемещаются между несколькими источниками и приемниками, обработанные данные загружаются в хранилища аналитических данных либо же результаты передаются непосредственно в отчет или на панель мониторинга. Чтобы автоматизировать эти рабочие процессы, вы можете использовать технологию оркестрации, такую как фабрика данных Azure или Apache Oozie и Sqoop.
Лямбда-архитектура
При работе с очень большими наборами данных выполнение типа запросов, необходимых клиентам, может занять много времени. Эти запросы нельзя выполнить в режиме реального времени. Они часто требуют алгоритмов, например MapReduce, которые работают параллельно по всему набору данных. Результаты затем сохраняются отдельно от необработанных данных и используются для выполнения запросов.
Недостатком этого подхода является то, что появляется задержка. Если обработка занимает несколько часов, запрос может возвращать результаты, которые были актуальными несколько часов назад. В идеале вам следует получить некоторые результаты в режиме реального времени (возможно, с некоторой потерей точности) и объединить их с результатами пакетной аналитики.
Лямбда-архитектура, впервые предложенная Натаном Марцом (Nathan Marz), устраняет эту проблему путем создания двух путей для потока данных. Все данные, поступающие в систему, проходят через эти два пути:
На пакетном уровне (холодный путь) все входящие данные хранятся в необработанном виде и выполняется их пакетная обработка. Результаты этой обработки сохраняются в пакетном представлении.
На уровне ускорения (критический путь) данные анализируются в режиме реального времени. Этот уровень обеспечивает минимальную задержку, хотя и за счет точности.
Пакетный уровень предоставляет результаты для уровня обслуживания, который индексирует пакетное представление для эффективного выполнения запросов. Уровень ускорения обновляет уровень обслуживания, отправляя добавочные обновления (с учетом последних данных).
Данные, которые поступают в критический путь, ограничены требованиями к задержке, наложенными уровнем ускорения, чтобы их можно было обработать как можно быстрее. Часто в этом случае следует обеспечить компромисс: некоторая потеря точности в пользу получения готовых данных как можно быстрее. Например, рассмотрите сценарий Интернета вещей, где большое количество датчиков температуры отправляют данные телеметрии. Уровень ускорения можно использовать для обработки скользящего временного окна входных данных.
На данные, которые поступают в холодный путь, с другой стороны, не распространяются те же требования к низкой задержке. Это обеспечивает высокую точность вычисления больших наборов данных, однако занимает много времени.
В результате критический и холодный пути объединяются в клиентском приложении аналитики. Если клиент должен отображать результаты своевременно, но потенциально с менее точными данными в режиме реального времени, он будет получать результаты из критического пути. В противном случае он будет выбирать результаты из холодного пути, чтобы отображать более точные данные, однако не так своевременно. Другими словами, критический путь содержит данные за относительно небольшой промежуток времени, после которого результаты можно обновить более точными данными из критического пути.
Каппа-архитектура
Недостатком лямбда-архитектуры является ее сложность. Логика обработки применяется в двух различных местах, в холодном и критическом путях, с использованием различных структур. Это приводит к дублированию логики вычислений и усложняет управление архитектурой для обоих путей.
Каппа-архитектура была предложена Джеем Крепсом (Jay Kreps) в качестве альтернативы лямбда-архитектуре. Она имеет такие же основные цели, что и лямбда-архитектура, но при этом есть важное различие: все данные проходят через один путь с использованием системы обработки потоковых данных.
Имеется некоторое сходство с пакетным уровнем лямбда-архитектуры. Оно заключается в том, что данные являются неизменяемыми. Кроме того, собираются все данные, а не только их подмножество. Данные принимаются как поток событий в распределенном и отказоустойчивом едином журнале. Эти события упорядочиваются, и текущее состояние события изменяется только при добавлении нового события. Аналогично уровню ускорения лямбда-архитектуры вся обработка событий выполняется во входном потоке и сохраняется как представление в режиме реального времени.
Если необходимо повторно вычислить весь набор данных (аналогично тому, что происходит на пакетном уровне в лямбда-архитектуре), просто воспроизведите поток. Чтобы завершить вычисление вовремя, обычно используется параллелизм.
Интернет вещей.
С практической точки зрения Интернет вещей представляет все устройства, подключенные к Интернету. Сюда входят ПК, мобильный телефон, умные часы, умный термостат, умный холодильник, подключенный автомобиль, импланты для кардиомониторинга и все остальные устройства, которые подключены к Интернету и отправляют или получают данные. Количество подключенных устройств растет каждый день, как и объем собираемых с них данных. Часто эти данные собираются в среды с большим количеством ограничений, а иногда и с высокой задержкой. В других случаях данные отправляются из сред с малой задержкой тысячами или миллионами устройств, требуя возможности быстро принимать данные и обрабатывать их соответствующим образом. Таким образом, чтобы работать с этими ограничениями и уникальными требованиями, требуется продуманное планирование.
Управляемые событиями архитектуры очень удобны при работе с решениями Интернета вещей. На следующей схеме представлены возможные варианты логической архитектуры для Интернета вещей. Особое внимание в этой схеме уделяется компонентам архитектуры для потоковой передачи событий.
Устройства могут отправлять события в облачный шлюз напрямую или через полевой шлюз. Полевой шлюз — это специальное устройство или программа, обычно размещаемые рядом с устройствами, которые получают события и пересылают их в облачный шлюз. Полевой шлюз может выполнять некоторую предварительную обработку событий, собираемых с устройств, например фильтрацию, статистическую обработку или преобразование протоколов.
Полученные события проходят через один или несколько обработчиков потока, которые передают данные в другие системы (например, хранилище данных) или выполняют аналитическую или другую обработку.
Ниже приводятся примеры типичных процессов обработки. (Очевидно, что этот список не является исчерпывающим.)
Сохранение данных о событиях в "холодное" хранилище для архивации или пакетной аналитики.
Аналитика критического пути, то есть анализ потока событий почти в режиме реального времени для обнаружения аномалий, выявления закономерностей в скользящих диапазонах времени или создания оповещений при выполнении определенных условий в потоке.
Серые блоки обозначают компоненты системы Интернета вещей, не связанные напрямую с потоковой передачей событий. Они включены в схему для полноты представления.
Реестр устройств — это база данных о подготовленных устройствах, которая содержит идентификаторы устройств и некоторые метаданные, например расположение.
API подготовки — это общий внешний интерфейс для подготовки и регистрации новых устройств.
Дополнительные сведения об Интернете вещей в Azure см. в статье об эталонной архитектуре Интернета вещей Microsoft Azure.
Экономические информационные системы имеют различную информационно-технологическую архитектуру, зависящую от используемых программных и технических средств, типа сетей и организации баз данных. Архитектура ИС, в свою очередь, влияет на параметры ИС:
· время выполнения одиночного запроса;
· производительность ИС (количество транзакций в единицу времени);
· стоимость создания, эксплуатации и развития ИС.
К основным видам архитектур ИС относят следующие:
· централизованная обработка данных;
Централизованная обработка данных
Централизованная обработка данных на локальном имеет следующие особенности:
1 На одном компьютере функционируют: программные средства пользовательского интерфейса, обеспечивающие интерактивный режим работы пользователя; программные средства приложений, выполняющие содержательную обработку данных; БД.
2 Развитие ИС ограничено:
· техническими параметрами центрального компьютера: объем оперативной памяти, объем дисковой памяти для БД, надежность работы компьютера и программного обеспечения;
· производительностью центрального компьютера, влияющей на своевременность обработки всех приложений.
Рис. 5.1. ИС с архитектурой централизованной обработки данных
Архитектура «Файл-сервер»
ИС с распределенной обработкой данных типа «файл-сервер» использует компьютерные сети, как правило, локального типа. Компьютеры в сети делятся на рабочие станции и серверы. На рабочей станции установлены программные средства пользовательского интерфейса, программные средства приложений, выполняющие содержательную обработку данных. На файловом сервере находится БД.
· обмен на уровне файлов, доступ к которым в режиме корректировки блокируется для других пользователей;
· перегрузка трафика сети;
· высокие требования к техническому оснащению рабочих станций, на которых выполняется содержательная обработка данных.
Рис. 5.2. ИС с архитектурой «файл-сервер»
Двухуровневый «Клиент-сервер»
В отличие от ранее рассмотренной архитектуры, распределенная обработка данных типа «двухуровневый клиент-сервер» предполагает, что на сервере находится БД под управлением СУБД в архитектуре «клиент-сервер».
Все рабочие станции (клиенты) посылают запросы на данные к серверу, который осуществляет извлечение и предварительную обработку данных.
Единицей обмена по сети является запрос и релевантная запросу выборка данных из БД. Существенно уменьшается трафик сети, снимаются ограничения на доступность данных БД различным приложениям.
«Клиентская» часть приложений становится несколько облегченной, но в больших ИС со сложной логикой обработки данных возникает проблема "толстого" клиента. Рабочая станция должна иметь достаточно высокие технические параметры для выполнения сложных приложений. Недостатком архитектуры является наличие очень высоких требований к техническому комплексу сервера БД, который становится центральным звеном всей ИС и определяет ее надежность.
Рис. 5.3. ИС с архитектурой «двухуровневый клиент-сервер»
Многоуровневый «Клиент-сервер»
На рабочей станции установлены только программные средства, поддерживающие интерфейс с БД. На сервере БД находятся БД под управлением СУБД, архитектура сети – «клиент-сервер». В архитектуре ИС выделен сервер приложений, на котором находятся программные средства общего пользования. Эти серверы выполняют всю содержательную обработку данных.
В отличие от двухуровневой архитектуры, данная архитектура обеспечивает эффективное использование приложений общего пользования многими клиентами. Клиенты преобразуются в "тонких" клиентов, при этом снижаются требования к оборудованию рабочих станций. Если серверов приложений и БД в сети несколько, архитектура ИС становится многоуровневой клиент-серверной архитектурой. Наличие самостоятельных уровней в информационно-технологической архитектуре ИС дает возможность варьировать аппаратными и программными средствами: выбирать операционные системы, СУБД, интерфейсы конечных пользователей, типы серверов и рабочих станций.
Рис. 5.4. ИС с архитектурой "трехуровневый клиент-сервер"
При построении больших ИС актуальна проблема создания распределенных систем обработки данных на основе интеграции неоднородных аппаратно-программных платформ. Многоуровневая архитектура ИС обеспечивает изоляцию параллельно работающих процессов, в результате ошибки в работе одной программы не влияют на работу других программ либо операционной системы. Компьютерные сети могут включать отдельные сегменты, для связи которых используются стандартные протоколы. Для БД осуществляется администрирование, регистрация каждого имевшего место доступа к базе данных и выполненных изменений в специальном журнале БД. Как правило, для больших БД создаются страховые копии, осуществляется «зеркализация» дисков.
Проблемой многопользовательского доступа являлось обеспечение согласованной работы многих клиентов с одними данными, т. е. обеспечение целостности базы данных. При совместной работе нескольких пользователей с данными, может быть нарушена целостность данных, т.е. при обращении нескольких пользователей к одним и тем же данным содержание записи становится неопределенным. Для решения проблемы сохранения целостности существуют следующие архитектуры.
Рис.1. Архитектура хост/терминал.
На рис.1 показана традиционная архитектура баз данных. При подобной архитектуре и СУБД, и физические данные размещаются на центральном компьютере (хост компьютере)вместе с приложением, принимающим входную информацию с пользовательского терминала (устройство ввода-вывода) и отображающим данные на экране пользователя. Для каждого терминала запускается своя копия приложения(процесс) которая обращается с базой данных. Приложение и СУБД работают на одном компьютере, и поскольку система обслуживает много различных пользователей, каждый из них ощущает снижение быстродействия по мере увеличения нагрузки на систему.
Преимущества: дешевые терминалы, невысокая загрузка сети (трафик), эффективнее решается проблема целостности.
Недостатки: мощность ограничена хостом, если в качестве терминала используются персональные компьютеры,то их ресурсы не используются.
Данная архитектура применима для больших и очень больших корпоративных сетей, построенных, как правило, на базе ОС Unix
Архитектура файл/сервер.
Появление персональных компьютеров и локальных вычислительных сетей привело к разработке архитектуры файл/сервер. При такой архитектуре приложение, выполняемое на персональном компьютере, может получить “прозрачный” доступ к файл-серверу, на котором хранятся совместно используемые файлы. Когда приложению, работающему на ПК, требуется данные из совместно используемого файла, сетевое программное обеспечение автоматически считывает требуемый блок данных с сервера. В этой архитектуре мы имеем дело с файловым сервером. В данной архитектуре вопросами целостности должно заниматься каждое приложение.
Преимущества: простота. Малая стоимость.
Недостатки:низкая надежность и малое количество клиентов,вопросы целостности возлагаются на клиентские приложения.
Данная архитектура применяется в простых коробчатых вариантах программного обеспечения (Например, 1:C).
В настоящее время на рынке наиболее популярными СУБД, которые применяют данную архитектуру, являются такие продукты, как FoxPro,DBase,Paradox,Access.
Архитектура клиент/сервер.
Рис.3. Архитектура клиент/сервер.
При такой архитектуре персональные компьютеры объединены в локальную сеть, в которой имеется сервер содержащий общие базы данных. В этой архитектуре мы имеем дело с сервером баз данных. Функции СУБД разделены на две части. Пользователь формирует запрос к БД. При помощи клиентской части СУБД запрос передается к серверу БД (ядро СУБД). Сервер БД выполняет запрос и при необходимости возвращает результат запроса клиенту. Пользовательские запросы объединяются в транзакции. Транзакция - логически связанная последовательность трансляции данных (запросов). Средством написания запросов является языкSQL, который является стандартным языком, обеспечивающим взаимодействие между клиентскими приложениями. Синтаксис и правила выполнения запросовSQL стандартизированы. В настоящее время этим занимается американский национальный институт стандартизацииANSI.Помимо стандартных возможностей каждый производитель СУБД может расширять свою версиюSQL дополнительными возможностями, которые впоследствии могут стать частью стандарта.
Преимущества: использование ресурса, как клиента, так и сервера.
Недостатки: при очень большой загрузке (при высоком трафике) падает производительность.
Данная архитектура применяется в масштабе предприятия.
В настоящее время на рынке имеются огромное количество СУБД, применяющих данную архитектуру. Перечислим наиболее популярные: ORACLE, Sy Base, MS SQL, InterBase.
Исторически первыми появились информационные системы с использованием файл-сервера. Файл-сервер только извлекает данные из файла (файлов) базы данных и передает их клиенту для дальнейшей обработки (рис. 1.1).
В процессе работы из базы данных клиенту передаются большие объемы информации. Значительный сетевой трафик иногда особенно сильно сказывается при одновременной работе даже уже нескольких клиентов, например вы скачиваете игры на Андроид Fruit Ninja или другие приложения. В файл-серверной архитектуре всегда передаются избыточные данные. Неважно, сколько записей из базы данных нужны клиенту — файлы базы данных передаются в самом общем случае целиком. Что касается MS Access, то нагрузку на сеть добавляют еще и объекты приложения, такие как формы, отчеты и т. д. Они вместе с данными хранятся в одном файле на компьютере-сервере.
Рис. 1.1. Структура информационной системы с файл-сервером
В MS Access 2010 у разработчика имеется возможность разделить данные и приложение, работающее с этими данными. В этом случае приложение тиражируется на компьютерах-клиентах, а база данных остается на компьютере-сервере.
Информационные системы с клиент-серверной архитектурой позволяют избежать проблем файл-серверных приложений. При такой архитектуре сервер базы данных, расположенный на компьютере-сервере, обеспечивает выполнение основного объема обработки данных. Клиентское приложение формирует запросы к серверу базы данных, как правило, в виде инструкций языка SQL. Сервер извлекает из базы запрошенные данные и передает на компьютер клиента. Главное достоинство такого подхода — значительно меньший объем передаваемых данных.
Рис. 1.2. Структура информационной системы с сервером базы данных
Обеспечение безопасности данных — очень важная функция для успешной работы информационной системы. Если у базы данных слабая система безопасности, любой достаточно подготовленный пользователь может нанести серьезный ущерб работе предприятия. Следует отметить, что защита данных в файл-серверной информационной системе изначально не может быть обеспечена на должном уровне.
Читайте также: