Основы процесса ETL

ETL (Extract, Transform, Load) — это хорошо известный архитектурный шаблон, популярность которого в последнее время растет с ростом приложений, управляемых данными, а также ориентированных на данные архитектур и фреймворков. Говорят данные — это новая нефть, так что, как и в случае с нефтью, ее мало найти, нужно будет много вложить в ее добычу, переработку, транспортировку, хранение, сбыт конечного продукта и т. д. Простыми словами, если ваша система собирается перемещать данные из одного или нескольких источников, каким-то образом изменять их формат, делать их доступными через какую-либо систему управления данными и повторять это неоднократно, то вы можете быть уверены, что собираетесь разрабатывать систему ETL, даже если вы не называй это так. Эта статья познакомит вас с проблемами и проблемами, известными решениями, хитростями и лучшими практиками, применяемыми в мире современного процесса ETL.

Проблемы и вызовы

При построении системы ETL вы, вероятно, столкнетесь с рядом проблем, которые зависят от характера ваших данных. Вот список некоторых проблем, с которыми вы можете столкнуться при разработке этапов обработки данных: извлечение, преобразование и загрузка.

Извлекать

Доступность источников данных

Чем сложнее и ценнее ваши данные, тем больше шансов, что они будут разбросаны по многочисленным источникам и представлены в различных форматах. Если исходные данные накапливаются в структурированном хранилище данных, таком как PostgreSQL или MongoDB, а владелец источника принадлежит вашей организации, возможен прямой доступ через интерфейс языка запросов и драйвер БД. Однако в реальном мире предоставление прямого доступа к службе базы данных используется редко, поскольку это сопряжено с высокими рисками безопасности и может привести к взлому и уязвимостям. С другой стороны, получение прямого доступа к исходной БД является излишним, поскольку нам нужно читать данные, а любая запись выходит за рамки функциональности ETL. Поэтому наиболее эффективным и, следовательно, популярным способом доступа к исходным данным является создание конечной точки HTTP, которая будет передавать данные в структурированном формате, таком как XML, JSON или CSV. При проектировании конечной точки настоятельно рекомендуется следовать принципам протокола REST. Менее эффективным, но жизнеспособным вариантом является сохранение данных в файле и его публикация на веб-сервере. В таком случае имеет смысл сжимать файлы перед публикацией, т.е. в формате ZIP.

Вышеупомянутая ситуация, когда данные доступны в структурированном формате, к сожалению, редко имеет место, тем более что право собственности на источник данных выходит за рамки вашей организации. Данные, скорее всего, будут предназначены для людей, а не для агентов ETL, и будут представлены в формате HTML как традиционный просматриваемый веб-сайт. Вот где в игру вступает концепция скрейпинга. Конечно, реализация HTTP-загрузчика и синтаксического анализатора с нуля была бы неудачной идеей, поскольку к вашим услугам есть много отличных решений с открытым исходным кодом. Например, Scrapy, решение для парсинга и сканирования веб-страниц на основе Python. Поскольку современные веб-сайты часто представляют собой одностраничные веб-приложения, а не наборы статических HTML-документов, просмотр и получение доступа к отдельным страницам может оказаться еще более сложной задачей и потребовать полной имитации поведения пользователя. В этом случае может быть полезен эмулятор браузера Selenium, надежное решение, имеющее долгую историю развития и реализации на нескольких языках программирования, включая, помимо прочего, Java и Python.

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

  1. Свяжитесь с владельцем источника данных и спросите о доступности официальных конечных точек API или разрешении на очистку данных. Во многих случаях решение может быть проще, чем кажется. Обмен ссылками, упоминание владельца данных или распределение доходов могут быть хорошими мотиваторами для того, чтобы поделиться с вами данными. В любом случае, делиться — значит заботиться.
  2. Внимательно прочитайте страницы «Условия использования» и «Конфиденциальность данных», там могут быть ответы на многие ваши вопросы, а также имейте в виду, что эти страницы имеют реальное юридическое значение.
  3. Изучите местные законы о конфиденциальности данных и поищите в Google последние новости о судебных делах, связанных с использованием общедоступных данных, особенно со очисткой и сканированием данных.
  4. Посмотрите на структуру исходного кода, который вы собираетесь парсить. Если у него есть специальные средства защиты от агентов парсинга, таких как капча, то автоматически сканировать такие источники не стоит.
  5. Вообще говоря, парсинг данных не является незаконным, но регулируется многочисленными правилами и должен выполняться с осторожностью и соблюдением этических норм.

