Поскольку мы перезапускаем System Soft и укрепляем наш успех на различных рынках, я хотел бы поделиться нашим мнением об одном, в частности: Инженерия данных и аналитика.
Это первая из серии статей, посвященных изучению того, как структурировать конвейеры данных и управлять ими, поскольку типы и источники данных постоянно трансформируются и требуют изменений. В этой статье я более подробно рассмотрю природу данных и новые способы управления ими и их монетизации.
Хотя некоторые могут не видеть прочной связи между инжинирингом данных и деловой стороной вещей, на самом деле прямая связь существует.
Одной из важных ролей инженера данных является проектирование конвейеров данных на основе потребностей бизнеса. Поскольку эти потребности различаются, меняется и архитектура.
Давайте посмотрим на конвейер данных с двух точек зрения: воды и нефти. В случае воды она собирается и направляется в одну большую магистраль. Инженеры собирают и контролируют различные параметры: объем, скорость, давление, температуру и т. д., а также управляют курированием в зависимости от спроса.
Конвейеры данных имеют схожие параметры и соображения, влияющие на архитектуру конвейера:
- Партия
- В реальном времени, почти в реальном времени
- Объем данных
- Скорость данных
- Потребности в обработке
- Потребности в обогащении
- Системы, из которых он собран
- Потребители данных
- Актуальная технология эхосистемы заказчика
Данные непрерывно поступают с одной стороны конвейера, проходят ряд шагов и выходят в виде отчетов, моделей и представлений. Конвейер данных — это «операционная» сторона анализа данных.
Данные — это новая НЕФТЬ
По мере роста источников данных, их использования и ценности они приобрели характеристики нефти, а не воды. Он должен пройти множество стадий обработки, которые определяются его конечным использованием, прежде чем он обретет свою истинную ценность. Первый шаг для компаний — направить эти большие данные из разных источников в систему хранения, чтобы затем выполнить
- Аналитика данных для визуализации данных на информационных панелях или
- Алгоритмы машинного обучения для поиска закономерностей в данных и создания прогнозной аналитики
При рассмотрении конвейеров данных необходимо учитывать 3 ключевых момента:
- Спроектируйте конвейер так, чтобы все последующие потребители могли использовать один и тот же конвейер для получения данных для своих нужд.
- Сохраняйте происхождение всех данных, чтобы при необходимости можно было отследить происхождение и путь.
- Избегайте дублирования данных, чтобы оптимизировать производительность и затраты, при этом соблюдая бизнес-потребности и SLA.
Создание конвейера данных
Конвейер больших данных строится с использованием множества инструментов. Например, когда данные поступают по конвейеру, синтаксические анализаторы анализируют эти данные для распределенной файловой системы, NoSQL или облачного хранилища. Давайте посмотрим на эталонную архитектуру, которую мы внедрили на нескольких клиентах.
Наш старший инженер по большим данным, Антон Прабху, построил множество конвейеров больших данных для многих клиентов, используя различные инструменты и технологии для настройки конвейера больших данных к их озерам больших данных.
Syslog NG: этот инструмент собирает дельта-данные из разных источников данных. Он объединяет все данные из разных источников в единый пакет и передает эти пакеты в другие каналы, такие как Flume или Kafka.
- Ввод: имеет исходную информацию
- Фильтр: фильтруйте журналы или необходимую информацию, используя шаблоны регулярных выражений.
- Выход: место назначения, куда мы хотим отправить данные.
Flume: еще один канал конвейера данных, который передает данные из одного источника и синхронизирует их с местом назначения. Местом назначения может быть распределенная файловая система или база данных NoSQL.
Kafka: система обмена сообщениями, которая хранит данные в виде разделов темы. Он работает на основе модели издателя и подписчика.
Spark. Широко используемый инструмент для анализа и преобразования больших данных, который также можно использовать для хранения данных в распределенной файловой системе Hadoop.
Elastic Search, Logstash и Kibana: база данных NoSQL, где мы храним данные в эластичном поиске в виде индексов. Эти данные можно легко и быстро проиндексировать, а также их можно визуализировать в Kibana в виде информационных панелей.
HDFS: используется для долгосрочного архивирования для пакетной аналитики.
Реальное использование хранилища больших данных
Когда дело доходит до хранилища больших данных, доступны следующие варианты: распределенная файловая система (распределенная файловая система Hadoop — HDFS), NoSQL или графовые базы данных (Elastic search, Cassandra, MongoDB, Neo4J и т. д.) в виде неструктурированных или полуструктурированных данных.
Этот сбор данных в основном используется учеными для машинного обучения или прогнозной аналитики, а также может использоваться для визуализации в виде информационных панелей.
Долгосрочное архивирование данных также можно использовать для машинного обучения, глубокого обучения и искусственного интеллекта для построения моделей и оценки.
Он также видел, как некоторые компании сохраняют данные в графовых базах данных для решения задач дискретной математики. Одним из таких примеров является сохранение операционных данных в базе данных графа, а затем визуализация сети узлов или машин и их ребер в виде связей между узлами. Это помогает найти самый простой способ обнаружения отказавших узлов от активных узлов или машин.
Оставайтесь с нами
Я надеюсь, что вы нашли это полезным. Следующие блоги будут посвящены изучению различных комбинаций конвейерных технологий и подключению к различным вариантам использования.
Я также включу анализ того, как это вписывается в реализацию в разных облачных стеках.
Сатиш Аббури
Оригинальную версию этой статьи читайте здесь.
