Четыре компонента предварительной обработки данных:

  1. Интеграция данных
  2. Преобразование данных
  3. Сжатие данных
  4. Очистка данных

Интеграция данных

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

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

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

Области интеграции данных

Интеграция данных — это термин, охватывающий несколько отдельных подобластей, таких как:

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

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

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

Дизайн

  • Инициатива интеграции данных внутри компании должна быть инициативой бизнеса, а не ИТ. Должен быть лидер, который понимает активы данных предприятия и сможет возглавить обсуждение долгосрочной инициативы по интеграции данных, чтобы сделать ее последовательной, успешной и полезной.
  • Анализ требований (BRS), т.е. зачем проводится интеграция данных, каковы цели и результаты. Из каких систем будут браться данные? Все ли данные доступны для выполнения требований? Каковы правила бизнеса? Какова модель поддержки и SLA?
  • Анализ исходных систем, т.е. какие есть варианты извлечения данных из систем (уведомление об обновлении, добавочные извлечения, полные извлечения), какова требуемая/доступная частота извлечений? Каково качество данных? Правильно ли заполнены обязательные поля данных? Доступна ли документация? Какие объемы данных обрабатываются? Кто является владельцем системы?
  • Любые другие нефункциональные требования, такие как окно обработки данных, время отклика системы, предполагаемое количество (одновременных) пользователей, политика безопасности данных, политика резервного копирования.
  • Какова модель поддержки новой системы? Каковы требования SLA?
  • И последнее, но не менее важное: кто будет владельцем системы и каково финансирование расходов на обслуживание и модернизацию?
  • Результаты вышеуказанных шагов должны быть задокументированы в виде документа SRS, подтвержденного и подписанного всеми сторонами, которые будут участвовать в проекте интеграции данных.

Выполнение

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

Тестирование

Наряду с внедрением необходимо провести надлежащее тестирование, чтобы убедиться, что унифицированные данные являются правильными, полными и актуальными.

В тестировании должны участвовать как технические ИТ-специалисты, так и представители бизнеса, чтобы убедиться, что результаты соответствуют ожиданиям/требованиям. Таким образом, тестирование должно включать как минимум нагрузочное тестирование производительности (PST), техническое приемочное тестирование (TAT) и пользовательское приемочное тестирование (UAT) PST, TAT (техническое приемочное тестирование), UAT (пользовательское приемочное тестирование).

Методы интеграции данных

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

Интеграция вручную или общий пользовательский интерфейс — пользователи работают со всей необходимой информацией, получая доступ ко всем исходным системам или интерфейсу веб-страницы. Единого представления данных не существует.

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

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

Единый доступ к данным или виртуальная интеграция — оставляет данные в исходных системах и определяет набор представлений для предоставления и доступа к единому представлению для клиента в рамках всего предприятия. Например, когда пользователь получает доступ к информации о клиенте, конкретные сведения о клиенте прозрачно получаются из соответствующей системы. Основными преимуществами виртуальной интеграции являются почти нулевая задержка распространения обновлений данных из исходной системы в консолидированное представление, отсутствие необходимости в отдельном хранилище для консолидированных данных. Однако к недостаткам относятся ограниченная возможность управления историей данных и версиями, ограничение применения метода только к «похожим» источникам данных (например, базы данных одного типа) и тот факт, что доступ к пользовательским данным создает дополнительную нагрузку на исходные системы. которые, возможно, не были предназначены для размещения.

Общее хранилище данных или физическая интеграция данных — обычно означает создание новой системы, в которой хранится копия данных из исходных систем для хранения и управления ими независимо от исходной системы. Наиболее известный пример такого подхода называется хранилищем данных (DW). Преимущества включают в себя управление версиями данных, объединение данных из очень разных источников (мэйнфреймы, базы данных, плоские файлы и т. д.). Однако для физической интеграции требуется отдельная система для обработки огромных объемов данных.