Основные функции ETL-систем

ETL – аббревиатура от Extract, Transform, Load. Это системы корпоративного класса, которые применяются, чтобы привести к одним справочникам и загрузить в DWH и EPM данные из нескольких разных учетных систем.

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

Хочу оговориться, что описание архитектуры отражает мой личный опыт работы с ETL-инструментами и мое личное понимание «нормального» применения ETL – промежуточным слоем между OLTP системами и OLAP системой или корпоративным хранилищем.
Хотя в принципе существуют ETL, который можно поставить между любыми системами, лучше интеграцию между учетными системами решать связкой MDM и ESB. Если же вам для интеграции двух зависимых учетных систем необходим функционал ETL, то это ошибка проектирования, которую надо исправлять доработкой этих систем.

Зачем нужна ETL система


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

Этот бардак есть всегда, он бывает двух видов:
  1. Как случайные ошибки, возникшие на уровне ввода, переноса данных, или из-за багов;
  2. Как различия в справочниках и детализации данных между смежными ИТ-системами.

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

Из-за этой особенности ETL-системы должны в идеале решать не одну, а две задачи:
  1. Привести все данные к единой системе значений и детализации, попутно обеспечив их качество и надежность;
  2. Обеспечить аудиторский след при преобразовании (Transform) данных, чтобы после преобразования можно было понять, из каких именно исходных данных и сумм собралась каждая строчка преобразованных данных.

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

Как работает ETL система


Все основные функции ETL системы умещаются в следующий процесс:



В разрезе потока данных это несколько систем-источников (обычно OLTP) и система приемник (обычно OLAP), а так же пять стадий преобразования между ними:



  1. Процесс загрузки – Его задача затянуть в ETL данные произвольного качества для дальнейшей обработки, на этом этапе важно сверить суммы пришедших строк, если в исходной системе больше строк, чем в RawData то значит — загрузка прошла с ошибкой;
  2. Процесс валидации данных – на этом этапе данные последовательно проверяются на корректность и полноту, составляется отчет об ошибках для исправления;
  3. Процесс мэппинга данных с целевой моделью – на этом этапе к валидированной таблице пристраивается еще n-столбцов по количеству справочников целевой модели данных, а потом по таблицам мэппингов в каждой пристроенной ячейке, в каждой строке проставляются значения целевых справочников. Значения могут проставляться как 1:1, так и *:1, так и 1:* и *:*, для настройки последних двух вариантов используют формулы и скрипты мэппинга, реализованные в ETL-инструменте;
  4. Процесс агрегации данных – этот процесс нужен из-за разности детализации данных в OLTP и OLAP системах. OLAP-системы — это, по сути, полностью денормализованная таблица фактов и окружающие ее таблицы справочников (звездочка/снежинка), максимальная детализация сумм OLAP – это количество перестановок всех элементов всех справочников. А OLTP система может содержать несколько сумм для одного и того же набора элементов справочников. Можно было-бы убивать OLTP-детализацию еще на входе в ETL, но тогда мы потеряли бы «аудиторский след». Этот след нужен для построения Drill-down отчета, который показывает — из каких строк OLTP, сформировалась сумма в ячейке OLAP-системы. Поэтому сначала делается мэппинг на детализации OLTP, а потом в отдельной таблице данные «схлопывают» для загрузки в OLAP;
  5. Выгрузка в целевую систему — это технический процесс использования коннектора и передачи данных в целевую систему.


Особенности архитектуры


Реализация процессов 4 и 5 с точки зрения архитектуры тривиальна, все сложности имеют технический характер, а вот реализация процессов 1, 2 и 3 требует дополнительного пояснения.

Процесс загрузки

При проектировании процесса загрузки данных необходимо помнить о том что:

  1. Надо учитывать требования бизнеса по длительности всего процесса. Например: Если данные должны быть загружены в течение недели с момента готовности в исходных системах, и происходит 40 итераций загрузки до получения нормального качества, то длительность загрузки пакета не может быть больше 1-го часа. (При этом если в среднем происходит не более 40 загрузок, то процесс загрузки не может быть больше 30 минут, потому что в половине случаев будет больше 40 итераций, ну или точнее надо считать вероятности:) ) Главное если вы не укладываетесь в свой расчет, то не надейтесь на чудо — сносите и все, делать заново т.к. вы не впишитесь;
  2. Данные могут загружаться набегающей волной – с последовательным обновлением данных одного и того-же периода в будущем в течение нескольких последовательных периодов. (например: обновление прогноза окончания года каждый месяц). Поэтому кроме справочника «Период», должен быть предусмотрен технический справочник «Период загрузки», который позволит изолировать процессы загрузки данных в разных периодах и не потерять историю изменения цифр;
  3. Данные имеют обыкновение быть перегружаемыми много раз, и хорошо если будет технический справочник «Версия» как минимум с двумя элементами «Рабочая» и «Финальная», для отделения вычищенных данных. Кроме-того создание персональных версий, одной суммарной и одной финальной позволяет хорошо контролировать загрузку в несколько потоков;
  4. Данные всегда содержат ошибки: Перезагружать весь пакет в [50GB -> +8] это очень не экономно по ресурсам и вы, скорее всего, не впишитесь в регламент, следовательно, надо грамотно делить загружаемый пакет файлов и так проектировать систему, чтобы она позволяла обновлять пакет по маленьким частям. По моему опыту лучший способ – техническая аналитика «файл-источник», и интерфейс, который позволяет снести все данные только из одного файла, и вставить вместо него обновленные. А сам пакет разумно делить на файлы по количеству исполнителей, ответственных за их заполнение (либо админы систем готовящие выгрузки, либо пользователи заполняющие вручную);
  5. При проектировании разделения пакета на части надо еще учитывать возможность так-называемого «обогащения» данных (например: Когда 12 января считают налоги прошлого года по правилам управленческого учета, а в марте-апреле перегружают суммы на посчитанные по бухгалтерскому), это решается с одной стороны правильным проектированием деления пакета данных на части так, чтобы для обогащения надо было перегрузить целое количество файлов (не 2,345 файла), а с другой стороны введением еще одного технического справочника с периодами обогащения, чтобы не потерять историю изменений по этим причинам).


