Хотя работа по анализу данных скрыта за бизнес-системой, она играет очень важную роль, а результаты анализа данных играют ключевую роль в принятии решений и развитии бизнеса. С развитием технологии больших данных все чаще и чаще используются такие термины, как интеллектуальный анализ данных и исследование данных.Для анализа данных на основе системы BI уже существуют очень зрелые и стабильные технические решения и экосистемы.Для системы BI , общая схема архитектуры выглядит следующим образом:
Видно, что в системе BI основным модулем является куб, который представляет собой абстракцию бизнес-модели более высокого уровня.На кубе могут выполняться различные операции, такие как детализация, детализация и нарезка. Большинство систем BI основаны на реляционных базах данных, а реляционные базы данных используют операторы SQL для операций, но SQL относительно слаб для выражения многомерных операций и анализа, поэтому Cube имеет свой собственный уникальный язык запросов MDX, а выражения MDX имеют более сильные многомерные выражения. Возможности размерной производительности, поэтому система анализа с кубом в качестве ядра в основном занимает половину статистического анализа данных.Большинство поставщиков услуг баз данных напрямую предоставляют программные услуги пакета BI, и систему анализа Olap легко построить. Однако проблемы BI постепенно выявлялись с течением времени:
- Система BI в основном фокусируется на структурированных данных с высокой плотностью и высокой ценностью, генерируемых путем анализа бизнес-данных, и очень слаба в обработке неструктурированных и полуструктурированных данных, таких как хранение и анализ изображений, текстов и аудио.
- Поскольку хранилище данных является структурированным хранилищем, когда данные поступают в хранилище данных из других систем, мы обычно называем это процессом ETL. Действия ETL тесно связаны с бизнесом. Обычно для связи с бизнесом и принятия решений требуется специальная команда ETL. как очистить и преобразовать данные.
- С увеличением разнородных источников данных, например, если есть такие источники данных, как видео, текст и изображения, для анализа содержимого данных и входа в хранилище данных требуется очень сложная программа ETL, в результате чего ETL становится слишком большим. и раздутый.
- Когда объем данных слишком велик, производительность станет узким местом, и будет очевидна проблема с объемом данных на уровне ТБ/ПБ.
- Ограничения, такие как парадигмы базы данных, сосредоточены на решении проблемы избыточности данных, чтобы обеспечить согласованность данных, но для хранилищ данных нам не нужно изменять данные и обеспечивать согласованность.В принципе, хранилища данных Необработанные данные доступны только для чтения, поэтому эти ограничения могут быть фактором производительности.
- Предварительное предположение и обработка данных действием ETL приводит к тому, что данные, полученные частью машинного обучения, являются гипотетическими данными, поэтому эффект не идеален. Например, если хранилище данных необходимо использовать для аномального интеллектуального анализа данных, необходимо четко определить характерные данные, которые необходимо извлечь, когда данные хранятся в базе данных через ETL, иначе они не могут быть структурированы в базу данных. в большинстве случаев его нужно извлекать на основе разнородных данных.
В условиях ряда проблем платформа анализа больших данных, возглавляемая системой Hadoop, постепенно демонстрировала свое превосходство, и экосистема вокруг системы Hadoop также продолжала расти, что позволило системе Hadoop в корне решить узкое место традиционных хранилищ данных. ., но это также приносит ряд проблем:
- Переход от хранилища данных к архитектуре больших данных не происходит плавно, что в основном означает отмену и переделывание.
- Распределенное хранилище в условиях больших данных подчеркивает доступность данных только для чтения, поэтому, как и Hive, HDFS не поддерживает обновление, а HDFS не поддерживает параллельные операции записи, что приводит к определенным ограничениям.
Платформа анализа данных, основанная на архитектуре больших данных, направлена на устранение узких мест, с которыми сталкиваются традиционные хранилища данных для анализа данных по следующим параметрам:
- Распределенных вычислений:Идея распределенных вычислений состоит в том, чтобы позволить нескольким узлам выполнять параллельные вычисления, а также максимально подчеркнуть локальность данных и сократить передачу данных.Например, Spark выражает логику вычисления данных в виде RDD, а ряд оптимизаций можно сделать на RDD, чтобы уменьшить передачу данных.
- Распределенное хранилище:Так называемое распределенное хранилище относится к разбиению большого файла на N копий, каждая из которых независимо размещается на машине.Это включает в себя копирование файлов, сегментирование и операции управления.Распределенное хранилище в основном Оптимизированные действия все в этом.
- Сочетание поиска и хранения:В ранних компонентах больших данных хранение и расчеты были относительно простыми, но в настоящее время в хранилище делается больше усилий, чтобы сделать запросы и вычисления более эффективными.Для вычислений эффективность — это не что иное, как быстрый поиск данных., быстрое чтение данных, таким образом, текущее хранилище не только хранит содержимое данных, но также добавляет много метаинформации, такой как информация индекса. Такие идеи похожи на паркет и углеродные данные.
В целом, текущие архитектуры больших данных вокруг системы Hadoop примерно следующие:
Традиционная архитектура больших данных
Причина, по которой ее называют традиционной архитектурой больших данных, заключается в том, что ее позиционирование заключается в решении проблем традиционной BI.Короче говоря, бизнес анализа данных не изменился, но система не может нормально использоваться из-за таких проблем, как данные объем и производительность.Обновление, то этот тип архитектуры должен решить эту проблему. Видно, что он по-прежнему сохраняет действие ETL, а данные заносятся в хранилище данных через действие ETL.
преимущество:Простая и понятная для системы BI основная идея не изменилась, единственное, что изменилось, это выбор технологии, а компоненты BI заменены архитектурой больших данных.
недостаток:Для больших данных нет такой полной архитектуры Cube под BI.Хотя kylin в настоящее время доступен, ограничения kylin очень очевидны.Ему далеко до гибкости и стабильности Cube под BI, поэтому он недостаточно гибок для бизнеса поддержки. , поэтому для сценариев с большим количеством отчетов или сложной детализации требуется слишком много ручной настройки.В то же время архитектура по-прежнему основана на пакетной обработке и не имеет поддержки в реальном времени.
Применимая сцена:В требованиях к анализу данных по-прежнему преобладают сценарии BI, но из-за объема данных, производительности и других проблем он не может удовлетворить повседневное использование.
Потоковая архитектура
На основе традиционной архитектуры больших данных потоковая архитектура очень радикальна.Пакетная обработка напрямую удалена, а данные обрабатываются в виде потоков на протяжении всего процесса.Поэтому на стороне доступа к данным нет ETL, и его заменяет канал данных. Данные, обработанные потоковой обработкой, напрямую передаются потребителям в виде сообщений. Хоть часть хранения и есть, но хранилище больше в виде окон, поэтому хранение происходит не в озере данных, а в периферийной системе.
преимущество:Нет раздутого процесса ETL, а достоверность данных очень высока.
недостаток:В потоковой архитектуре пакетная обработка отсутствует, поэтому воспроизведение данных и историческая статистика не поддерживаются должным образом. Для автономного анализа поддерживается только анализ в окне.
Применимая сцена:Раннее предупреждение, мониторинг и ситуации, когда существует срок действия данных.
Лямбда Архитектура
Лямбда-архитектура является важной архитектурой в системах больших данных.Большинство архитектур в основном представляют собой лямбда-архитектуру или архитектуры, основанные на ее вариантах. Канал данных Lambda разделен на две ветви: потоковая передача в реальном времени и оффлайн. Поток в реальном времени основан на архитектуре потоковой передачи, чтобы обеспечить его производительность в реальном времени, в то время как автономный режим в основном основан на пакетной обработке, которая обеспечивает конечную согласованность. Что это обозначает? Чтобы обеспечить эффективность обработки потокового канала, инкрементные вычисления являются основным вспомогательным ориентиром, в то время как пакетный уровень выполняет полные операции с данными, чтобы обеспечить их окончательную согласованность.Поэтому самый внешний уровень Lambda имеет уровень реального времени и уровень автономный слой.Действие слияния,это действие очень важное действие в Lambda.Общая идея слияния такова:
преимущество:Как в режиме реального времени, так и в автономном режиме, он очень хорошо охватывает сценарии анализа данных.
недостаток:Хотя автономный уровень и потоковая передача в реальном времени сталкиваются с разными сценариями, их внутренняя логика обработки одинакова, поэтому существует много почетных и повторяющихся модулей.
Применимая сцена:Бывают ситуации, когда существуют запросы как в режиме реального времени, так и в автономном режиме.
Каппа Архитектура
Архитектура Kappa оптимизирована на основе Lambda, объединяя части реального времени и потоковой передачи, а также заменяя канал данных очередью сообщений. Таким образом, для архитектуры Kappa потоковая обработка по-прежнему является основным методом, но данные хранятся на уровне озера данных.Когда требуется автономный анализ или пересчет, данные в озере данных могут быть повторно воспроизведены через очередь сообщений. .
преимущество:Архитектура Kappa решает избыточную часть архитектуры Lambda и разработана с потусторонней идеей, что данные могут быть воспроизведены.Вся архитектура очень проста.
недостаток:Хотя архитектура Kappa выглядит простой, ее относительно сложно реализовать, особенно для части воспроизведения данных.
Применимая сцена:Подобно Lambda, модифицированная архитектура оптимизирована для Lambda.
Юнифилд Архитектура
Вышеуказанные архитектуры в основном основаны на обработке массивных данных.Архитектура Unifield является более радикальной, интегрируя машинное обучение и обработку данных.В ядре Unifield по-прежнему доминирует Lambda, но он был преобразован и находится в потоке.Новый Слой машинного обучения был добавлен к слою обработки. Видно, что после того, как данные поступают в озеро данных через канал данных, часть обучения модели добавляется и используется на уровне потоковой передачи. При этом потоковый слой не только использует модель, но и включает непрерывное обучение модели.
преимущество:Архитектура Unifield предоставляет набор архитектурных решений, сочетающих анализ данных и машинное обучение, что очень хорошо решает проблему объединения машинного обучения с платформой данных.
недостаток:Архитектура Unifield более сложна для реализации.Для архитектуры машинного обучения пакет программного обеспечения для развертывания оборудования сильно отличается от платформы анализа данных, поэтому фактор сложности в процессе внедрения выше.
Применимая сцена:Существует большой объем данных для анализа, и в то же время существует очень большой спрос или планирование для удобства машинного обучения.
Суммировать
Вышеуказанные архитектуры являются наиболее используемыми архитектурами в области обработки данных.Конечно, есть много других архитектур, но их идеи будут более или менее похожими. Сфера данных и машинного обучения будет продолжать развиваться, и некоторые из вышеперечисленных идей со временем могут устареть.
Для получения более замечательных идей, пожалуйста, обратите внимание на публичный аккаунт WeChat: Stworker
WeChat Sina Weibo Evernote Pocket Instapaper Email LinkedIn Pinterest