ETL инструменты подключаются к источнику, забирают данные, трансформируют данные, приводят к нужному формату и структуре и уже упорядоченные данные складывают в слой ODS хранилища.

ELT инструменты подключаются к источнику, забирают данные и сохраняют их как есть, а потом трансформируют и передают в слой ODS хранилища.

Оба класса инструментов имеют свои достоинства и недостатки.

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

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

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

Но на этом этапе в витрине еще не появятся данные — их нужно туда загрузить. Загружать данные вручную долго и не удобно. Для этой задачи используются ETL-инструменты — это приложения, которые по расписанию могут подключаться к источнику, забирать нужные данные, преобразовывать их и сохранять в нужное место.

Есть два класса инструментов загрузки, преобразования и выгрузки данных:
ETL (Extract — Transform — Load) и ELT (Extract — Load — Transform).

Часто термином ETL дата-специалисты обозначают оба класса инструментов, хотя это и не совсем корректно, потому что инструменты отличаются. Давайте разберемся в различиях.

Для нашей витрины мы можем описать источники примерно так:

После того как мы поняли структуру данных итоговой витрины — начинаем работу с источниками, чтобы понять откуда можем выгрузить нужную информацию. Мы определяем основную (мастер-систему) для ключевых сущностей, определяем связи между данными, правила преобразования и агрегации. Эта информация заносится в специальный документ — S2T (source to target).

Пример источников для нашей витрины:

Разработка витрины в хранилище начинается с описания структуры данных — какую информацию мы хотим получать для решения задачи.

Для решения 3й задачи нам больше подойдет лямбда-архитектура. Это подход, который агрегирует в себя два предыдущих — потоковую и пакетную обработку. Лямбда-архитектуру также называют обработкой в режиме близком к реальному времени.

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

Давайте рассмотрим три разные бизнес-задачи:

1. Бухгалтерский квартальный отчет

Бухгалтеру для подачи квартального отчета в налоговую нужны выверенные и точные данные за весь квартал: нужно понимать точно, какие платежи прошли, какие акты закрылись, чтобы подвести баланс о прибылях и убытках. При подготовке квартального отчета бухгалтера не интересует история по каждому отдельному счету — платеж может быть совершен, потом отозван и совершен заново. Нужна итоговая информация#nbsp— сколько денег компания получила, сколько потратила, чтобы корректно рассчитать налоги.

2. Отправка рекламных сообщений клиенту, который находится рядом с офисом компании

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

3. Анализ конверсии в интернет-рекламе

Когда маркетологи формируют интернет компанию они могут ошибиться. Например, неправильно указать размер скидки в рекламном объявлении. Человек может видеть объявление «Скидки на зимние шины 70%», переходить на сайт, где написано, что скидка всего 7% и уходить разочарованным. Чтобы проанализировать эффективность рекламных компаний, исправить ошибки или уточнить целевую аудиторию, маркетологам нужна статистика. Получать такую статистику 1 раз в квартал — безрассудно, и даже 1 раз в день — слишком редко, нужна оперативная информация. Но отслеживать каждый переход по рекламе тоже не эффективно. Для такой задачи может подойти сводная аналитика 1 раз в час.

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

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

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

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

Контроль качества данных или что может пойти не так?

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

Бизнес или содержательные ошибки в данных.

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

Технические ошибки в данных, которые вызваны сбоями в работе системы.

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

Основные проверки контроля качества данных:

• Полнота загрузки данных
• Своевременность загрузки данных
• Корректность загрузки данных

Все ли вовремя загружается?

Любимый вопрос бизнес-заказчиков: когда данные должны появится в отчете? И как я могу убедиться, что данные в отчете уже обновлены. Очень удобно такую информацию выносить в инструменты DataGovernance. Например, в реестре отчетом могут быть сведения о составе витрин, которые используются для BI-дэшборда, данные о плановых сроках загрузки всех таблиц и статус загрузки — в регламенте, загрузилось без ошибок, загрузилось, но с ошибками.

Почему данных меньше, чем ожидалось?

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

Почему данные некорректные?

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

Какие вопросы качества данных чаще всего интересуют бизнес-пользователей?

Вариантов ошибок множество — могут быть аппаратные проблемы: с жесткими дисками, с сетевым кабелем, с оперативной памятью. Могут быть сбои программного обеспечения — приложения имеют свойство «зависать». Могут быть проблемы на уровне логики загрузки (ETL-процессов) — например, ошибки в форматах — мы можем пытаться положить картинку в текстовое поле.

Почему возникают ошибки при загрузке данных?

Логическая модель описывает смысловую структуру таблиц и связей между ними. А физическая модель описывает формат хранения данных в базе.
Например, в логической модели мы можем сказать, что нам нужна таблица Клиенты, с атрибутами: ФИО, паспорт, адрес проживания. При этом, мы можем указать, что адрес проживания мы хотим брать из справочника адресов.

В физической модели мы должны будет указать, что ФИО — это текстовое поле длинной 255 символов, паспорт — целое число в 10 символов, адрес проживания — ключ-идентификатор, связанный со справочником адресов.

В чем разница между физической и логической моделью базы данных?

Во-первых, не все источники могут отдавать данные в потоке. Во-вторых, настраивать потоковую загрузку очень «дорого» — требуются и специальные технологии, и специализированные архитектурные подходы — вложения должны окупаться результатом. А в-третьих, потоковая обработка данных менее надежна — если произойдут сбои в потоковой передаче данных, то исторические данные будет сложно восстановить.

Почему не используют только потоковую загрузку данных?

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

Что лучше ETL или ELT?

Самый крутой ETL инструмент тот, который решает ваши задачи.
ETL инструментs разные. Например, полнофункциональные коробочные решения, как Informatica или IBM DataStage. Эти инструменты предоставляют очень много функций из коробки. Но это лицензионные вендорские продукты, и будет сложно применять их для нестандартных процессов и задач.

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

Можно воспользоваться открытыми ETL-фреймворками, например, Spark. На нем можно реализовать практически любую логику и любой ETL процесс. Минус в сложности освоения – придется писать код руками.

Какой ETL инструмент самый крутой?

Рубрика: 5 вопросов от джуна