Открыть список
Как стать автором
Обновить

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

произошедшие за последние два года в немаленьком хранилище
а в циферках «немаленькое» — это сколько?

Название сочное, хаб «Big Data» вызывающе предвещает нам многонодное хранилище вокруг которого наверчен кровавоэнтерпрайзный ETL, и рядом же SQLite… Big Data на мамином ноутбуке и мониторинг ETL процессов к ней? Не обижайтесь пожалуйста, но описывая мониторинг ETL, для начала полезно бы описать решение в целом. В статьях 2-х месячной давности Вы писали о «маленьком» хранилище и собственных велосипедах к нему…

PS: хаб «BD», имхо, лишний
Вы правы, циферки имеют смысл.
Классификация ошибок проведена в хранилище с характеристиками:

  • подключено 20 источников данных,
  • ежедневно обрабатывается 10.5 миллиардов строк,
  • которые агрегируются до 50 миллионов строк,
  • данные обрабатывают 140 пакетов в 700 шагов (шаг — это один sql запрос)
  • железяка 4х нодная X5

Big Data часто используется как собирательный термин для цифровых технологий обработки данных. Описанные методы относят к традиционным способам. Да, имеет смысл убрать их из BG.

Энтерпрайзные инструменты быстро себя исчерпывают и приходится в них мастерить жуткие «велосипеды».
SQLite и старенький ноутбук — это ирония, это история «велосипедов», очень многие — не собственные, рождённые в больших коллективах.

Однако, простейшие методы и SQLite показывают результат: 113тыс. записей в секунду, из сырых данных до агрегатов. Не дурно, потому как в энтерпрайзе мы долго к этому идём.

… мониторинг ETL, для начала полезно бы описать решение в целом

Считаете, что статья про организацию технических средств и команды в условиях энтерпрайза будет не скучной?

Чтобы посты не заминусовали представители энтерпрайза, я решил сосредоточиться на описании методов абстрактными и примитивными средствами, и понятии эффективность.
в SSIS в любом компоненте есть Success Flow и Error Flow.
Т.е. уже архитектура ETL обязывает заранее планировать какие ошибки следует ожидать и как их следует обрабатывать.
по моему опыту:
если ваш ETL записыват в таблицу TableName, то весь Error Flow всегда надо записывать в отдельную TableName_Error таблицу и любое BI решение визуализирует в реалтайме возникающие ошибки в каждом выполненном пакете (batch).

1. сначала ищем все таблицы с названием _Error
2. считаем статистику — сколько строк в каждой таблице ошибок, какие типы ошибки самые частый (топ-3)
3. визуализируем циферки в тренд-графике, смотрим на outliers — случаи когда количество ошибок выходит за установленные пределы (либо в процентах к успешно загруженным данным, либо к статистике предыдущих месяцев)
4. точечно фокусируемся на зафейленных ETLах
5. с течением времени улучшаем качество данных и понижаем допускаемые пределы ошибок, чтобы повысить качество данных

Спасибо за комментарий. SSIS и ODI практически один и тот же инструмент, даже названия в дереве объектов одинаковые. Только ODI застрял в «каменном веке».

Подобные инструменты — могут быть хорошими для интеграции данных, у них много коннекторов. Но почти всегда я сталкивался с необходимостью строить «велосипеды», если источник данных был чуть-чуть «другим», например,
— Нужно интегрировать xml, но xsd к нему нет, да ещё могут быть ошибки. Нужно парсить.
— Нужно по FTP забрать файлы и что-то отметить, а не все команды FTP поддерживаются (ODI).
— Нужно интегрировать много разных файлов — настройка схемы файла очень утомительна.
— Какая-нибудь странная база, где используются jdbc или odbc. Это так медленно, что проще выгружать в файл, перевозить и снова читать.

ETL в реляционной базе данных — это набор инструкций SQL, последовательно или параллельно выполнямых. SSIS и ODI предлагают нам настолько развитую объектную схему, что это приводит к 7 уровням вложений, когда нужно найти свой пакет.
image
Это я называю издевательством над человеческой сущностью. Пока докликаешь до нужного объекта, уже забываешь, что хотел проверить.
Когда количество целевых таблиц стремится к сотне, то процесс сопровождения становится весьма неэффективным.

На практике, использование встроенных функций и процедур для хранения ETL(SQL запросов) в самой базе данных показывает лучший результат. Это относится к большим и дорогим базам данных. В случае MySQL или Sqlite эти же запросы можно хранить в файлах.

Хранимые функции или SQL запросы позволяют себя сохранять в виде обычных файлов с исходным кодом и замечательным образом версионировать, используя git или svn.

Энтерпрайз решения позволяют экспортировать результаты в виде xml или использовать встроенные средства версионирования. В оперативной работе это всё снова приводит к бесконечному количеству бессмысленных движений и кликов, потому что нужно импортировать и искать.

Всё тоже самое с мониторингом ETL. Много отвлекающей и часто лишней информации, много оперативного времени тратится на лишние и ненужные движения.
Когда-то давно описанные энтерпрайз продукты были просто интеграторами и функцию эту они выполняют отлично. Со временем в них встроили возможность создания ETL и это был маркетинговый ход.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.