Есть задача анализа Индекса относительной величины цен (Relative Strength Index - RSI). Возможно ли получить это значение с использованием приведенных вами инструментов?
В данной статье не рассматривается разработка многопоточных и многопроцессорных приложений. Поднимать копии скриптов не вариант, т.к. источник входных данных для etl-процесса один. Т.е. копии скрипта будут "брать на борт" одни и те же данные. А вот использовать многопоточную/многопроцессорную обработку для требовательных к вычислительным ресурсам функций вполне уместно.
Спасибо за вопрос. В данной статье рассматривается заготовок кода, который можно заполнить своей бизнес-логикой. Да, записи поступают в алгоритм последовательно (можно сделать пачками, но тоже последовательно). Идея этой статьи возникла после реализации промышленного ETL-процесса, в котором каждая команда представляла из себя обращение к другой БД и/или сторонней апишки, т.е. i/o операцию. Поэтому производительность можно получить при реализации данных команд асинхронным способом.
Придется грузить всё по новой. Чтобы была возможность докачки, нужно дорабатывать и код сервера и код клиента. Обновление кода клиента в постановку задачи в рамках данного кейса не входил.
Ещё раз спасибо за комментарии. Внёс исправления в проект:
добавил тесты
`await request.content.read()` заменил на `async for data in request.content.iter_any()`
библиотеку `aiofiles` заменил на `aiofile`
параметризовал сервис переменными окружения
добавил запуск проекта в docker'е
инициализацию движка БД перенес в область глобальной видимости модуля
заменил `logger` на `aiologger`
По оставшимся вопросам:
репликация / шардирование постановкой задачи не были предусмотрены. Заранее было оговорено, что сервис работает в рамках локальной сети заказчика и бэкап делается его силами.
Если в процессе загрузки данных в файл выключится электричество на сервере, то процесс придется начинать заново. Насколько я себе представляю, чтобы возобновить загрузку файла с определенного места нужно ещё научить клиента понимать, с какого места продолжить байтовый поток. Но клиент в данном кейсе давался уже "как есть". Чтобы избежать ссылок на битые файлы, сохранение данных о новом файле в БД сервиса происходит только после сохранения файла на диске.
Здесь важен контекст. Речь идёт о группах, в которых были выпускники курсов. Я использовал два варианта - на докере и на вагранте. Вагрант требовал от меня больше знаний и объяснений на входе в проект. Потом вопросов "как это мне запустить?" было минимум, потому что участники работали с привычным интерфейсом (по другому я это объяснить не могу). С докером было наоборот. Сначала приходилось объяснять что-такое докер, а затем попутно решать вопросы "а у меня слетело, а я перезапустил" и т.д.
Я ранее не работал с IBM DataStage. Насколько я понял из описания системы, она предназначена для перекачки данных из БД в БД. Если я ошибаюсь, напишите пож-та. Описанный мною etl процесс я использую для перекачки данных из БД в API-сервисы и наоборот. Причем API сервисы разные и требуют (или отдают) данные как json-формате, так и в xml. Помимо кода выгрузки, загрузки в etl-процессе требуется разработка билдеров и парсеров
Цель данной статьи - показать способ решения задачи на питоне. Что именно использовать: собственную разработку или готовое программное решение - на усмотрение постановщика задачи.
Airflow безусловно да. Джанго появился из-за того, что в разрабатываемых мною проектах etl нужно было прикрутить в рамках уже существующего проекта. Как дополнительную функциональность.
Есть задача анализа Индекса относительной величины цен (Relative Strength Index - RSI). Возможно ли получить это значение с использованием приведенных вами инструментов?
В данной статье не рассматривается разработка многопоточных и многопроцессорных приложений. Поднимать копии скриптов не вариант, т.к. источник входных данных для etl-процесса один. Т.е. копии скрипта будут "брать на борт" одни и те же данные. А вот использовать многопоточную/многопроцессорную обработку для требовательных к вычислительным ресурсам функций вполне уместно.
Спасибо за вопрос. В данной статье рассматривается заготовок кода, который можно заполнить своей бизнес-логикой. Да, записи поступают в алгоритм последовательно (можно сделать пачками, но тоже последовательно). Идея этой статьи возникла после реализации промышленного ETL-процесса, в котором каждая команда представляла из себя обращение к другой БД и/или сторонней апишки, т.е. i/o операцию. Поэтому производительность можно получить при реализации данных команд асинхронным способом.
Придется грузить всё по новой. Чтобы была возможность докачки, нужно дорабатывать и код сервера и код клиента. Обновление кода клиента в постановку задачи в рамках данного кейса не входил.
Ещё раз спасибо за комментарии. Внёс исправления в проект:
добавил тесты
`await request.content.read()` заменил на `async for data in request.content.iter_any()`
библиотеку `aiofiles` заменил на `aiofile`
параметризовал сервис переменными окружения
добавил запуск проекта в docker'е
инициализацию движка БД перенес в область глобальной видимости модуля
заменил `logger` на `aiologger`
По оставшимся вопросам:
репликация / шардирование постановкой задачи не были предусмотрены. Заранее было оговорено, что сервис работает в рамках локальной сети заказчика и бэкап делается его силами.
Если в процессе загрузки данных в файл выключится электричество на сервере, то процесс придется начинать заново. Насколько я себе представляю, чтобы возобновить загрузку файла с определенного места нужно ещё научить клиента понимать, с какого места продолжить байтовый поток. Но клиент в данном кейсе давался уже "как есть". Чтобы избежать ссылок на битые файлы, сохранение данных о новом файле в БД сервиса происходит только после сохранения файла на диске.
Спасибо большое за развернутый комментарий. Почему
aiofilesсомнительная библиотека? Какие предлагаете альтернативы?Спасибо за замечание, переделаю на aiologger
Здесь важен контекст. Речь идёт о группах, в которых были выпускники курсов. Я использовал два варианта - на докере и на вагранте. Вагрант требовал от меня больше знаний и объяснений на входе в проект. Потом вопросов "как это мне запустить?" было минимум, потому что участники работали с привычным интерфейсом (по другому я это объяснить не могу). С докером было наоборот. Сначала приходилось объяснять что-такое докер, а затем попутно решать вопросы "а у меня слетело, а я перезапустил" и т.д.
<точно так>
в том числе docker
</точно так>
Спасибо за замечание, исправил
ещё рекомендую клонировать репозиторий и погонять код через отладчик. Будет интересно!
Спасибо за вопрос. Чтобы ответить на него я переработал статью. Надеюсь теперь понятнее.
Я ранее не работал с IBM DataStage. Насколько я понял из описания системы, она предназначена для перекачки данных из БД в БД. Если я ошибаюсь, напишите пож-та. Описанный мною etl процесс я использую для перекачки данных из БД в API-сервисы и наоборот. Причем API сервисы разные и требуют (или отдают) данные как json-формате, так и в xml. Помимо кода выгрузки, загрузки в etl-процессе требуется разработка билдеров и парсеров
Цель данной статьи - показать способ решения задачи на питоне. Что именно использовать: собственную разработку или готовое программное решение - на усмотрение постановщика задачи.
Логируется всё в воркер
Airflow безусловно да. Джанго появился из-за того, что в разрабатываемых мною проектах etl нужно было прикрутить в рамках уже существующего проекта. Как дополнительную функциональность.
Надо попробовать...