У нас гораздо меньше объемы. Сначала проводится историческа загрузка, делается пересчет, аналитик смотрит по срезу, все ли верно, все сделано так, как надо и т.д. После этого запускается инкрементальная загрузка с максимальным значением инкрементных ключей из ранее загруженных данных. Так как объемы не велики, то архив не храним, в случае необходимости перегрузка ставится в задание. Если данных до 100 млн записей, то можно грузить в любое время, разруливается приоритетами на потоки. А вот если больше, то под контролем команды NIFI (то есть меня :) ). Самое большое, что грузил - 500 млн записей, заняло 4-5 часов. Но грузил в выходные, когда DWH не нагружено запросами от аналитики.
Допустим, для загрузки нескольких лет данных ему понадобилось три месяца.
А можно примерный объем данных, которые грузятся так долго? Как целевая система релизует обработку данных - ждет полной загрузки и ворочает весь объем, или по мере поступления пересчитывается хранилище?
все данные, поступающие к нам через Apache Nifi, сохраняются в минимально измененном виде в HDFS
А можно поподробнее? Кто отвечает за хранение этой информации? Как долго, в среднем, хранятся данные? Доливаются ли сюда данные при последующей инкрементальной загрузке?
При обнаружении ошибки, котрорая затрагивает каскад проблем, дополнительно вношу в специальный раздел в базе знаний (у нас это Confluence), где собраны правила разработки, условия и т.д.
Коллега, если честно, даже не знаю как Вам ответить. Я без каких-то проблем захожу на GitHub, есть там пара моих репозиторием, есть и рабочий репо.
Сижу с Евпаторийского интернета, гугл уверено относит его к Украинскому сегменту, Яндекс относит к русскому. Slack заблокирован по сотовой связи, но с локального компа все доступно
Если хотите представить, каково жить без Google Play и Google Pay - посмотрите на Крым.
Живу в Крыму. Google Play тут есть. Никаких проблем. Да, зайти в Google One можно через VPN, но я один раз все настроил, и больше не хожу. В Photo и Disk захожу без ограничений. Да, с Google Pay все верно. Не работает. Однако - я в своем банке заказал виртуальную карту "Мир", поставил MirPay и плачу телефоном без проблем. Так что, не надо нагнетать панику.
Что касается блокировки поставки чипов - рекомендую более подробно ознакомится с цепочкой поставки сырья. 90% неона поставьте Украина (после 2014 года цена на неон взлетела на 600%). Также РФ поставляет более 50% остального сырья для полупроводниковой промышленности. Таким образом, блокирование поставок может вызвать ответную блокировку поставки сырья. Уверен, что через месяц все вернется на круги своя
Решение принимал директор по направлению. Меня взяли на работу с задачей развернуть сервисы и сделать потоки.
Преимущества NIFI просты - имеет внутренний сервер для запуска процессов, Open Source, стабильный продукт, горизонтальное масштабирование, позволяет хранить выгружаемые данные в себе, обеспечивает потоковую обработку, есть большое количество процессов, и легко написать свой.
Какие ещё альтернативы рассматривали?
Рассматривался Spark, Airflow (в плане рассказать о том, как мы его внедрили и для чего).
Кстати, с такой постановкой задачи ("обеспечить загрузку данных по мере их изменения на источнике") был смысл использовать CDC инструменты
Бюджет не позволяет использовать GoldenGate. Внедрение Debezium в компании не рассматривалось.
имея в руках такой инструмент, как SSIS, к чему все и сводится в конце - зачем все остальное (в этом случае)? все 3 буквы выполнить можно без проблем: и Extract, и Transform, и Load.
И это так и было. О возникших трудностях загрузки данных от источников с помощью SSIS я указал. И второй немаловажный момент - готовится миграция на GreenPlum, где нет инструмента, подобного SSIS.
SSIS мощный инструмент, однако применять его для выгрузки данных нецелесообразно, ресурсы сервера использовались для пересчета витрин, отчетов, и нагружать его выгрузкой с увеличением объема данных стало невозможно. Он просто не успевал все выгрузить и пересчитать.
передайте привет тому, кто отвечает за допуски (у вас DBA есть?). что мешает (снова вспоминаем) сделать эту операцию с помощью SSIS?
Да, я в курсе, что это не является безопасным решением. Однако оно решало две задачи - убрать именно тот файл, который залился в стейджинг, и оставить остальные файлы в этой папке.
После обкатки стейджингового слоя подобное решение было заменено. Об этом я напишу в следующей части.
В текущий момент нельзя брать ипотеку на вторичку. Чтобы взял, и сразу въехал. Это снижает привлекательность. Также присоединюсь к комментарию выше.
У нас гораздо меньше объемы. Сначала проводится историческа загрузка, делается пересчет, аналитик смотрит по срезу, все ли верно, все сделано так, как надо и т.д. После этого запускается инкрементальная загрузка с максимальным значением инкрементных ключей из ранее загруженных данных. Так как объемы не велики, то архив не храним, в случае необходимости перегрузка ставится в задание. Если данных до 100 млн записей, то можно грузить в любое время, разруливается приоритетами на потоки. А вот если больше, то под контролем команды NIFI (то есть меня :) ). Самое большое, что грузил - 500 млн записей, заняло 4-5 часов. Но грузил в выходные, когда DWH не нагружено запросами от аналитики.
А можно примерный объем данных, которые грузятся так долго? Как целевая система релизует обработку данных - ждет полной загрузки и ворочает весь объем, или по мере поступления пересчитывается хранилище?
А можно поподробнее? Кто отвечает за хранение этой информации? Как долго, в среднем, хранятся данные? Доливаются ли сюда данные при последующей инкрементальной загрузке?
Полностью поддерживаю.
При обнаружении ошибки, котрорая затрагивает каскад проблем, дополнительно вношу в специальный раздел в базе знаний (у нас это Confluence), где собраны правила разработки, условия и т.д.
Коллега, точной ссылки не дам, чтобы не плодить холивар. На YouTube канал "Борная солянка", свежее видео от Анны Сочиной.
Коллега, если честно, даже не знаю как Вам ответить. Я без каких-то проблем захожу на GitHub, есть там пара моих репозиторием, есть и рабочий репо.
Сижу с Евпаторийского интернета, гугл уверено относит его к Украинскому сегменту, Яндекс относит к русскому. Slack заблокирован по сотовой связи, но с локального компа все доступно
Живу в Крыму. Google Play тут есть. Никаких проблем. Да, зайти в Google One можно через VPN, но я один раз все настроил, и больше не хожу. В Photo и Disk захожу без ограничений.
Да, с Google Pay все верно. Не работает. Однако - я в своем банке заказал виртуальную карту "Мир", поставил MirPay и плачу телефоном без проблем. Так что, не надо нагнетать панику.
Что касается блокировки поставки чипов - рекомендую более подробно ознакомится с цепочкой поставки сырья. 90% неона поставьте Украина (после 2014 года цена на неон взлетела на 600%). Также РФ поставляет более 50% остального сырья для полупроводниковой промышленности. Таким образом, блокирование поставок может вызвать ответную блокировку поставки сырья. Уверен, что через месяц все вернется на круги своя
Решение принимал директор по направлению. Меня взяли на работу с задачей развернуть сервисы и сделать потоки.
Преимущества NIFI просты - имеет внутренний сервер для запуска процессов, Open Source, стабильный продукт, горизонтальное масштабирование, позволяет хранить выгружаемые данные в себе, обеспечивает потоковую обработку, есть большое количество процессов, и легко написать свой.
Рассматривался Spark, Airflow (в плане рассказать о том, как мы его внедрили и для чего).
Бюджет не позволяет использовать GoldenGate. Внедрение Debezium в компании не рассматривалось.
Ошибся в интерфейсе.
Ответил в комментарии
Не могу с вами согласится.
И это так и было. О возникших трудностях загрузки данных от источников с помощью SSIS я указал. И второй немаловажный момент - готовится миграция на GreenPlum, где нет инструмента, подобного SSIS.
SSIS мощный инструмент, однако применять его для выгрузки данных нецелесообразно, ресурсы сервера использовались для пересчета витрин, отчетов, и нагружать его выгрузкой с увеличением объема данных стало невозможно. Он просто не успевал все выгрузить и пересчитать.
Да, я в курсе, что это не является безопасным решением. Однако оно решало две задачи - убрать именно тот файл, который залился в стейджинг, и оставить остальные файлы в этой папке.
После обкатки стейджингового слоя подобное решение было заменено. Об этом я напишу в следующей части.