1) Разругаться с заказчиком за дополнительную оплату изменений и затянуть сроки реализации, при этом оплата по договору будет также задерживаться заказчиком.
2) Оценить изменения, если они укладываются в риски проекта, сообщить об этом заказчику и внести изменения. При этом оплата договора пройдет быстрее.
Кажется, что путь очевиден, но в реальности эмоции часто выходят на первый план и портят взаимоотношения между заказчиком и исполнителем.
В этой статье речь идет о DQ на большом хранилище данных, Ростелеком - огромная компания с большим массивом данных.
"Это правда - действительно будет сверяться со всей таблицей.Не знаю как на счет сотни миллиардов строк - но проверка 200 млн строк происходит за 2 минуты. "
Я хочу сказать, что использование уникального ключа в большинстве случаев не является хорошим советом для таблиц DWH с нагрузкой OLAP.
Использование ресурсов системы при вставке в таблицу с уникальным ключом, в особенности при построчном хранении или, в случае, если уникальный ключ является составным при колоночном хранении, будет значительным, при этом таких таблиц может быть много. Это может привести к увеличению времени доставки данных до пользователей или вовсе к "падению" процессов вставки данных в витрину.
"ну тогда Вы найдете дубль только в Рамках дня.А если Вам надо не допустить дубли в таблице .... то партиции приведут к печали. Потому что к каждой партиции будет обращение как к отдельной таблице. То есть если есть сканирование индекса - то в пориционной таблице за год, будет 365 сканирований индекса. И профита нету .... но есть торможение "
Индексы в DWH - это скорее исключение из правил, как и отсутствие партиционирования. Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами, а проверка всей таблицы на дубли при ежедневной загрузке данных скорее всего не будет иметь никакого смысла.
"Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут.
Если использовать уникальный ключ, то каждая загружаемая строка будет сверяться со всеми строками в таблице. При таком подходе скорость загрузки падает катастрофически, в особенности, если набор данных под сотню миллиардов строк.
Сама проверка на дубли может выполняться ежедневно над дневной "партицией"
Добрый день!
1) Правильно ли я понимаю, что все, кто купил ранее лицензию CDH должны покупать новую на CDP?
2) Ранее у вас была бесплатная редакция CDH, многие ей пользуются. В текущей ситуации с закрытием бесплатного дистрибутива получается, что пользователь на express должен искать альтернативу CDH или покупать лицензию и мигрировать в CDP. Как при таком рваном векторе развития продукта можно ему доверять?
Когда в ТЗ нужно внести правки есть 2 пути:
1) Разругаться с заказчиком за дополнительную оплату изменений и затянуть сроки реализации, при этом оплата по договору будет также задерживаться заказчиком.
2) Оценить изменения, если они укладываются в риски проекта, сообщить об этом заказчику и внести изменения. При этом оплата договора пройдет быстрее.
Кажется, что путь очевиден, но в реальности эмоции часто выходят на первый план и портят взаимоотношения между заказчиком и исполнителем.
В этой статье речь идет о DQ на большом хранилище данных, Ростелеком - огромная компания с большим массивом данных.
"Это правда - действительно будет сверяться со всей таблицей.Не знаю как на счет сотни миллиардов строк - но проверка 200 млн строк происходит за 2 минуты. "
Я хочу сказать, что использование уникального ключа в большинстве случаев не является хорошим советом для таблиц DWH с нагрузкой OLAP.
Использование ресурсов системы при вставке в таблицу с уникальным ключом, в особенности при построчном хранении или, в случае, если уникальный ключ является составным при колоночном хранении, будет значительным, при этом таких таблиц может быть много. Это может привести к увеличению времени доставки данных до пользователей или вовсе к "падению" процессов вставки данных в витрину.
"ну тогда Вы найдете дубль только в Рамках дня.А если Вам надо не допустить дубли в таблице .... то партиции приведут к печали. Потому что к каждой партиции будет обращение как к отдельной таблице. То есть если есть сканирование индекса - то в пориционной таблице за год, будет 365 сканирований индекса. И профита нету .... но есть торможение "
Индексы в DWH - это скорее исключение из правил, как и отсутствие партиционирования. Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами, а проверка всей таблицы на дубли при ежедневной загрузке данных скорее всего не будет иметь никакого смысла.
"Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут.
Если использовать уникальный ключ, то каждая загружаемая строка будет сверяться со всеми строками в таблице. При таком подходе скорость загрузки падает катастрофически, в особенности, если набор данных под сотню миллиардов строк.
Сама проверка на дубли может выполняться ежедневно над дневной "партицией"
Добрый день!
1) Правильно ли я понимаю, что все, кто купил ранее лицензию CDH должны покупать новую на CDP?
2) Ранее у вас была бесплатная редакция CDH, многие ей пользуются. В текущей ситуации с закрытием бесплатного дистрибутива получается, что пользователь на express должен искать альтернативу CDH или покупать лицензию и мигрировать в CDP. Как при таком рваном векторе развития продукта можно ему доверять?