это ад для разработчика, delete Отключен по умолчанию, данные можно только добавлять (но не удалять)
если есть косяк в данных то это только срубать всю таблицу целиком либо пытаться сделать через replace partition (подключаясь напрямую к каждому шарду поочерёдно)
В общем есть в нём одна незадокументированная фишка, а именно - ReplicatedReplacingMergeTree не работает, точнее работает, но не как задумано.
В чём выражается - данные должны дедпуплицироваться по PK/SK, это происходит, но только частично, у нас сейчас в продовой БД есть дубли которым 2+ года (процесс дедубликации не моментальный, но не 2 года же), при этом данные находятся на одном шарде.
Решается только если грузить методом REPLACE PARTITION.
расскажу лайфхак - есть принтер "прямой печати", печатает любую картинку на футболке\кофте за пару минут, правда только на полиэстере если память не изменяет
и стоила такая футболка за 1шт. рублей 700-900 (правда цены 6-летней давности, допустим сейчас 1200-1500 стоит), и не надо никакой шелкографии с тиражом 5 футболок, только рамы обойдутся тыщ в 7, а ещё приладка 3-4 * 1500 уже больше 10к и это без самих футболок..
Типография производит "от визиток до баннеров" - обычно это вообще разные ветви бизнеса:
- оперативная полиграфия (просто принтер за пару млн либо ризограф) - визитки, буклеты, листовки и тд - шелкография (тут от направления зависит) - визитки (тачкавер), брендирование (сумки, футболки, пакеты, ручки и тд - в общем мерч) - либо прямая УФ-печать (привет китайцам с мимаки) - визитки, ручки, всякие повербанки и тд - плоттерная резка\термопресс - футболки (как у футболистов) - баннеры (широкоформатная печать) - оффсет (большие тиражи всяких буклетов\сборные тиражи визиток) - цифровой оффсет (малые тиражи книг) - наружная реклама (световые панно\наружные вывески)
Есть подозрение что эта типография, скажем так, выполняет 1-2 видов заказов, а остальное просто перезаказывает у крупных игроков в сборных тиражах
А проблема в том, что вместо своих 1-2 операций пытается делать вообще всё, играет в РА (рекламное агентство) где она совсем не сильна, иначе "под ключ" постоянно валились бы заказы от всяких МТС\Билайнов\Банков и тд на (условный пример) пледы с брендированием + ПВД-пакеты + футболки + ручки-кружки + 5 ноутов с брендированием
Хорошо хоть пластиковые карты с эмбоссированием не делают (надеюсь) или газеты (самый мрак)
Т.е. теперь в типографию будет поступать больше всевозможных заказов которые она делать самостоятельно не в состоянии, что скажется на скорости, качестве, и, в результате, уменьшения количества клиентов в долгосроке
Ну и насчет сарафанного радио - принт-форум никто не отменял, но там надо репутацию заслужить
Вопреки вашим убеждениям, технология нормального смешивания меда с ягодами и правда непростая. Здесь важны температура меда и расплавления кристаллов, фракции и состояние ягод, степень их усушки и внутренне количество внутренней влаги, длительность смешивания и опять же температура процесса, стадии ввода ягоды.
не эксперт по мёду, тут может быть недоступное мне знание (без сарказма), но есть некий шанс что условно если придерживаться паре правил (грубо говоря температуре и длительности смешивания) то в 99% результат будет удовлетворительным
приведу пример из другой индустрии - шелкографии:
Печатная краска - "это гетерогенная коллоидная система, состоящая из высокодисперсных частиц пигментов, равномерно распределённых и стабилизированных в жидкой фазе связующего вещества". Тем не менее замечательный человек из Таждикистана (и не только он) не зная всего этого прекрасно печатал заказы просто добавляя растворитель если водная краска сохнет, а так же вовремя смывая раму))
Библиотека предполагает ETL-подход, но для неструктурированных данных кажется проще использовать ELT (Extract - Load - Transform), т.е. сохранить данные as is в какой-нибудь Postgres в поле с типом json, а потом уже обрабатывать это поле
Т.е. грубо говоря если с помощью библиотеки делаем парсинг json, а потом (как обычно бывает) туда попадают новые ключи \ уходят старые то мы на выходе получим некорректный json. В случае с ELT-подходом просто правим парсер (вместо перезагрузки данных за N-период + так же правки парсера)
Интересно, конечно, подобное слышал когда друг проходил (прошёл в итоге) на тимлида С-решётки.
Как я проходил отбор:
1) Отправил резюме через форму на их сайте в разделе Вакансии (Дата-инженер\ЕТЛ-разработчик) 2) Согласовал с HR время собеседований в ТГ 3) Теоретическая секция по MPP (Greenplum) 4) Практическая по SQL (3 или 4 задачи было + последнюю нужно было решить без окна типа как задание со звёздочкой) 5) Оффер
На всё ушло меньше недели. Команду только 1 предложили (обычно больше, но в тот момент как у ТС была доступна только 1).
В яндекс проходил (с алгоритмами) 2 года назад, не пошёл т.к. про меня "забыли" и потом предложили поменять команду+направление, 1 год назад попробовал повторно, завалил, в Авито просто отказали без причин.
В общем витиеватость собеседования зависит от выбранного направления.
GenerateFlowFile создает flowfile который уже бегает по вашим процессорам и собирает данные \ выполняет загрузку данных, пока что для меня загадка как Вы без него работаете, ну да ладно, может у нас подходы к работе в NiFi разные
4) Если есть процессорная группа под мониторинг - тогда нет вопросов
5) По идее пользователь не должен трогать работающий NiFi-поток, если он загружает данные на прод и при этом вносит изменения в real-time режиме то это как-то странно
6) Тут про мониторинг был пункт, но я понял про что Вы говорите, посмотреть данные действительно удобно, тут бесспорно :)
1) Согласен 2) Согласен 3) Согласен 4) Локализация проблемы - да, а вот насчет простоты решения.. Придёт какой-нибудь ответ по API {"error": "400"} или просто сетевая ошибка - тут пользователю надо всё-таки разбираться в инструменте и уметь читать Java-еггоги хотя бы минимально 5) Защита? У Вас в примере все процессоры стопнуты, а если они (кроме первого) будут включены? Пока не понимаю до конца этого утверждения 6) Тоже не понимаю - вот выгрузились данные и куда-то сохранились (или произошёл UPDATE), NiFi это же ETL-инструмент, а не мониторинг, Вы предлагаете в Data Provenance смотреть что ли?)
И ещё заметил что в в примерах нет процессора GenerateFlowFile - это специально так и задумано?
Для обработки ошибок есть Retry-процессор с настройкой penalty duration, а так же с настройкой retries_exceeded, после чего надо отправлять flowfile в порт error для анализа ошибки
Не надо failure возвращать обратно в процессор
А вообще не увидел зачем для таких задач NiFi нужен, почему просто через Airflow PostgresOperator это не сделать
Старые-добрые шутки из игромании)) только не заметил шутку про шар
Поэтому на всякий
Hidden text
Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
- Как так-то, блять! Должно же работать! - в отчаянии кричишь ты и звонишь прошлому прорабу:
- Вася, у нас ядовитый газ потёк! В чем проблема?
- Не знаю, должно было все работать. Что-то в проекте менял?
- Немного, швабры вынес...
- Швабры потолок держали!
- Что??? Что, блять, извините???
- Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
- Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
- Включай вентилятор. Он сдует газ с острова.
- Я его, блять, демонтировал сразу же!
- Зачем?
- Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
- Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
- Вася, я убрал твой вентилятор! Мы тут задыхаемся!
- Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!
Зачем делать графики с аномалиями ("экстремально маленькая выборка"), вы же сами на своём курсе по аналитике данных учите про выбросы и перцентили?
И оффтоп - если получится то сделайте, пожалуйста, график сколько выпускников в детстве интересовалось IT и пока у всех был интернет по карточкам - они уже проложили локалку на районе и играли в CS:Go и Dota2, очень заинтересовало
в сбере по отделам есть лимит вакансий на команду + иногда нужно просто реализовать краткосрочный проект, потом передав его сберовцам на поддержку, а содержать дальше команду разработки бессмысленно
поэтому это обходят тем, что есть 1 МРОТ-ставка (попиленная на несколько неполных ставок), на которую берут аутстафф, а расходы на их ЗП это уже другая статья расходов
это ад для разработчика, delete Отключен по умолчанию, данные можно только добавлять (но не удалять)
если есть косяк в данных то это только срубать всю таблицу целиком либо пытаться сделать через replace partition (подключаясь напрямую к каждому шарду поочерёдно)
к сожалению я не могу этого сделать вручную (не являюсь админом клика), только загружаю в него
optimize дёргается кроном\аирфлоу по расписанию, но это не помогает
в общем советую проверить данные на дубли)
О, этот дивный ClickHouse
select version() -- 23.12.1.1368
В общем есть в нём одна незадокументированная фишка, а именно - ReplicatedReplacingMergeTree не работает, точнее работает, но не как задумано.
В чём выражается - данные должны дедпуплицироваться по PK/SK, это происходит, но только частично, у нас сейчас в продовой БД есть дубли которым 2+ года (процесс дедубликации не моментальный, но не 2 года же), при этом данные находятся на одном шарде.
Решается только если грузить методом REPLACE PARTITION.
Да, но шелкухой тираж в 10 именных футболок печатать не будешь же (если не хочешь по 10к за футболку платить)
назвал Ракель щёткой, эх..
расскажу лайфхак - есть принтер "прямой печати", печатает любую картинку на футболке\кофте за пару минут, правда только на полиэстере если память не изменяет
и стоила такая футболка за 1шт. рублей 700-900 (правда цены 6-летней давности, допустим сейчас 1200-1500 стоит), и не надо никакой шелкографии с тиражом 5 футболок, только рамы обойдутся тыщ в 7, а ещё приладка 3-4 * 1500 уже больше 10к и это без самих футболок..
Типография производит "от визиток до баннеров" - обычно это вообще разные ветви бизнеса:
- оперативная полиграфия (просто принтер за пару млн либо ризограф) - визитки, буклеты, листовки и тд
- шелкография (тут от направления зависит) - визитки (тачкавер), брендирование (сумки, футболки, пакеты, ручки и тд - в общем мерч)
- либо прямая УФ-печать (привет китайцам с мимаки) - визитки, ручки, всякие повербанки и тд
- плоттерная резка\термопресс - футболки (как у футболистов)
- баннеры (широкоформатная печать)
- оффсет (большие тиражи всяких буклетов\сборные тиражи визиток)
- цифровой оффсет (малые тиражи книг)
- наружная реклама (световые панно\наружные вывески)
Есть подозрение что эта типография, скажем так, выполняет 1-2 видов заказов, а остальное просто перезаказывает у крупных игроков в сборных тиражах
А проблема в том, что вместо своих 1-2 операций пытается делать вообще всё, играет в РА (рекламное агентство) где она совсем не сильна, иначе "под ключ" постоянно валились бы заказы от всяких МТС\Билайнов\Банков и тд на (условный пример) пледы с брендированием + ПВД-пакеты + футболки + ручки-кружки + 5 ноутов с брендированием
Хорошо хоть пластиковые карты с эмбоссированием не делают (надеюсь) или газеты (самый мрак)
Т.е. теперь в типографию будет поступать больше всевозможных заказов которые она делать самостоятельно не в состоянии, что скажется на скорости, качестве, и, в результате, уменьшения количества клиентов в долгосроке
Ну и насчет сарафанного радио - принт-форум никто не отменял, но там надо репутацию заслужить
не эксперт по мёду, тут может быть недоступное мне знание (без сарказма), но есть некий шанс что условно если придерживаться паре правил (грубо говоря температуре и длительности смешивания) то в 99% результат будет удовлетворительным
приведу пример из другой индустрии - шелкографии:
Печатная краска - "это гетерогенная коллоидная система, состоящая из высокодисперсных частиц пигментов, равномерно распределённых и стабилизированных в жидкой фазе связующего вещества". Тем не менее замечательный человек из Таждикистана (и не только он) не зная всего этого прекрасно печатал заказы просто добавляя растворитель если водная краска сохнет, а так же вовремя смывая раму))
Библиотека предполагает ETL-подход, но для неструктурированных данных кажется проще использовать ELT (Extract - Load - Transform), т.е. сохранить данные as is в какой-нибудь Postgres в поле с типом json, а потом уже обрабатывать это поле
Т.е. грубо говоря если с помощью библиотеки делаем парсинг json, а потом (как обычно бывает) туда попадают новые ключи \ уходят старые то мы на выходе получим некорректный json. В случае с ELT-подходом просто правим парсер (вместо перезагрузки данных за N-период + так же правки парсера)
Добавьте тег что статья написана ботом, тут просто явно видно:
"...маршрутизатор, спрятанный в подошве обуви человека."
Согласен, но если просто развлекательный контент для спинного мозга включить то этого достаточно)
можно же просто VPN включить и поставить страну РФ
Интересно, конечно, подобное слышал когда друг проходил (прошёл в итоге) на тимлида С-решётки.
Как я проходил отбор:
1) Отправил резюме через форму на их сайте в разделе Вакансии (Дата-инженер\ЕТЛ-разработчик)
2) Согласовал с HR время собеседований в ТГ
3) Теоретическая секция по MPP (Greenplum)
4) Практическая по SQL (3 или 4 задачи было + последнюю нужно было решить без окна типа как задание со звёздочкой)
5) Оффер
На всё ушло меньше недели. Команду только 1 предложили (обычно больше, но в тот момент как у ТС была доступна только 1).
В яндекс проходил (с алгоритмами) 2 года назад, не пошёл т.к. про меня "забыли" и потом предложили поменять команду+направление, 1 год назад попробовал повторно, завалил, в Авито просто отказали без причин.
В общем витиеватость собеседования зависит от выбранного направления.
К сожалению у меня регламент по работе с NiFi, спасибо за объяснение про ваш подход, но у меня такой не покатит :)
Развернуть мне пока что негде, добавлю в закладки, не удивляйтесь если через полгода произойдёт "реанимация" треда)
GenerateFlowFile создает flowfile который уже бегает по вашим процессорам и собирает данные \ выполняет загрузку данных, пока что для меня загадка как Вы без него работаете, ну да ладно, может у нас подходы к работе в NiFi разные
4) Если есть процессорная группа под мониторинг - тогда нет вопросов
5) По идее пользователь не должен трогать работающий NiFi-поток, если он загружает данные на прод и при этом вносит изменения в real-time режиме то это как-то странно
6) Тут про мониторинг был пункт, но я понял про что Вы говорите, посмотреть данные действительно удобно, тут бесспорно :)
1) Согласен
2) Согласен
3) Согласен
4) Локализация проблемы - да, а вот насчет простоты решения.. Придёт какой-нибудь ответ по API {"error": "400"} или просто сетевая ошибка - тут пользователю надо всё-таки разбираться в инструменте и уметь читать Java-еггоги хотя бы минимально
5) Защита? У Вас в примере все процессоры стопнуты, а если они (кроме первого) будут включены? Пока не понимаю до конца этого утверждения
6) Тоже не понимаю - вот выгрузились данные и куда-то сохранились (или произошёл UPDATE), NiFi это же ETL-инструмент, а не мониторинг, Вы предлагаете в Data Provenance смотреть что ли?)
И ещё заметил что в в примерах нет процессора GenerateFlowFile - это специально так и задумано?
Для обработки ошибок есть Retry-процессор с настройкой penalty duration, а так же с настройкой retries_exceeded, после чего надо отправлять flowfile в порт error для анализа ошибки
Не надо failure возвращать обратно в процессор
А вообще не увидел зачем для таких задач NiFi нужен, почему просто через Airflow PostgresOperator это не сделать
Старые-добрые шутки из игромании)) только не заметил шутку про шар
Поэтому на всякий
Hidden text
Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
- Как так-то, блять! Должно же работать! - в отчаянии кричишь ты и звонишь прошлому прорабу:
- Вася, у нас ядовитый газ потёк! В чем проблема?
- Не знаю, должно было все работать. Что-то в проекте менял?
- Немного, швабры вынес...
- Швабры потолок держали!
- Что??? Что, блять, извините???
- Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
- Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
- Включай вентилятор. Он сдует газ с острова.
- Я его, блять, демонтировал сразу же!
- Зачем?
- Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
- Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
- Вася, я убрал твой вентилятор! Мы тут задыхаемся!
- Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!
В этом и смысл - если "выпускник" играл в доку2 во времена карточного интернета то история его трудоустройства, скажем мягко, фантазия копирайтера
Зачем делать графики с аномалиями ("экстремально маленькая выборка"), вы же сами на своём курсе по аналитике данных учите про выбросы и перцентили?
И оффтоп - если получится то сделайте, пожалуйста, график сколько выпускников в детстве интересовалось IT и пока у всех был интернет по карточкам - они уже проложили локалку на районе и играли в CS:Go и Dota2, очень заинтересовало
Для тех кто не видел:
https://pikabu.ru/story/kak_ya_iskal_rabotu_vo_frontende_11075658
в сбере по отделам есть лимит вакансий на команду + иногда нужно просто реализовать краткосрочный проект, потом передав его сберовцам на поддержку, а содержать дальше команду разработки бессмысленно
поэтому это обходят тем, что есть 1 МРОТ-ставка (попиленная на несколько неполных ставок), на которую берут аутстафф, а расходы на их ЗП это уже другая статья расходов