Downloaded 20 times
![Анализ содержимого таблиц исходных
данных
• Понимание содержания данных имеет решающее значение для
определения наилучшего подхода для извлечения данных из
источника
• Поиск NULL значений в т.ч. во внешних ключах, разработка
правил обработки таких данных
• Даты в недетерминированных полях - не [date] / [datetime] Часто
даты в системах хранят в виде строки разного формата, на этапе
преобразования нужно понимать правила их обработки](https://image.slidesharecdn.com/etl-180208125241/85/ETL-22-320.jpg)
Uploaded bySergey Sukharev
Витрины данных - загрузка данных, разработка процессов ETL
Документ описывает процессы разработки и загрузки данных для витрин данных и хранилищ данных. Он охватывает методы ETL, проектирование и архитектуру данных, а также важные аспекты управления качеством данных и их интеграции из различных источников. Спецификации включают правила обработки, хранение метаданных и использование карт преобразований для обеспечения корректности и согласованности данных.
Витрины данных - загрузка данных, разработка процессов ETL
- 1. Витрины данных Разработка процессовзагрузки данных Сергей Сухарев Эксперт отдела BI-систем и интеграционных технологий ООО «Джи-Эм-Си-Эс Верэкс»
- 2. Сергей Сухарев • Экспертотдела BI-систем и интеграционных технологий • > 20 лет в IT • > 18 лет в DWH • Экспертиза: • Архитектор информационных систем • Архитектор Хранилищ Данных и систем Business Intelligence • Знания методик построения Корпоративных Хранилищ Данных (ER, Dimensional Modeling, Data Vault) • Бизнес аналитик/Системный аналитик • Опыт оптимизации баз данных для целей построения Корпоративных Хранилищ Данных и отчетности (Oracle, MS SQL Server) • Опыт разработки Витрин Данных и отчетов в системах отчетности • Разработчик процессов загрузки данных в Корпоративные Хранилища Данных и Витрины Данных (ETL)
- 3. Архитектура и требования Сбори анализ требований Планирование архитектуры Разработка Тестирование
- 4.
- 5. Staging Area • Всяобработка и подготовка данных для загрузки в хранилище данных или витрину производится в области Staging Area • Staging Area необходимая область данных для: • Временное хранения исходных данных, для того что бы повторно не обращаться за исходными данными в системы – источники данных • Постоянное хранение исходных данных для возможного восстановления данных хранилища данных после возможного катастрофического сбоя хранилища данных • Аудит загрузки и трансформации, имея исходные данные всегда можно проверить правильность расчетов и трансформации данных
- 6. Необходимая информация для проектированияобласти Staging Area • Имя таблицы • Стратегия обновления данных в ней, будут ли данные добавляться, обновляться и удаляться. Будет ли таблица временной для хранения данных промежуточных расчетов • Частота загрузки данных. Загрузка по расписанию или загрузка в режиме реального времени • ETL job, в котором участвует таблица, если их много, то необходимо иметь информацию обо всех • Начальное кол-во строк в таблице • Средняя длина строки, в байтах. Необходимо для оптимизации хранения данных и производительности системы • Ожидаемый ежемесячный прирост данных • Первоначальный размер таблицы в байтах • Предполагаемый размер таблицы через 6-ть месяцев
- 7. Структуры данных ETLсистем • Источники данных: • Файлы • XML структуры • Таблицы реляционных баз данных • Не реляционные данные • Целевые структуры: • Таблицы измерений • Таблицы фактов • Таблицы агрегатов • Таблицы перекодировки ключей
- 8. Стандарты планирования иразработки • Перед изменением таблицы в Staging Area необходимо провести анализ влияния изменения на процессы загрузки, добавление или удаление колонки может сломать ежедневную загрузку • Хранение метаданных о таблицах Staging Area • Связь с логической моделью данных • Связь с бизнес-процессом • Техническое описание таблицы • Применение стандартов в наименованиях таблиц н.р. таблицы области Staging Area источника данных CRM должны иметь префикс SA_CRM_ • Протоколы или журналы контроля преобразований данных на каждом шаге процессов ETL
- 9.
- 10.
- 11. Извлечение данных (extraction) •Интеграция всех данных предприятия является самой сложной проблемой при построении хранилища данных или витрины данных • Данные извлекаются из гетерогенных источников данных • Данные источников могут быть не согласованы, не связаны между собой, справочники могут иметь разную кодировку • Каждый источник данных имеет свой собственный набор характеристик, которым необходимо управлять и интегрировать в системе при помощи ETL процессов • Время на загрузку данных всегда ограничено технологическим окном
- 12. Извлечение данных (extraction) •ETL процессы должны эффективно интегрировать системы, которые отличаются друг от друга: • СУБД • Операционные системы • Аппаратные средства • Протоколы связи • До проектирования процессов ETL необходимо создать карту преобразований (логический мэппинг) данных • Карта преобразований – это таблица в которой описаны правила преобразований данных от источника данных до целевой таблицы
- 13. Карта преобразований • Документируетсвязь между полями таблиц источника данных и полями целевых таблиц хранилища данных или витрин данных • Документ связывает системы от начала преобразований до самого конца
- 14. Разработка карты преобразований •Определить метаданные • Определить источники данных • Анализ исходных систем, поиск аномалий и грязных данных в источнике, необходимо исправить данные в учетных системах до того как данные начнут попадать в хранилище данных • Разработчик процессов загрузки должен совместно с аналитиком и архитектором хранилища данных пройти все шаги преобразования данных • Физическая модель данных должна быть готова, база данных хранилища данных или витрины данных должна быть развернута • Необходимо убедиться в правильности расчетной модели заложенной аналитиком прежде чем приступать к разработке процессов загрузки
- 15. Карта преобразований Таблица вкоторой представлены • Название целевой таблицы. • Физическое имя таблицы, которое отображается в хранилище данных • Название целевого столбца. • Имя столбца в таблице хранилища данных • Тип таблицы. • Указывает, является ли таблица фактом или измерением • Если измерение то какой тип SCD (медленно меняющийся размерности). • Для размеров этот компонент указывает на медленно изменяющийся размерный подход Type-1, -2 или -3. Этот индикатор может меняться для каждого столбца измерения. • Исходная база данных. • Имя экземпляра базы данных, в которой находятся исходные данные, • строка соединения для подключения к базе данных. • имя файла, которое оно отображается в файловой системе • Имя исходной таблицы. • Имя таблицы, в которой происходят исходные данные. перечислите все таблицы, необходимые для получения таблицы в целевом хранилище данных. • Имя исходного столбца. • Столбец или столбцы, необходимые для заполнения целевой таблицы. Связи исходных столбцов документируются в разделе преобразования. • Преобразования. • Точное преобразование, необходимое для исходных данных, что бы получить данные для целевых таблиц. Обычно обозначается в SQL запросе или псевдокоде.
- 16. Карта преобразований Целевая таблицаИсточник данных Преобразование Наименование таблицы Наименование поля таблицы Тип поля таблицы Наименование таблицы Наименование поля таблицы Тип поля таблицы • Карта преобразований – критически важная часть планирования разработки процессов загрузки данных • Основная цель этого документа - предоставить разработчику ETL четкую схему именно того, что ожидается от процесса ETL
- 17. Построение логической карты преобразований •Преобразование может содержать что угодно: от абсолютного решения до ничего. Чаще всего преобразование может быть выражено в SQL. • Анализ исходной системы обычно разбивается на две основные фазы: • Фаза обнаружения данных • Фаза обнаружения аномалии
- 18. Фаза обнаружения данных/ исследование источника • Обнаружение данных – это ключевой критерий успеха • Если у вас есть модель данных целевой системы вам необходимо приступить к определению источника данных • Сбор и документирование информации об источнике данных • Определение владельцев учетных систем, кто несет за них ответственность
- 19. Отчет об источникахданных • Предметная область. • Наименование системы / подсистемы • Бизнес наименование, как именуют систему бизнес-пользователи • Приоритет системы в хранилище данных • Департамент / отдел использующий систему • Руководитель департамента / отдела который пользуется этой системой • Технический владелец. Кто занимается сопровождением системы, отвечает за ее работоспособность • База данных, СУБД (oracle, ms sql server и т.д.) • Промышленный сервер / ОС. Физическое имя сервера с базой денных, операционная система • Кол-во пользователей системы • Размер БД. Администратор базы данных должен иметь возможность предоставить эту информацию. • Сложность БД. Количество таблиц в системе • Кол-во транзакций в день • Общие наблюдения в виде текста, обнаруженные на этапе обследования источника данных
- 20. Мастер данные (System-of-Record) •Часто предприятие имеет несколько систем в которых данные дублируют друг друга • Одни и те же данные перемещаются из одной системы в другую, при этом происходит трансформация первоначальных данных • Важно определить систему – источник первичных данных • Источник первичных данных не всегда можно использовать как мастер данные, в этом случае данные придется согласовывать из нескольких источников
- 21. Анализ исходных данных •Создание E/R диаграммы исходной системы • Анализ созданной E/R диаграммы • Уникальные идентификаторы и натуральные ключи • Типы данных • Связи между таблицами • Дискретность отношений (как вариант - одна таблица справочник хранит все справочники системы) • Кардинальность связей таблиц • Один к одному • Один ко многим • Многие ко многим
- 22. Анализ содержимого таблицисходных данных • Понимание содержания данных имеет решающее значение для определения наилучшего подхода для извлечения данных из источника • Поиск NULL значений в т.ч. во внешних ключах, разработка правил обработки таких данных • Даты в недетерминированных полях - не [date] / [datetime] Часто даты в системах хранят в виде строки разного формата, на этапе преобразования нужно понимать правила их обработки
- 23. Определение бизнес-правил • Существуютбизнес правила, которые необходимо применять при обработке входных данных • При обнаружении аномалий в данных требуется дополнительная обработка с учетом бизнес-правил от требований пользователей
- 24. Интеграция гетерогенных источников •Определение источников данных • Анализ источников данных, поиск аномалий, проблем с качеством данных • Разработать алгоритмы сопоставления сущностей разных источников • Определение мастер системы для одной и той же сущности • Определение бизнес-правил для атрибутов без ключа, атрибуты сущностей не из мастер системы, определение связей • Разработка правил загрузки согласованных измерений
- 25. Поиск измененных данныхв источнике (поиск дельты) • В исходной системе в таблицу добавляется столбец, который содержит дату и время изменения строки • Необходимо убедиться, что такой столбец не содержит NULL • Следует избегать опоры только на период (текущий день -1) из за возможной потери дня при сбое процессов загрузки, логика должна быть сложнее • Определение изменений на основе анализа логов базы данных системы источника • Сравнение с данными предыдущей загрузки, хранение истории • Первоначальная загрузка и загрузка по расписанию (инкрементальная) • Это два разных процесса, необходимо разрабатывать процессы под каждую загрузку отдельно • Первоначальная загрузка не требует обнаружения изменений в источнике данных
- 26. Советы • Если используетев SQL запросах WHERE и JOIN просите владельца системы источника добавить индексы к таблицам, которые ускорят выборку данных • Загружайте из источника только необходимые данные • Старайтесь не использовать DISTINCT • Используйте UNION, MINUS и INTERSET только там, где это необходимо (UNION ALL быстрее UNION, но может давать дубли) • Если есть возможность, используйте HINT в запросах • Избегайте в запросах конструкции NOT IN, этот влечет за собой полное сканирование таблицы источника данных • Избегайте функций и преобразований внутри WHERE
- 27. Поиск удаленных илиперезаписанных данных • Одна из самых сложных задач для хранилища данных т.к. это требует повторного извлечения записей и в некоторых случаях полного пересчета витрины • Рекомендации: • Договориться с владельцем системы источника явно помечать удаленные записи н.р. добавлением колонки IsDeleded=1 • Периодически сверять суммы итогов в источнике данных и в витрине данных, для поиска изменений
- 28. Очистка и согласованиеданных
- 29. Качество данных (DataQuality) • Корректность. Данные не должны содержать ошибок • Однозначность. Описание должно иметь только одно значение • Последовательность. Например код города должен соответствовать его наименованию • Полнота данных • Не должно быть пустых значений • Строки не потеряны в потоке преобразования данных
- 30. Балансировка качества данныхи целей проектирования • Подсистема качества дынных не должна вносить собственных ошибок • Подсистема качества данных должна быть быстрой • Самый правильный способ исправления проблемы качества данных – исправить данные в источнике • Преобразования должны быть прозрачными, должен быть понятен источник ошибки в данных
- 31. Проверки качества данных •Проверка атрибутов • Проверка структуры • Проверка данных • Проверка значений
- 32. Проверка атрибутов • Проверкана NULL • Проверка числовых значений по диапазону от минимального до максимального • Проверка символьных строк на аномалии – неожиданно короткая или длинная строка • Проверка значений на соответствие заранее определенному набору значений • Проверка значений по определенным шаблонам • Поиск и замена заранее определенных неправильных значений • Проверка орфографии
- 33. Проверка структуры • Проверкаструктуры таблиц • Проверка ссылочной целостности • Проверка структуры родитель-потомок • Каждый потомок имеет родителя • Каждый потомок имеет только одного родителя
- 34. Проверка данных изначений • Логические проверки данных например: • Соблюдение лимитов платежа • Входящий остаток банковской выписки равен исходящему остатку предыдущей банковской выписки • Порядковые номера банковских выписок не нарушены т.е. нет пропусков • Расчетный исходящий остаток банковской выписки равен исходящему остатку, указанному в заголовке
- 35. Обработка ошибок • Типичнаяорганизация иерархии таблиц логирования загрузки данных • Сессия загрузки (старт по расписанию, одна сессия на все источники данных) • Процесс загрузки (загрузка из источника, один источник один процесс) • Джоб загрузки (загрузка таблицы источника) • Ошибки загрузки (журнал ошибок) • Действия исходя из результата проверки • Фатальная ошибка джоба загрузки – запись в журнал ошибок, остановка процесса загрузки • Не фатальная ошибка джоба загрузки – запись в журнал ошибок, продолжение процесса загрузки
- 36.
- 37.
- 38.
- 39. Загрузка измерений • Суррогатныйключ – это первичный ключ измерения • Суррогатный ключ назначается на этапе загрузки данных изменять его вне процесса загрузки нельзя • Измерение – это денормализованная плоская таблица, строки которой уникальны и связаны с первичным ключом • Измерение должно содержать одно поле или комбинацию полей, которое определяет натуральный ключ
- 40. Загрузка таблиц измерений ОчисткаСогласование Загрузка
- 41. Медленно меняющееся измерениятип 1 Данные из ХД Lookup Данные из источника Поиск по натуральному ключу Строка найдена Присвоить новый суррогатный ключ, вставить строку в таблицу Обновить строку в таблице Нет Да
- 42. Медленно меняющееся измерениятип 2 Данные из ХД Lookup Данные из источника Поиск по натуральному ключу активной строки Строка найдена Присвоить новый суррогатный ключ, вставить строку в таблицу Обновить строку в таблице ХД, сделать строку неактивной Нет Да Присвоить новый суррогатный ключ, вставить строку в таблицу, сделать активной В строке есть изменения Нет Да
- 43. Медленно меняющееся измерениятип 3 Данные из ХД Lookup Данные из источника Поиск по натуральному ключу активной строки Строка найдена Присвоить новый суррогатный ключ, вставить строку в таблицу Обновить строку в таблице ХД, новые данные в текущее значение, старые данные в предыдущие значения Нет Да В строке есть изменения Нет Да
- 44. Позднее связывание • Поместитьстроку фактов в таблицу ожидания до тех пор, пока не придут данные в таблицу измерения • Недостаток решения – факты не попадают в отчет, пока не придут данные по измерениям
- 45. Позднее связывание • Записьстроки факта на «неопределенно» • После обновления измерения обновляется строка факта • Строки с «неопределенно» так же можно помещать в таблицу- ожидания
- 46. Позднее связывание • Добавлятьв таблицу измерения новую строку с новым суррогатным ключом, заполнить атрибуты измерения значениями по умолчанию • После прихода строки измерения – обновить атрибуты измерения согласно алгоритмам для SCD 1 или 3
- 47. Позднее связывание SCD2 • В самом начале имеем одну строку таблицы измерения и два документа в таблице факта • Строка измерения была разделена на две строки в зависимости от состояния справочника на дату • Строка таблицы факта «восстанавливается» на дату актуальной строки измерения
- 48. Позднее связывание SCD2. Изменения задним числом • Вставка новой строки в измерение, с новым суррогатным ключом • Поиск строк «перед», изменение даты окончания • Поиск срок «после», изменение атрибутов соответствующих изменениям задним числом • Строка таблицы факта «восстанавливается» на дату актуальной строки измерения
- 49. Многие ко многим,таблицы-мост • Факт продажи одного продукта может быть осуществлен под разными маркетинговыми компаниями • Для того, что бы показать данные в разрезах не продуктов а маркетинговых компаний необходимо построить таблицу-мост связи продуктов и маркетинговых компаний
- 50.
- 51.
- 52. Обеспечение ссылочной целостности •Каждая строка факта должна ссылаться на все измерения, не должно быть «пустых» ссылок или left join с таблицей измерения • Для того, что бы избежать «пустых» ссылок необходимо: • Проверка целостности данных на этапе подготовки данных • Не привязанные данные или не грузятся в таблицу факта или загружаются на строку «неопределенно» измерения (-1)
- 53. Привязка факта ксуррогатным ключам измерения • Основной процесс загрузки факта – это преобразования натуральных ключей факта в суррогатные ключи измерения
- 54. Транзакционные факты • Транзакционныефакты содержат данные о событиях
- 55. Периодические снимки данных •Периодический снимок – это промежуток времени, который регулярно повторяется н.р. месяц • Хорошо подходят для данных о длительных процессах, финансовых данных
- 56. Накопительные снимки данных •Используются для процессов, которые имеют начало и конец • Не подходят для длительного непрерывного процесса • Обычно имеют несколько ссылок на таблицу Календарь • Факты в таких таблицах перезаписываются по мере происхождения события
- 57. Factless Fact • Фактыбез мер, содержат данные о каком либо событии, которое не имеет числовых характеристик, н.р. маркетинговые акции
- 58. Загрузка таблиц фактов,позднее связывание • При загрузке записи факта необходимо провести поиск соответствующей истории таблицы измерений, чтобы найти соответствующий суррогатный ключ, который действует на момент возникновения факта.
- 59. Литература • Kimball &Caserta The Data Warehouse ETL Toolkit
Editor's Notes
- #48 Как описано выше, мы можем обрабатывать последнее прибывающее измерение, сохраняя запись измерения «Неизвестная» или запись «Измеряемая», которая действует как заполнитель. Даже до того, как мы получим подробные данные о полном размере из исходной системы, может быть несколько изменений типа SCD Type 2 в записи измерения замещающего. Это приводит к созданию новой записи измерений с новым суррогатным ключом и модификации любого последующего факта, записывающего суррогатный ключ, чтобы указать новый суррогатный ключ. Давайте посмотрим на сценарий подробно с помощью примера медицинского страхования. Пациент с ID 67223 сделал два страховых требования. Один на 9/10 и другие на 9/20. Поскольку информация о пациенте отсутствует для пациента id 67223, для пациента с суррогатным ключом 1001 создана запись измерения «Inferred». Ниже показано состояние размерности и таблицы фактов в этой точке. Позже, к тому времени, когда информация о времени была доступна, уже были изменения типа SCD Type 2 для идентификатора пациента 67223. Были изменения для пациента с номером 67223 по 9/10 и снова 9/12. Ниже показано текущее состояние измерений и записей фактов. Запись факта, созданная на 9/20, все еще имеет в виду суррогатный ключ 1001, который не является правильным представлением. Это означает, что запись заявки, созданная на 9/20, должна быть переназначена на правильный ключ суррогата, который активен за тот же период времени. Ниже показано правильное состояние измерений и записей фактов.
- #49 Позднее связывание с изменениями задним числом Вы можете получать записи измерений из исходной системы с ретро-эффективными датами. Например, вы можете обновить свое семейное положение в своей системе управления персоналом позднее даты вступления в брак. Это обновление поступает в хранилище данных с датой вступления в силу. Это приводит к новой записи измерений с новым суррогатным ключом и изменениям эффективных дат для затронутого измерения. Вам придется сканировать вперед в измерении, чтобы увидеть, есть ли последующие строки типа 2 для этого измерения. Это дополнительно приводит к изменению любого последующего факта, записывающего суррогатный ключ, чтобы указать новый суррогатный ключ. Позвольте снова использовать пример страхового возмещения для нашего объяснения. Ниже показано состояние пациента и таблица фактов претензий в этот момент, что совершенно хорошо. Эти новые данные измерений, которые поставляются с датой вступления в силу, делают все записи измерений не синхронизированными с точки зрения эффективной даты начала и окончания. В дополнение к этому записи фактов относятся к неправильным записям измерений. Поэтому в дополнение к вставке новой записи измерений с новым суррогатным ключом нам придется корректировать эффективные даты записи измерения предыдущего периода и распространять изменения значения столбца измерения на оставшиеся записи. Таблицу фактов также необходимо обновить, чтобы переназначить правильный ключ суррогата