Передача данных из Kinesis (или s3) в задание RDS postgres chron - PullRequest
Новая
       64

Передача данных из Kinesis (или s3) в задание RDS postgres chron

0 голосов
/ 18 октября 2018

Я довольно новичок в AWS и пытаюсь найти способ надежной передачи данных из потока Kinesis в таблицу базы данных AWS RDS postgres.Записи должны будут подвергаться небольшому преобразованию при входе, например фильтр (не все записи будут вставлены, в зависимости от ключа) и анализироваться для вставки в postgres.В настоящее время данные из потока Kinesis сбрасываются пожарным шлангом в ведра S3 в виде паркета.

Я немного растерян во многих возможных способах сделать это, например:

  • Потоки Kinesis -> Firehose -> Лямбда -> RDS
  • Потоки Kinesis -> Firehose -> S3 -> Задание ETL конвейера данных -> RDS
  • Миграция базы данных для S3-> RDS?
  • Клей AWS?
  • другие ...?

В мире, где нет сервера, я бы выполнял хронологическую работу каждый, скажем, одинчас, который будет занимать файлы в самом последнем сегменте сегмента S3 (это год / месяц / день / час), то есть самый последний час, и отфильтровывать записи, которые не нужны в RDS, и выполнять массовую вставку остальных в RDS.,Я не хочу иметь экземпляр EC2, который бездействует 95% времени, чтобы сделать это.Любой совет?

1 Ответ

0 голосов
/ 20 октября 2018

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

Для Firehose, IMO, это интереснокогда у вас есть много данных в режиме реального времени для приема.Что касается AWS Glue, для меня это больше похоже на «управляемый» Apache Spark, поэтому, если у вас есть логика обработки данных для реализации в большом количестве пакетных данных, это может быть интересно.Но, по твоему описанию, дело не в этом, верно?

Подводя итог, если вы думаете, что объем вставленных данных всегда будет по-прежнему составлять несколько мегабайт, для меня самое простое решение - лучшее, то есть Kinesis -> Lambda -> RDS, возможно, с другой Lambda.для резервного копирования данных на S3 (срок хранения Kinesis ограничен 7 днями).Это особенно интересно с точки зрения ценообразования - очевидно, у вас не так много данных, Lambda выполняется по требованию, например, путем пакетирования 1000 записей Kinesis, так что это хороший повод сэкономить немного денег.В противном случае, если вы ожидаете, что у вас будет все больше и больше данных, использование версии «Firehose -> Lambda» будет для меня более подходящим, поскольку вы не загружаете базу данных большим объемом данных одновременно.

...