Автор Киба здесь! Это важный вопрос, спасибо, что задали его!
МОЙ ВОПРОС: Должен ли я использовать Rails в этом проекте ETL?
По умолчанию я бы рекомендовал начать с отдельный проект (например, своего рода «макро-сервисный» подход), если у вас нет важных вещей (кроме настройки RSpe c и ENV) для повторного использования из приложения Rails.
Если есть важная ожидаемая связь между приложением и ETL (например, под «запланированными заданиями» вы подразумеваете задания, запущенные через Sidekiq, чтобы реагировать на события, или у вас есть классы, совместно используемые двумя проектами), затем вы можете поместить ETL в etl например, подпапка вашего Rails-приложения, чтобы обеспечить немного разделения и оставить возможность разделить код позже, если он станет лучшим путем (это промежуточный вариант, который я использую в некоторых проектах).
Если это не так, и ожидается, что конвейер данных станет большим и будет жить своей собственной жизнью, вы можете вместо этого разделить его на собственный проект.
* 101 4 * Использование этого означает, что мы можем применить ту же структуру папок, что и другие репозитории, использовать RSpe c все то же самое и т.д. c.
Вы можете использовать RSpe c или minitest из также выделенный ETL (чистый Ruby) проект, введите понятие ETL_ENV (development, test, production), создайте свою собственную конфигурацию на основе ENV (или на основе файлов) с помощью dotenv или аналогичной, и если вам это нужно, также поддержите задания cron.
Чистые Ruby проекты могут быть структурированы так же, как приложение на Rails, и обычно меньше волхвов c (более явное), что полезно.
Мне также показалось, что Rails меняет способ, которым классы наподобие Ha sh действуют.
Я бы действительно рекомендовал использовать "явный" подход относительно зависимости от этого. , Сегодня я предпочитаю выбирать нужные расширения в верхней части каждого файла (как описано здесь ).
Последнее слово, вы можете проверить ETL-конвейеры Kiba так же, как и ваши отдельные компоненты ETL, и я бы порекомендовал это сделать (об этом я расскажу в следующем сообщении в блоге), поскольку это помогает легко перемещать и обновлять Ruby и в целом легко масштабировать команду разработчиков. (CI + тесты).
Я надеюсь, что это даст вам достаточное руководство для принятия решения по этому вопросу, если это не так, пожалуйста, закомментируйте!