Комментарии 9
И всё же, как нам говорят правила (и лингвисты), "Контроль качества данных, и точка."Повторяя за другими — не повторяйте их ошибок.
Где та тонкая грань, когда проверка начинает съедать больше ресурсов, чем рабочая нагрузка? :)
Какая же садомия ....
"Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут.
"За выполнение проверки отвечает универсальный python-скрипт," - точно, именно так всё работает ....
я часто встречаю подобные теории:
"На планете земля есть Гугл, Майкрософт, Apple, Yandex, IBM ... и у всех нет универсального скрипта!
Но! нам повезло! У нас Федор Гавнюков, самородок земли Русской. Сделает Универсальный загрузчик, универсальный чек таблиц, универсальный мониторинг, универсальный отчет и тд... " .... каждый раз одно и тоже .... сделают "космолет" потом появится не стандартный кейс - а чел уже уволился! что будем делать ? Конечно же Универсальнй мониторинг! А что бы Универсальное что-то отрабатывало разные кейсы - сделаем таблицу в базе в которой пропишем все параметры! .....
"Проверкой (check) называется именованный абстрактный объект, к которому привязаны один или несколько SQL-запросов, правила обработки результата для каждого запроса, параметры, конфигурации подключения к ХД, список объектов ХД, к которым можно применить проверку и т.д. Всё это хранится в настроечных таблицах отдельной БД."
Вы количество людей и время потраченное ими на создание этой системы посчитали?
может быть проще найти причину почему "пропадают строчки" и решить эту проблему ?
"....то инструмент профилирования мы тоже решили разработать свой. "
я всё понял.
Ичары сказали - "Надо что то написать на Хабре для ИТ имиджа"
вот так и получилась статья ....
А по тексту - Там у Вас вообще кто нибудь работает или все только утилиты пишут ?
У меня тоже было дофига ошибок. Но потом я их все поправил, одну за одной, методично и долго. - и сейчас всё ок - нет необходимости в подобной инфраструктуре.....
>>>"Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут. <<<
А как решили вопрос с исправлениями дублей? Многие приходят из источника и появляются они там не волшебным способом, а после ввода оператором (например). И если компания насчитывает более 1000 человек в штате, то найти ответственного за исправление может быть не просто. Тут или решать вопрос кардинально, все кривые данные не загружать или заранее знать (вы верно подметили, что люди увольняются) кому переадресовать исправление данных
А как решили вопрос с исправлениями дублей?
в каждом случае по разному.
Но общий кейс такой:
Допустим получилось так что один клиент два раза обращается за услугой - и от него приходят две анкеты. (Идентификатор клиента 1 - А анкеты у клиента 2 - обе актуальные)
в этом случае я в слой Load (куда загружают данные 1 в 1 как в источнике) оставляю дубли - это нужно на случай разборок.
а при переливе в слой Stage (где уже дополненые и готовые для построения витрин данные) - переливаю последнюю по дате анкету.
И примерно так в каждом случае создается такой костылек.
"Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут.
Если использовать уникальный ключ, то каждая загружаемая строка будет сверяться со всеми строками в таблице. При таком подходе скорость загрузки падает катастрофически, в особенности, если набор данных под сотню миллиардов строк.
Сама проверка на дубли может выполняться ежедневно над дневной "партицией"
"Если использовать уникальный ключ, то каждая загружаемая строка будет сверяться со всеми строками в таблице."
Это правда - действительно будет сверяться со всей таблицей.
Не знаю как на счет сотни миллиардов строк - но проверка 200 млн строк происходит за 2 минуты.
"Сама проверка на дубли может выполняться ежедневно над дневной "партицией" "
ну тогда Вы найдете дубль только в Рамках дня.
А если Вам надо не допустить дубли в таблице .... то партиции приведут к печали. Потому что к каждой партиции будет обращение как к отдельной таблице. То есть если есть сканирование индекса - то в пориционной таблице за год, будет 365 сканирований индекса. И профита нету .... но есть торможение
В этой статье речь идет о DQ на большом хранилище данных, Ростелеком - огромная компания с большим массивом данных.
"Это правда - действительно будет сверяться со всей таблицей.Не знаю как на счет сотни миллиардов строк - но проверка 200 млн строк происходит за 2 минуты. "
Я хочу сказать, что использование уникального ключа в большинстве случаев не является хорошим советом для таблиц DWH с нагрузкой OLAP.
Использование ресурсов системы при вставке в таблицу с уникальным ключом, в особенности при построчном хранении или, в случае, если уникальный ключ является составным при колоночном хранении, будет значительным, при этом таких таблиц может быть много. Это может привести к увеличению времени доставки данных до пользователей или вовсе к "падению" процессов вставки данных в витрину.
"ну тогда Вы найдете дубль только в Рамках дня.А если Вам надо не допустить дубли в таблице .... то партиции приведут к печали. Потому что к каждой партиции будет обращение как к отдельной таблице. То есть если есть сканирование индекса - то в пориционной таблице за год, будет 365 сканирований индекса. И профита нету .... но есть торможение "
Индексы в DWH - это скорее исключение из правил, как и отсутствие партиционирования. Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами, а проверка всей таблицы на дубли при ежедневной загрузке данных скорее всего не будет иметь никакого смысла.
"Я хочу сказать, что использование уникального ключа в большинстве случаев не является хорошим советом для таблиц DWH с нагрузкой OLAP."(c)
Погодите :)
Давайте "Мухи отдельно - Котлеты отдельно" Олап это Кубы (которые процессятся в ночи). Тот кто думает получить агрегацию данных из обыкновенных таблиц - получит ее это называется ROLAP, но будет значительно медленнее. и в Контексте Ролап Вы правы. Но и само ожидание больших скоростей от "таблиц с нагрузкой OLAP" = неправильно.
"будет значительным, при этом таких таблиц может быть много." Не правда.
Потому что ключи это Индексы - индексы хранятся в страницах. Поэтому что бы вставить строчку с Ключём 100 вам надо задействовать диапазон страниц в которых данные от 95 до 105 (примерно) это будет не Вся таблица. а только несколько страниц из близлижайших диапазонов .
Задержка будет - но она будет незначительной по сравнению с тем что бы проверить на уникальность строки каким либо другим способом (как всегда способ один Row_Number).
"Индексы в DWH - это скорее исключение из правил, как и отсутствие партиционирования. Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами, а проверка всей таблицы на дубли при ежедневной загрузке данных скорее всего не будет иметь никакого смысла."(с)
Ну уж нет :)
Индексы это правило на DWH - так как после получения данных от источника - Вы создаете Витрины - А это Селекты, Много Много Селектов - ускорить их можно индексами.
Те же самые ОЛАПы будут просить список Уникальных значений справочников (Измерений). Ускорить сбор куба можно индексом по полю справочника.
Без Индексов - у Вас будет всё ужасно медленно :)
Загрузка быстрее - а сбор витрин = смерти подобное действо.
"как и отсутствие партиционирования" - наверно я прошлый раз не совсем доходчево сказал :)
Ок пример:
У Вас гигантская таблица - Кредит, Дата Операции
допустим - Вы секционируете по Кредиту. Приходит запрос где ищется по дате операции = Всё встало раком (потому что надо поднять все секции, и просмотреть все их индексы)
допустим Вы секционируете по Дате Операции. Приходит запрос где ищется по Номеру Кредита. = Опять Всё встало раком (опять таки потому что надо поднять все секции)
А если у Вас нет Секции - тогда делаете два индекса Один по Дате другой по номеру Кредита. И У Вас все летает. Потому что при любом запросе надо прочитать всего лишь одну секцию (саму таблицу) и соответвтующий ей индекс
Если секционирование ни как не используется (не переключаются, не архивируются, не транкетсятся, не переносятся на архивные диски) === Тогда Смысла в Секциях нету
"Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами"(с)
неа....
тот же самый пример с кредитами:
Вы в мобильнике нажали - перевести деньги.
А фактически перевод выполнился в другой день.
итого у Вас две строчки:
Одна за пятницу Вечер - создать перевод.
вторая за субботу утро - провести по бух учету этот перевод.
И если смотреть дубликаты в рамках дня - вы не увидите дублеж в балансе.
"на 99% вопрос с дубликатами"
достаточно всего 1 строчки, что бы Вы будучи руководителем начали изрядно кипятиться по поводу неверной отчёности :) Особенно если эта строчка связана с каким нибудь партнером - который прекрасно умеет считать свои средства :)
Контроль качества данных и точка. Как мы строили модуль DQM с нуля