согласно пункта 2 Культура 2 ===> Овна Кусок --- Быстро накодить тормозящий кусок овна, а потом еще выторговать себе сроки и бюджеты на оптимизацию .... ну такое .... ну на любителя.
Что это за программа ? :) Какие бонусы разработчикам? Могут ли стартапы участвовать ? Какое ПО может быть Игры - можно ? Утилиты ? :) Какая монитизация допускается и тд Расскажите про эту программу :)
На сколько я понимаю это поддержка Разработки ПО, для Аstra не могли бы Вы написать статью о самой программе, какой интерес разработчикам в нем участвовать и как подключиться к этой программе.
"Я хочу сказать, что использование уникального ключа в большинстве случаев не является хорошим советом для таблиц DWH с нагрузкой OLAP."(c)
Погодите :) Давайте "Мухи отдельно - Котлеты отдельно" Олап это Кубы (которые процессятся в ночи). Тот кто думает получить агрегацию данных из обыкновенных таблиц - получит ее это называется ROLAP, но будет значительно медленнее. и в Контексте Ролап Вы правы. Но и само ожидание больших скоростей от "таблиц с нагрузкой OLAP" = неправильно.
"будет значительным, при этом таких таблиц может быть много." Не правда. Потому что ключи это Индексы - индексы хранятся в страницах. Поэтому что бы вставить строчку с Ключём 100 вам надо задействовать диапазон страниц в которых данные от 95 до 105 (примерно) это будет не Вся таблица. а только несколько страниц из близлижайших диапазонов . Задержка будет - но она будет незначительной по сравнению с тем что бы проверить на уникальность строки каким либо другим способом (как всегда способ один Row_Number).
"Индексы в DWH - это скорее исключение из правил, как и отсутствие партиционирования. Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами, а проверка всей таблицы на дубли при ежедневной загрузке данных скорее всего не будет иметь никакого смысла."(с)
Ну уж нет :) Индексы это правило на DWH - так как после получения данных от источника - Вы создаете Витрины - А это Селекты, Много Много Селектов - ускорить их можно индексами. Те же самые ОЛАПы будут просить список Уникальных значений справочников (Измерений). Ускорить сбор куба можно индексом по полю справочника. Без Индексов - у Вас будет всё ужасно медленно :) Загрузка быстрее - а сбор витрин = смерти подобное действо.
"как и отсутствие партиционирования" - наверно я прошлый раз не совсем доходчево сказал :) Ок пример: У Вас гигантская таблица - Кредит, Дата Операции допустим - Вы секционируете по Кредиту. Приходит запрос где ищется по дате операции = Всё встало раком (потому что надо поднять все секции, и просмотреть все их индексы) допустим Вы секционируете по Дате Операции. Приходит запрос где ищется по Номеру Кредита. = Опять Всё встало раком (опять таки потому что надо поднять все секции)
А если у Вас нет Секции - тогда делаете два индекса Один по Дате другой по номеру Кредита. И У Вас все летает. Потому что при любом запросе надо прочитать всего лишь одну секцию (саму таблицу) и соответвтующий ей индекс
Если секционирование ни как не используется (не переключаются, не архивируются, не транкетсятся, не переносятся на архивные диски) === Тогда Смысла в Секциях нету
"Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами"(с) неа....
тот же самый пример с кредитами: Вы в мобильнике нажали - перевести деньги. А фактически перевод выполнился в другой день.
итого у Вас две строчки: Одна за пятницу Вечер - создать перевод. вторая за субботу утро - провести по бух учету этот перевод.
И если смотреть дубликаты в рамках дня - вы не увидите дублеж в балансе.
"на 99% вопрос с дубликатами" достаточно всего 1 строчки, что бы Вы будучи руководителем начали изрядно кипятиться по поводу неверной отчёности :) Особенно если эта строчка связана с каким нибудь партнером - который прекрасно умеет считать свои средства :)
"Если использовать уникальный ключ, то каждая загружаемая строка будет сверяться со всеми строками в таблице."
Это правда - действительно будет сверяться со всей таблицей. Не знаю как на счет сотни миллиардов строк - но проверка 200 млн строк происходит за 2 минуты.
"Сама проверка на дубли может выполняться ежедневно над дневной "партицией" " ну тогда Вы найдете дубль только в Рамках дня. А если Вам надо не допустить дубли в таблице .... то партиции приведут к печали. Потому что к каждой партиции будет обращение как к отдельной таблице. То есть если есть сканирование индекса - то в пориционной таблице за год, будет 365 сканирований индекса. И профита нету .... но есть торможение
в каждом случае по разному. Но общий кейс такой: Допустим получилось так что один клиент два раза обращается за услугой - и от него приходят две анкеты. (Идентификатор клиента 1 - А анкеты у клиента 2 - обе актуальные) в этом случае я в слой Load (куда загружают данные 1 в 1 как в источнике) оставляю дубли - это нужно на случай разборок. а при переливе в слой Stage (где уже дополненые и готовые для построения витрин данные) - переливаю последнюю по дате анкету. И примерно так в каждом случае создается такой костылек.
Какая же садомия .... "Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут.
"За выполнение проверки отвечает универсальный python-скрипт," - точно, именно так всё работает .... я часто встречаю подобные теории: "На планете земля есть Гугл, Майкрософт, Apple, Yandex, IBM ... и у всех нет универсального скрипта! Но! нам повезло! У нас Федор Гавнюков, самородок земли Русской. Сделает Универсальный загрузчик, универсальный чек таблиц, универсальный мониторинг, универсальный отчет и тд... " .... каждый раз одно и тоже .... сделают "космолет" потом появится не стандартный кейс - а чел уже уволился! что будем делать ? Конечно же Универсальнй мониторинг! А что бы Универсальное что-то отрабатывало разные кейсы - сделаем таблицу в базе в которой пропишем все параметры! .....
"Проверкой (check) называется именованный абстрактный объект, к которому привязаны один или несколько SQL-запросов, правила обработки результата для каждого запроса, параметры, конфигурации подключения к ХД, список объектов ХД, к которым можно применить проверку и т.д. Всё это хранится в настроечных таблицах отдельной БД." Вы количество людей и время потраченное ими на создание этой системы посчитали? может быть проще найти причину почему "пропадают строчки" и решить эту проблему ?
"....то инструмент профилирования мы тоже решили разработать свой. " я всё понял. Ичары сказали - "Надо что то написать на Хабре для ИТ имиджа" вот так и получилась статья ....
А по тексту - Там у Вас вообще кто нибудь работает или все только утилиты пишут ?
У меня тоже было дофига ошибок. Но потом я их все поправил, одну за одной, методично и долго. - и сейчас всё ок - нет необходимости в подобной инфраструктуре.....
Все зависит от задачи: если надо найти одну строку и в ней что то поискать - Ключ значение вполне подойдет если надо найти по атрибуту все строки - Wide-Column
Те кто пробуют искать что то внутри полей json .... ну такое на любителя.....
потому что у колонок есть фишки которых нет в Key Value - Тип данных - Статистика по колонке - Индексы
У нас есть SQL!
Мы его можем оформить в виде процедуры и дергать эту процедуру!
С мониторингом производительности и с возможностью быстрого изменения!
— Не… ну нафих…
мы будем использовать всякие ORM которые будут тормозить и мешать при изменении бизнес потребностей…
Г — Логика!
Осталось только выяснить кому нужен этот питон
— кодеров на Питоне пруд пруди, хоть отстреливай
— Аналитиков и могущих сделать что то на R не так много
Результат:
— Питонщики получают в два раза меньше чем спецы на R
Учи Питон — Будь нищебродом как все! :))))
Критикую решение не на .NET
— Мы сейчас делаем маленький проекторы поэтому Node.js, а если проект разростется — то и фиг с ним, гори огнем! Сей проект — кто нибудь на .NET перепилит
совет отключать индексы при больших загрузках это еще посчитать надо
— зальешь 50 кк строк без индексов, а дальше что?
А дальше — включай все индексы = полная перестройка — и где профит по времени и производительности?
А если таблица 3 ярда строк — а ты влил 50 кк — перестраивать индексы будет дороже
— Ограничения и так всегда отключены на работающих БД, а там где не отключены сделано специально для проверки корректности данных
В некотором смысле есть утилиты для ускорения
Например обфускатор от РейдГейта — не только запутывает код но и переводит «что то» на ассемблер — тем самым ускоряя работу дотнетовского экзешника
зачем нужна привязка к SQL-серверу? Почему нельзя тот же код использовать в R-сервере?
Можно использовать код где угодно :)
Однако, в этом варианте у Вас:
— процедура которая бекапируется вместе с базой
— при необходимости можно процедуру открыть и поправить
— задание выполняется по расписанию и мониторится стандартными средствами SQL
Этот подход дает удобство обслуживания загрузки данных в хранилище — всё находится в одном месте и в случае чего известно куда смотреть.
Мне кажется такой подход более инфраструктурный :)
согласно пункта 2
Культура 2 ===> Овна Кусок --- Быстро накодить тормозящий кусок овна, а потом еще выторговать себе сроки и бюджеты на оптимизацию .... ну такое .... ну на любителя.
Что это за программа ? :)
Какие бонусы разработчикам?
Могут ли стартапы участвовать ?
Какое ПО может быть Игры - можно ? Утилиты ? :)
Какая монитизация допускается и тд
Расскажите про эту программу :)
Вопрос не по теме:
Имеется такая программа
Программа READY FOR ASTRA LINUX
На сколько я понимаю это поддержка Разработки ПО, для Аstra
не могли бы Вы написать статью о самой программе, какой интерес разработчикам в нем участвовать и как подключиться к этой программе.
это мой не правильный комментарии - разобрался с Вопросом :)
По поводу названий
иногда возникает ситуация что в витрине не совсем понятно что именно содержится ....
иногда .... ну конечно же ..... иногда ....
а в некоторых случаях плюнул и назвал колонки по Русски - что бы аналитики не приставали с вопросами - А где мне взять то-то ? А что здесь ?
:) вот такой лайф хак :)
"Я хочу сказать, что использование уникального ключа в большинстве случаев не является хорошим советом для таблиц DWH с нагрузкой OLAP."(c)
Погодите :)
Давайте "Мухи отдельно - Котлеты отдельно" Олап это Кубы (которые процессятся в ночи). Тот кто думает получить агрегацию данных из обыкновенных таблиц - получит ее это называется ROLAP, но будет значительно медленнее. и в Контексте Ролап Вы правы. Но и само ожидание больших скоростей от "таблиц с нагрузкой OLAP" = неправильно.
"будет значительным, при этом таких таблиц может быть много." Не правда.
Потому что ключи это Индексы - индексы хранятся в страницах. Поэтому что бы вставить строчку с Ключём 100 вам надо задействовать диапазон страниц в которых данные от 95 до 105 (примерно) это будет не Вся таблица. а только несколько страниц из близлижайших диапазонов .
Задержка будет - но она будет незначительной по сравнению с тем что бы проверить на уникальность строки каким либо другим способом (как всегда способ один Row_Number).
"Индексы в DWH - это скорее исключение из правил, как и отсутствие партиционирования. Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами, а проверка всей таблицы на дубли при ежедневной загрузке данных скорее всего не будет иметь никакого смысла."(с)
Ну уж нет :)
Индексы это правило на DWH - так как после получения данных от источника - Вы создаете Витрины - А это Селекты, Много Много Селектов - ускорить их можно индексами.
Те же самые ОЛАПы будут просить список Уникальных значений справочников (Измерений). Ускорить сбор куба можно индексом по полю справочника.
Без Индексов - у Вас будет всё ужасно медленно :)
Загрузка быстрее - а сбор витрин = смерти подобное действо.
"как и отсутствие партиционирования" - наверно я прошлый раз не совсем доходчево сказал :)
Ок пример:
У Вас гигантская таблица - Кредит, Дата Операции
допустим - Вы секционируете по Кредиту. Приходит запрос где ищется по дате операции = Всё встало раком (потому что надо поднять все секции, и просмотреть все их индексы)
допустим Вы секционируете по Дате Операции. Приходит запрос где ищется по Номеру Кредита. = Опять Всё встало раком (опять таки потому что надо поднять все секции)
А если у Вас нет Секции - тогда делаете два индекса Один по Дате другой по номеру Кредита. И У Вас все летает. Потому что при любом запросе надо прочитать всего лишь одну секцию (саму таблицу) и соответвтующий ей индекс
Если секционирование ни как не используется (не переключаются, не архивируются, не транкетсятся, не переносятся на архивные диски) === Тогда Смысла в Секциях нету
"Ежедневная проверка одного загруженного дня закроет на 99% вопрос с дубликатами"(с)
неа....
тот же самый пример с кредитами:
Вы в мобильнике нажали - перевести деньги.
А фактически перевод выполнился в другой день.
итого у Вас две строчки:
Одна за пятницу Вечер - создать перевод.
вторая за субботу утро - провести по бух учету этот перевод.
И если смотреть дубликаты в рамках дня - вы не увидите дублеж в балансе.
"на 99% вопрос с дубликатами"
достаточно всего 1 строчки, что бы Вы будучи руководителем начали изрядно кипятиться по поводу неверной отчёности :) Особенно если эта строчка связана с каким нибудь партнером - который прекрасно умеет считать свои средства :)
"Если использовать уникальный ключ, то каждая загружаемая строка будет сверяться со всеми строками в таблице."
Это правда - действительно будет сверяться со всей таблицей.
Не знаю как на счет сотни миллиардов строк - но проверка 200 млн строк происходит за 2 минуты.
"Сама проверка на дубли может выполняться ежедневно над дневной "партицией" "
ну тогда Вы найдете дубль только в Рамках дня.
А если Вам надо не допустить дубли в таблице .... то партиции приведут к печали. Потому что к каждой партиции будет обращение как к отдельной таблице. То есть если есть сканирование индекса - то в пориционной таблице за год, будет 365 сканирований индекса. И профита нету .... но есть торможение
в каждом случае по разному.
Но общий кейс такой:
Допустим получилось так что один клиент два раза обращается за услугой - и от него приходят две анкеты. (Идентификатор клиента 1 - А анкеты у клиента 2 - обе актуальные)
в этом случае я в слой Load (куда загружают данные 1 в 1 как в источнике) оставляю дубли - это нужно на случай разборок.
а при переливе в слой Stage (где уже дополненые и готовые для построения витрин данные) - переливаю последнюю по дате анкету.
И примерно так в каждом случае создается такой костылек.
Какая же садомия ....
"Проверка на дубли ....." - у меня изначально на таблицах стоят уникальные индексы которые просто не дадут записать дубли. Если ошибка в скрипте преобзразования - загрузка упадет и всё тут.
"За выполнение проверки отвечает универсальный python-скрипт," - точно, именно так всё работает ....
я часто встречаю подобные теории:
"На планете земля есть Гугл, Майкрософт, Apple, Yandex, IBM ... и у всех нет универсального скрипта!
Но! нам повезло! У нас Федор Гавнюков, самородок земли Русской. Сделает Универсальный загрузчик, универсальный чек таблиц, универсальный мониторинг, универсальный отчет и тд... " .... каждый раз одно и тоже .... сделают "космолет" потом появится не стандартный кейс - а чел уже уволился! что будем делать ? Конечно же Универсальнй мониторинг! А что бы Универсальное что-то отрабатывало разные кейсы - сделаем таблицу в базе в которой пропишем все параметры! .....
"Проверкой (check) называется именованный абстрактный объект, к которому привязаны один или несколько SQL-запросов, правила обработки результата для каждого запроса, параметры, конфигурации подключения к ХД, список объектов ХД, к которым можно применить проверку и т.д. Всё это хранится в настроечных таблицах отдельной БД."
Вы количество людей и время потраченное ими на создание этой системы посчитали?
может быть проще найти причину почему "пропадают строчки" и решить эту проблему ?
"....то инструмент профилирования мы тоже решили разработать свой. "
я всё понял.
Ичары сказали - "Надо что то написать на Хабре для ИТ имиджа"
вот так и получилась статья ....
А по тексту - Там у Вас вообще кто нибудь работает или все только утилиты пишут ?
У меня тоже было дофига ошибок. Но потом я их все поправил, одну за одной, методично и долго. - и сейчас всё ок - нет необходимости в подобной инфраструктуре.....
Все зависит от задачи:
если надо найти одну строку и в ней что то поискать
- Ключ значение вполне подойдет
если надо найти по атрибуту все строки
- Wide-Column
Те кто пробуют искать что то внутри полей json ....
ну такое на любителя.....
потому что у колонок есть фишки которых нет в Key Value
- Тип данных
- Статистика по колонке
- Индексы
Мы его можем оформить в виде процедуры и дергать эту процедуру!
С мониторингом производительности и с возможностью быстрого изменения!
— Не… ну нафих…
мы будем использовать всякие ORM которые будут тормозить и мешать при изменении бизнес потребностей…
Г — Логика!
Ты Крут!
Лайк, только за одно оформление :)
— кодеров на Питоне пруд пруди, хоть отстреливай
— Аналитиков и могущих сделать что то на R не так много
Результат:
— Питонщики получают в два раза меньше чем спецы на R
Учи Питон — Будь нищебродом как все! :))))
— Мы сейчас делаем маленький проекторы поэтому Node.js, а если проект разростется — то и фиг с ним, гори огнем! Сей проект — кто нибудь на .NET перепилит
— зальешь 50 кк строк без индексов, а дальше что?
А дальше — включай все индексы = полная перестройка — и где профит по времени и производительности?
А если таблица 3 ярда строк — а ты влил 50 кк — перестраивать индексы будет дороже
— Ограничения и так всегда отключены на работающих БД, а там где не отключены сделано специально для проверки корректности данных
— Пометьте пожалуйста что это для Postgres
Например обфускатор от РейдГейта — не только запутывает код но и переводит «что то» на ассемблер — тем самым ускоряя работу дотнетовского экзешника
у меня просто колоночный индекс и нет проблем!
Можно использовать код где угодно :)
Однако, в этом варианте у Вас:
— процедура которая бекапируется вместе с базой
— при необходимости можно процедуру открыть и поправить
— задание выполняется по расписанию и мониторится стандартными средствами SQL
Этот подход дает удобство обслуживания загрузки данных в хранилище — всё находится в одном месте и в случае чего известно куда смотреть.
Мне кажется такой подход более инфраструктурный :)
— поменяйте логин на системный, под которым стартует служба (если у Вас не NT Service)
— попробуйте службу запустить вручную
— посмотрите журнал логов — может быть что то будет более понятно
и всегда есть ультимативный выход — переустановить R
через стандартный интерфейс установки