Процесс валидации

Данный процесс отвечает за выявление ошибок и пробелов в данных, переданных в ETL.
Само программирование или настройка формул проверки не вызывает вопросов, главный вопрос – как вычислить возможные виды ошибок в данных, и по каким признакам их идентифицировать?
Возможные виды ошибок в данных зависят от того какого рода шкалы применимы для этих данных. (Ссылка на прекрасный пост, объясняющий, какие существуют виды шкалhttp://habrahabr.ru/post/246983/).

Ближе к практике в каждом из передаваемых типов данных в 95% случаев возможны следующие ошибки:

Типы данных Внутри поля По отношению к другим полям Совместимость форматов при передаче между системами
Перечисление и текст
  1. Не из списка разрешенных значений
  2. Отсутствие обязательных значений
  3. Не соответствие формату (Все договора должны нумероваться «ДГВxxxx..»)

  1. Не из списка разрешенных значений для связанного элемента
  2. Отсутствие обязательных элементов для связанного элемента
  3. Не соответствие формату для связанного элемента(например: для продукта «АИС» все договора должны нумероваться «АИСxxxx..»)

  1. Символы допустимые в одном формате, недопустимы в другом
  2. Кодировка
  3. Обратная совместимость (Элемент справочника был изменен в целевой системе без добавления мэппинга)
  4. Новые значения (нет мэппинга)
  5. Устаревшие значения (не из списка разрешенных в целевой системе)

Числа и порядки
  1. Не число
  2. Не в границах разрешенного интервала значений
  3. Пропущено порядковое значение (например: данные не дошли)

  1. Не выполняется отношение y=ax+b (например: НДС и Выручка, или Встречные суммы равны)
  2. Элементу «А» присвоен неправильный порядковый номер
  3. Разницы за счет разных правил округления значений (например: в 1С и SAP никогда не сходится рассчитанный НДС)

  1. Переполнение
  2. Потеря точности и знаков
  3. Несовместимость форматов при конвертации в не число

Даты и периоды
  1. День недели не соответствует дате
  2. Сумма единиц времени не соответствует из-за разницы рабочие/не рабочие/праздничные/сокращенные дни

  1. Несовместимость формата даты при передаче текстом (например: ISO 8601 в UnixTime, или разные форматы в ISO 8601)
  2. Ошибка точки отсчета и точности при передаче числом (например: TimeStamp в DateTime)



Соответственно проверки на ошибки реализуются либо формулами, либо скриптами в редакторе конкретного ETL-инструмента.
А если вообще по большому счету, то большая часть ваших валидаций будет на соответствие справочников, а это [select * from a where a.field not in (select…) ]
При этом для сохранения аудиторского следа разумно сохранять в системе две отдельные таблицы – rawdata и cleandata с поддержкой связи 1:1 между строками.

Процесс мэппинга

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

  1. Таблица замэпленных данных должна включать одновременно два набора полей – старых и новых аналитик, чтобы можно был сделать select по исходным аналитикам и посмотреть, какие целевые аналитики им присвоены, и наоборот:



  2. Таблица замэпленных элементов должна иметь отдельное PK-поле, чтобы при связи 1:* и *:* можно было создать много строк в MappedData для одной строки в CleanData и сохранить аудиторский след
  3. Таблица MappedData должна быть отдельной от CleanData по тем же причинам что и пункт 2


Заключение


В принципе это все архитектурные приемы, которые мне понравились в тех ETL инструментах, которыми я пользовался.

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

Надеюсь, эта информация будет вам полезна.
  • +4
  • 118k
  • 4
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 4

    0
    то это ошибка проектирования, которую надо исправлять доработкой этих систем.

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

    Хабр, ты серьезно? Такой пост и ни одного комментария и рейтинг 4?!?
      0
      Спасибо за комплимент:) даже если интегрируются «суровые монстры» — если между двумя системами выполняющими полезную работу появляется третья только для связи между ними — это плохо, потому что это +1 технология и +1 человек поддержку и +1 комплект документации на решение для хранения.

      А когда систем работает 100+, то реальна ситуация когда под сокращение кого-то уволят и о ней просто забудут пока ненакроется

      Есть хорошее правило — требования к интерфейсу интеграции определяет система-приемник.
      Допиливать надо источник и выкладывать конец в Enterprise Service Bus, где в идеале лежит вся интеграция. Чтобы никаких «кротовых нор» не было.
        0
        мой личный опыт работы с ETL-инструментами

        Можете привести примеры и описать плюсы и минусы систем которыми пользовались.
        Просто в данный момент у нас самописная система, а хотелось бы что-то полноценное и зрелое.
          0
          Хорошая статья, спасибо. Сейчас сами решаем задачу подгрузки данных из других систем и разбираемся с ETL инструментами. Помогло структурировать полученные знания.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое