Синхронизировать все операции данных под одним и тем же инструментом

Question

В моей компании Pentaho Kettle ежедневно выполняет работу ETL (одной машины достаточно для всех имеющихся у нас данных), что означает:

• чтение данных из разных, в основном реляционных баз данных, электронных таблиц и API
• применение преобразований и вставка данных в Redshift
• Выполнение вызовов API для внешних инструментов SAAS

Мы планируем переделать его, используя более продвинутый инструмент, который позволит нам:

• обновлять dwh чаще, чем раз в день
• проще получать и отправлять данные в используемые нами API-интерфейсы SAAS (обработка и составление JSON в Пентахо трудны)
• Включить запуск других рабочих нагрузок в рабочем процессе (например, сценарии Python)
• Синхронизировать конвейеры машинного обучения, работающие на машинах EC2
• Будьте готовы к 5-кратному масштабированию данных за один год (когда одной машины может не хватить)

Что-то, что приходит мне в голову, это Luigi или Airflow в качестве менеджеров рабочих процессов, и создание ETL на основе кода с использованием python? Поскольку вся наша инфраструктура находится в облаке AWS, я вижу, что теперь AWS Glue также предлагается в качестве опции (я не знаю, предназначен ли он только для etl или также может использоваться для других процессов, которые мы планируем включить)

Есть ли другое решение? У кого-нибудь есть опыт их использования (особенно, как они работают с красным смещением, s3, возможно, с запуском в будущих рабочих нагрузках спарк / кинезис)?

Если да, какие библиотеки использовать, и где можно начать изучать?

Answer 1

Извините, но практически невозможно ответить на такие вопросы. Каждая компания и команда разные. То, что работает для нас, не обязательно будет работать для вас.

Однако я могу дать несколько общих советов:

Играй в свои сильные стороны. Если ваша команда полна сильных C# кодеров, не выбирайте Python. Если вы знаете SQL Server внутри и снаружи и выбираете их инструмент ETL.

Планирование. Это самый важный шаг. Убедитесь, что вы полностью проанализировали и задокументировали, как будет работать новое решение ETL. Выявление и решение всех сложных проблем заранее приведет к сокращению времени разработки и более своевременному решению. Более глубокое понимание мелочей также поможет вам оценить различные предлагаемые инструменты и структуры. В конце этого процесса вы должны знать:

• Сколько времени займет разработка.
• Какая функциональность вам требуется от вашего инструмента ETL.
• Как будет организован / проверен / обновлен ETL.
• Каковы основные вехи.

Если вы планируете правильно, не имеет значения, какие технологии вы используете.

Прототип и тест. Особенно важно, если вы используете инструмент или фреймворк впервые. По крайней мере, проверить основные функциональные возможности, прежде чем приступить к подходу. Компания, на которую я когда-то работал, потратила десятки тысяч фунтов на решение ETL. На следующий день после установки мы обнаружили, что он не поддерживает наш инструмент CRM. Обходного пути не найдено, и мы были вынуждены купить второй инструмент ETL. Очень дорогая ошибка.

Не стремитесь к движущейся цели. В идеале, новая и старая система ETL должны использовать одни и те же исходные данные и заполнять одни и те же таблицы отчетности. Это значительно упрощает тестирование. Это позволяет вам работать в двух направлениях. Это позволяет вам вернуться к старому решению, если вам нужно. Сохраните новый модный материал для второго выпуска.

Код. Не пишите код, пока не будут выполнены все остальные шаги (кроме прототипов / тестов). Когда вы полностью понимаете проблему, код (почти) пишет сам.

Для контекста; Я управляю хранилищем данных с 3 миллиардами записей для большой международной сети. Я сделал каждую ошибку, против которой я вас предупреждаю.