Динамический характер данных

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

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

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

3. Вышеупомянутые два подхода, когда владелец данных активно уведомляет клиентов об изменениях или публикует изменения через определенные промежутки времени, являются мечтой для потребителей данных, поскольку они экономят массу ресурсов и времени. К сожалению, в большинстве случаев это слишком хорошо, чтобы быть правдой, и потребители данных должны сами брать на себя бремя отслеживания изменений. Самый очевидный способ сделать это — снова и снова пинговать источники данных и сравнивать последние данные с ранее отсканированным снимком. Медленно, неэффективно, дорого как для обслуживания, так и для потребителей, но часто неизбежно. Процесс сканирования источника может стать отправной точкой всего конвейера ETL. График выполнения процесса можно настроить как простое задание Cron или более сложную систему планирования конвейера, такую ​​как Apache Airflow или AWS Glue.

Несколько лайфхаков для парсинга динамических данных:

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

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

Трансформировать

Неоднородный характер данных

Существует множество (если не бесконечное количество) способов моделирования и представления одних и тех же данных, что создает еще одну проблему для потребителей данных, особенно для тех, кто собирает данные из нескольких источников, связанных с одной бизнес-сферой. В этом случае мы рекомендуем придерживаться следующей стратегии:

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

2.Спроектировать и разработать несколько адаптеров данных, преобразующих поступающие необработанные данные в стандартную форму. Такие предварительные преобразования могут включать унификацию адресов, названий компаний и стран, форматов даты и времени, представления чисел и цифр и т. д. Не имеет значения, относится ли этот этап предварительного форматирования к части извлечения или преобразования вашего потока ETL, но важно выполнить эту унификацию до того, как будут применены преобразования, основанные на бизнес-логике, данные максимально стандартизированы. Другими словами, мы советуем следующую практику: сначала трансформировать на микроуровне (формате), а затем переходить к макротрансформациям (бизнесу). Такой подход позволит при необходимости подключать больше источников данных и адаптеров и отделить этап преобразования от этапа извлечения.

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

Обогащение данных

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

Связывание данных

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

Добавление метаданных: классификация и тегирование

Другим типом обогащения данных, который может повысить ценность ваших данных, является классификация. Он может быть полезен для навигации в системах визуализации данных или использоваться в качестве одного из критериев при анализе данных по принципу «разделяй и властвуй». Для добавления информации о классе к вашим данным можно применить несколько подходов: список предопределенных классов может быть представлен как отдельный объект, каждый класс имеет выделенный идентификатор. Другой хорошей практикой является организация списка классов в виде иерархии, также известной как таксономия. В зависимости от характера ваших данных элементам может быть назначен один эксклюзивный класс или несколько необязательных классов. Другим популярным способом классификации является добавление списка текстовых меток или тегов к вашим элементам данных. Как правило, он более гибкий как с точки зрения обработки, так и хранения, хотя его следует использовать с осторожностью, поскольку список тегов может неконтролируемо расти, создавая дубликаты. совпадения и другие несоответствия. Управление уровнем данных метаданных или вашей системой ETL — сложная нетривиальная задача, требующая постоянного пересмотра и рефакторинга таксономий классов и списков тегов. все изменения и синхронизирует все части системы, зависящие от метаданных.

Распознавание именованных объектов

Другой тип обогащения данных связан с добавлением к вашим данным имен людей, компаний, стран, адресов и другой географической информации. Он широко известен под термином Распознавание именованных объектов (NER). Это огромная тема, которая не может быть раскрыта в рамках данной статьи. Когда вы столкнетесь с необходимостью интеграции NER в вашу ETL-систему, вам, скорее всего, придется принять несколько решений:

  1. Создайте собственный NER или возьмите систему с открытым исходным кодом или коммерческую систему. Функциональность NER часто предоставляется как часть пакетов обработки естественного языка (NLP). Хорошей практикой является тестирование системы на тех же данных, которые вы будете вводить в нее позже в производственной среде. Тестовые прогоны на общих образцах текста часто могут вводить в заблуждение. Еще одним важным аспектом системы NER является возможность управлять списками именованных сущностей и настраивать правила распознавания. Использование системы с предустановленной конфигурацией в качестве «черного ящика» — большая вероятность столкнуться с серьезными проблемами в будущем.
  2. Используйте систему распознавания на основе правил или подход машинного обучения/нейронных сетей. Это решение сильно зависит от количества именованных объектов, с которыми вы имеете дело, и разнообразия форматов их представления. Наша общая рекомендация — использовать систему NER на основе машинного обучения, предпочтительно облачную SaaS, если ваша текстовая информация стандартна и универсальна. При работе с неуниверсальными текстами, такими как конкретные типы контрактов, банковские формы и т. д., может быть хорошей идеей использовать подход, основанный на правилах.

