Дополню что не всякий DE это обязательно питон, это вполне себе и Java и Scala и Kotlin местами... Ну и зачастую еще зоопарк систем и фреймворков которыми надо управлять. Ну и как бы само название Инженер подразумевает что его нужно к инженерам а не к аналитикам.
Для того чтобы пройти Алгосы сидишь месяц на LeetCode и их в лет проходишь. Все интересное дальше, и там надо будет показывать знания уже в той области в которую двигаешься.
Спасибо огромное, да логическая не стыковка в тексте вышла и я ее проглядел. Сейчас поправил должно стать понятнее. Любые выходы называются relations. И можно пометить Relation как Terminated
Да в терминах NIFI у процессора есть Upstream Connection и Relation. Upstream Connection это вход для Процессора. И получается для Процессора это внешняя информация, но в рамках NIFI это входящая очередь данных внутри NIFI.
В процессоре строго определены возможные/используемые relation. Если какой то из Relation не нужен (то есть нам не интересно что в него направляется, и мы не планируем обрабатывать информацию попавшую в этот выход) то мы можем пометить данную очередь как "Terminated", в этом случае мы не обязаны куда то ее направлять, и данные попадающие в нее будут уничтожаться. Но тем не менее процессор все равно имеет эту выход, просто он никуда не ведет.
Как по мне, замечательный инструмент для Extract Transform Load. Есть вопросы к механизму стейта (IO дисков узкое место для NIFI) Но это решаемая тема.
Просто были тучные времена, когда можно было инвестировать в проверки тысяч гипотез, и тратить деньги на очень фантастические идеи, а теперь настали голодные времена, и будут вкладываться в гарантированный доход, и в имеющиеся проекты. Это позволит, как мне кажется, показать прибыль на уровне той что было раньше, но вот к чему это приведет в более далекой перспективе, хз...
Куча современных инструментов это всё-таки ETL. Тот же Спарк или трансформации данных через python pandas это вариации ETL подхода, хотя со спарком можно поспорить, так как зачастую он использует ресурсы hdfs. Но если поставим его в условном Standalone будет вполне себе ETL. Куча инструментов предлагает оба варианта обработки. Облачные движки так же могут давать ETL подход. Кроме того стримовые движки типа флинка это тоже по факту etl. В статье очень странно описаны плюсы/минусы каждого из подходов, статья очень похожа на продажу ЕLT подхода с которой лет 10 или 15 назад выходил оракл со своим odi, рассказывая что придумал новый вариант интеграции данных. Например "Вы работаете только со структурированными данными и/или с небольшими частями данных" почему etl не подходит для слабоструктурированные данных и как вы загрузите произвольный json в целевую базу и будете жечь проц на парсинг этого json в базе?
Огромные ресурсы для ETL тоже миф, используя подходы микробатчинга можно ограничится довольно скромными ресурсами, но правда теряются не некоторые возможности. Но иначе вам необходимо жечь ресурсы системы хранения в ELT, что при не удачной реализации ресурсных политик может поставить вас в неудобную ситуацию.
Идеально сочитать оба подхода, не сжигая ресурсы на операции трансформации и интеграции самих данных используя etl, и выполняя сложные трансформации сочетающие данные из разных источников для сбора сущностей и витрин в пушдаун/elt подходе.
Хорошая статья про интерфейс. Я так понимаю это вводная часть к основной статье про мониторинг, потому что про мониторинг тут довольно мало, и скорее больше то что можно увидеть и проконтролировать в интерфейсе. С нетерпением жду почитать как делаете именно мониторинг и надеюсь алертинг в NIFI.
На самом деле чистый объем не так принципиально в вопросе инициирующей загрузки, гораздо интересней соотношение регламента к инициализации. Как правило мощность среды затачивается под погрузку регламента,и если данных в 100-1000 раз больше чем дневной икремент то могут быть негативные последствия о которых я писал, даже если речь о каких-то десятках миллионов, при учете что среда рассчитана на тысячи записей. Но да, до определённых объёмов вполне реально не выделять инициализации как отдельный процесс. Если пропускная возможность среды сильно выше текущей ёмкости потока данных.
На на самом деле на практике у нас были загрузки не больше пары недель. И для таких загрузок хранилище пересчитывалось каждый день батчевыми процессами. Регламентый поток работал в параллели. Но здесь все разумеется зависит от всего цикла обработки информации. Что касается объёмов это если не ошибаюсь десятки терабайт в сжатом виде.
Но бывали разумеется на практике и потоки которые требовали строгой последовательности погрузки данных в этом случае Регламентый поток запускался только после завершения инициализации данных. И в некоторых ситуациях даже после исполнения пересчёта хранилища на инициированных данных, но это скорее редкость,в идеале последующий пайп не должен рассчитывать на весь объем инициализированных данных.
Про архив. Данные хранятся до 5 лет, в среднем год. Регламент доливает данные в архив по мере загрузки. За хранение отвечает у нас команда поддержки NiFi совместно с командой поддержки Систем хранения.
А операторы ли связи жаловались, или может какая то другая компания с православным месенжером, в котором звонки не будут блокироваться?
а минусы будут?
Хотя летучих мышей жалко конечно, но вот обычных, я бы синицам еще приплачивал... Кстати видимо поэтому синицы любят сало, близко по вкусу похоже.
Дополню что не всякий DE это обязательно питон, это вполне себе и Java и Scala и Kotlin местами... Ну и зачастую еще зоопарк систем и фреймворков которыми надо управлять. Ну и как бы само название Инженер подразумевает что его нужно к инженерам а не к аналитикам.
Тоже негодую!
Для того чтобы пройти Алгосы сидишь месяц на LeetCode и их в лет проходишь. Все интересное дальше, и там надо будет показывать знания уже в той области в которую двигаешься.
Спасибо огромное, да логическая не стыковка в тексте вышла и я ее проглядел. Сейчас поправил должно стать понятнее. Любые выходы называются relations. И можно пометить Relation как Terminated
Да в терминах NIFI у процессора есть Upstream Connection и Relation. Upstream Connection это вход для Процессора. И получается для Процессора это внешняя информация, но в рамках NIFI это входящая очередь данных внутри NIFI.
В процессоре строго определены возможные/используемые relation. Если какой то из Relation не нужен (то есть нам не интересно что в него направляется, и мы не планируем обрабатывать информацию попавшую в этот выход) то мы можем пометить данную очередь как "Terminated", в этом случае мы не обязаны куда то ее направлять, и данные попадающие в нее будут уничтожаться. Но тем не менее процессор все равно имеет эту выход, просто он никуда не ведет.
Хотелось бы больше деталей.
Как по мне, замечательный инструмент для Extract Transform Load. Есть вопросы к механизму стейта (IO дисков узкое место для NIFI) Но это решаемая тема.
А для роутинга данных кажется слегка перебор.
Посмотрите в сторону NIFI Statless и Execute Statless ну и NIFI про Конвейер, а не про Процедуры, это немного ломает.
Просто были тучные времена, когда можно было инвестировать в проверки тысяч гипотез, и тратить деньги на очень фантастические идеи, а теперь настали голодные времена, и будут вкладываться в гарантированный доход, и в имеющиеся проекты. Это позволит, как мне кажется, показать прибыль на уровне той что было раньше, но вот к чему это приведет в более далекой перспективе, хз...
Куча современных инструментов это всё-таки ETL. Тот же Спарк или трансформации данных через python pandas это вариации ETL подхода, хотя со спарком можно поспорить, так как зачастую он использует ресурсы hdfs. Но если поставим его в условном Standalone будет вполне себе ETL. Куча инструментов предлагает оба варианта обработки. Облачные движки так же могут давать ETL подход. Кроме того стримовые движки типа флинка это тоже по факту etl. В статье очень странно описаны плюсы/минусы каждого из подходов, статья очень похожа на продажу ЕLT подхода с которой лет 10 или 15 назад выходил оракл со своим odi, рассказывая что придумал новый вариант интеграции данных. Например "Вы работаете только со структурированными данными и/или с небольшими частями данных" почему etl не подходит для слабоструктурированные данных и как вы загрузите произвольный json в целевую базу и будете жечь проц на парсинг этого json в базе?
Огромные ресурсы для ETL тоже миф, используя подходы микробатчинга можно ограничится довольно скромными ресурсами, но правда теряются не некоторые возможности. Но иначе вам необходимо жечь ресурсы системы хранения в ELT, что при не удачной реализации ресурсных политик может поставить вас в неудобную ситуацию.
Идеально сочитать оба подхода, не сжигая ресурсы на операции трансформации и интеграции самих данных используя etl, и выполняя сложные трансформации сочетающие данные из разных источников для сбора сущностей и витрин в пушдаун/elt подходе.
Хорошая статья про интерфейс. Я так понимаю это вводная часть к основной статье про мониторинг, потому что про мониторинг тут довольно мало, и скорее больше то что можно увидеть и проконтролировать в интерфейсе. С нетерпением жду почитать как делаете именно мониторинг и надеюсь алертинг в NIFI.
На самом деле чистый объем не так принципиально в вопросе инициирующей загрузки, гораздо интересней соотношение регламента к инициализации. Как правило мощность среды затачивается под погрузку регламента,и если данных в 100-1000 раз больше чем дневной икремент то могут быть негативные последствия о которых я писал, даже если речь о каких-то десятках миллионов, при учете что среда рассчитана на тысячи записей. Но да, до определённых объёмов вполне реально не выделять инициализации как отдельный процесс. Если пропускная возможность среды сильно выше текущей ёмкости потока данных.
На на самом деле на практике у нас были загрузки не больше пары недель. И для таких загрузок хранилище пересчитывалось каждый день батчевыми процессами. Регламентый поток работал в параллели. Но здесь все разумеется зависит от всего цикла обработки информации. Что касается объёмов это если не ошибаюсь десятки терабайт в сжатом виде.
Но бывали разумеется на практике и потоки которые требовали строгой последовательности погрузки данных в этом случае Регламентый поток запускался только после завершения инициализации данных. И в некоторых ситуациях даже после исполнения пересчёта хранилища на инициированных данных, но это скорее редкость,в идеале последующий пайп не должен рассчитывать на весь объем инициализированных данных.
Про архив. Данные хранятся до 5 лет, в среднем год. Регламент доливает данные в архив по мере загрузки. За хранение отвечает у нас команда поддержки NiFi совместно с командой поддержки Систем хранения.
Надеюсь ответил на вопросы.