Комментарии 4
произошедшие за последние два года в немаленьком хранилищеа в циферках «немаленькое» — это сколько?
Название сочное, хаб «Big Data» вызывающе предвещает нам многонодное хранилище вокруг которого наверчен
PS: хаб «BD», имхо, лишний
Вы правы, циферки имеют смысл.
Классификация ошибок проведена в хранилище с характеристиками:
Big Data часто используется как собирательный термин для цифровых технологий обработки данных. Описанные методы относят к традиционным способам. Да, имеет смысл убрать их из BG.
Энтерпрайзные инструменты быстро себя исчерпывают и приходится в них мастерить жуткие «велосипеды».
SQLite и старенький ноутбук — это ирония, это история «велосипедов», очень многие — не собственные, рождённые в больших коллективах.
Однако, простейшие методы и SQLite показывают результат: 113тыс. записей в секунду, из сырых данных до агрегатов. Не дурно, потому как в энтерпрайзе мы долго к этому идём.
Считаете, что статья про организацию технических средств и команды в условиях энтерпрайза будет не скучной?
Чтобы посты не заминусовали представители энтерпрайза, я решил сосредоточиться на описании методов абстрактными и примитивными средствами, и понятии эффективность.
Классификация ошибок проведена в хранилище с характеристиками:
- подключено 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. с течением времени улучшаем качество данных и понижаем допускаемые пределы ошибок, чтобы повысить качество данных
Т.е. уже архитектура 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 уровням вложений, когда нужно найти свой пакет.
Это я называю издевательством над человеческой сущностью. Пока докликаешь до нужного объекта, уже забываешь, что хотел проверить.
Когда количество целевых таблиц стремится к сотне, то процесс сопровождения становится весьма неэффективным.
На практике, использование встроенных функций и процедур для хранения ETL(SQL запросов) в самой базе данных показывает лучший результат. Это относится к большим и дорогим базам данных. В случае MySQL или Sqlite эти же запросы можно хранить в файлах.
Хранимые функции или SQL запросы позволяют себя сохранять в виде обычных файлов с исходным кодом и замечательным образом версионировать, используя git или svn.
Энтерпрайз решения позволяют экспортировать результаты в виде xml или использовать встроенные средства версионирования. В оперативной работе это всё снова приводит к бесконечному количеству бессмысленных движений и кликов, потому что нужно импортировать и искать.
Всё тоже самое с мониторингом ETL. Много отвлекающей и часто лишней информации, много оперативного времени тратится на лишние и ненужные движения.
Когда-то давно описанные энтерпрайз продукты были просто интеграторами и функцию эту они выполняют отлично. Со временем в них встроили возможность создания ETL и это был маркетинговый ход.
Подобные инструменты — могут быть хорошими для интеграции данных, у них много коннекторов. Но почти всегда я сталкивался с необходимостью строить «велосипеды», если источник данных был чуть-чуть «другим», например,
— Нужно интегрировать xml, но xsd к нему нет, да ещё могут быть ошибки. Нужно парсить.
— Нужно по FTP забрать файлы и что-то отметить, а не все команды FTP поддерживаются (ODI).
— Нужно интегрировать много разных файлов — настройка схемы файла очень утомительна.
— Какая-нибудь странная база, где используются jdbc или odbc. Это так медленно, что проще выгружать в файл, перевозить и снова читать.
ETL в реляционной базе данных — это набор инструкций SQL, последовательно или параллельно выполнямых. SSIS и ODI предлагают нам настолько развитую объектную схему, что это приводит к 7 уровням вложений, когда нужно найти свой пакет.
Это я называю издевательством над человеческой сущностью. Пока докликаешь до нужного объекта, уже забываешь, что хотел проверить.
Когда количество целевых таблиц стремится к сотне, то процесс сопровождения становится весьма неэффективным.
На практике, использование встроенных функций и процедур для хранения ETL(SQL запросов) в самой базе данных показывает лучший результат. Это относится к большим и дорогим базам данных. В случае MySQL или Sqlite эти же запросы можно хранить в файлах.
Хранимые функции или SQL запросы позволяют себя сохранять в виде обычных файлов с исходным кодом и замечательным образом версионировать, используя git или svn.
Энтерпрайз решения позволяют экспортировать результаты в виде xml или использовать встроенные средства версионирования. В оперативной работе это всё снова приводит к бесконечному количеству бессмысленных движений и кликов, потому что нужно импортировать и искать.
Всё тоже самое с мониторингом ETL. Много отвлекающей и часто лишней информации, много оперативного времени тратится на лишние и ненужные движения.
Когда-то давно описанные энтерпрайз продукты были просто интеграторами и функцию эту они выполняют отлично. Со временем в них встроили возможность создания ETL и это был маркетинговый ход.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг ETL-процессов в маленьком хранилище данных