Показатели качества

Во всех нетривиальных преобразованиях и обогащении данных, таких как классификация, тегирование и распознавание именованных объектов, качество обработки является ключевым (хотя в некоторых случаях скорость обработки может быть критической). Редко можно ожидать 100% качества вывода, даже если входные данные кристально чисты (конечно, это не так). В сложных случаях достаточно хорошим результатом можно считать выходное качество 60–70%. Основными показателями качества обработки данных являются полнота и точность. Припоминание — это процент сущностей, которые вы смогли правильно распознать, из всех сущностей, присутствующих во входном тексте. Точность — это процент правильно распознанных объектов от всех объектов, распознанных системой во входном тексте. В задачах обработки текста и классификации традиционно существует компромисс между точностью и полнотой, что вполне очевидно: чем больше сущностей вы пытаетесь распознать, тем менее строгие правила и модели распознавания вам придется применять, следовательно, вы будете собирать больше мусора. с ценными находками.

Человек в курсе

В случае, когда качество данных имеет решающее значение, а автоматизированное решение может обеспечить только определенный уровень точности и полноты, вмешательство человека часто является единственным вариантом. В контексте конвейера процессов ETL эффективным решением может быть шаблон «человек в цикле». Это означает, что человек-эксперт, курирующий некоторые или все элементы данных, рассматривается как один из блоков обработки, который можно разместить где-нибудь на диаграмме потока данных, например. между извлечением и загрузкой. Хорошей практикой является предварение этапа ручной обработки блоком принятия решений, который измеряет, являются ли результаты обработки для текущего элемента данных достаточно надежными или требуют проверки человеком-экспертом. Хорошим вариантом организации такого блока обработки с участием человека является создание базы данных для промежуточного хранения данных с простым пользовательским интерфейсом CRUD, чтобы группа экспертов-людей могла собирать входящие элементы данных, просматривать/исправлять их, и пометить как обработанный, чтобы обработка могла продолжаться, например. элементы данных передаются на этап загрузки.

Нагрузка

Основной компромисс при принятии решения о том, куда загружать ваши данные после того, как они претерпели все преобразования, заключается в выборе между реляционной БД (также известной как SQL) и каким-либо другим типом хранилища, широко известным как NoSQL, например. MongoDB или ElasticSearch. Основными аспектами, на которых должно основываться такое решение, являются:

  1. Количество записей в ваших данных (текущих и потенциальных)
  2. Количество новых записей, которые будут добавляться и обновляться ежедневно
  3. Всплески притока данных
  4. Сложность реляционной модели

Эмпирическое правило состоит в том, чтобы помнить два принципа:

  1. Реляционные базы данных не масштабируются.
  2. Базы данных NoSQL ограничены в объединении нормализованных объектов данных.

Лайфхаки для ETL-процессов

Чтобы найти золотую середину, можно применить пару лайфхаков:

  1. Денормализация: некоторые элементы данных не полностью отделены (нормализованы), а копируются непосредственно в объединенные родительские элементы. Это создает дублированные данные и потенциальные проблемы с обслуживанием в будущем, но помогает с масштабированием данных и задержкой чтения.
  2. Используйте комбинацию SQL и NoSQL в своей системе. Храните нормализованные бизнес-объекты в базе данных SQL, а сложные бизнес-объекты (документы) — в хранилище NoSQL, таком как Mongo. Реляционное хранилище гарантирует, что все объекты будут уникальными и однозначными, а хранилище документов будет легко масштабироваться. Время от времени может потребоваться некоторое управление служебными данными, например. полная переиндексация коллекции документов, что кажется справедливой ценой за комбинацию целостности ссылок и низкой задержки доступа, которую вы получите.

ЭТЛ-процесс. Резервное копирование

Выживают только параноики.