Подходит ли Kinesis для моих нужд? (и другие разные вопросы)

Мне нужно обрабатывать на пике 100 записей в секунду. Эти записи представляют собой простые тела JSON, и их следует собирать, а затем обрабатывать/преобразовывать в базу данных.

Несколько вопросов ...

1) Подходит ли Kinesis для этого? Или SQS лучше подходит?

2) При использовании kinesis хочу ли я использовать примеры Python, как показано здесь: https://aws.amazon.com/blogs/big-data/snakes-in-the-stream-feeding-and-eating-amazon-kinesis-streams-with-python/ или мне следует реализовать своего производителя и потребителя в KCL? Какая разница?

3) Предлагает ли Kinesis что-либо для управления потребителями, или я просто запускаю их на инстансах EC2 и управляю ими самостоятельно?

4) Каков правильный шаблон для доступа к данным - я не могу позволить себе пропустить какие-либо записи, поэтому я предполагаю, что буду извлекать записи из «TRIM_HORIZON», а не «LATEST». Если да, то как мне управлять дубликатами? Другими словами, как мои потребители получают записи из потока и обрабатывают потребителей, которые отключаются, и т. д., и всегда знают, что они извлекают все записи?

Спасибо!


comment
какую обработку планируете делать? Вы заботитесь о том, чтобы сообщения сохраняли свой порядок?   -  person ketan vijayvargiya    schedule 08.02.2017
comment
Эй, сообщения не должны поддерживать порядок, и единственная обработка, которую я буду выполнять потребителем, — это преобразование в другой формат и пересылка в другую службу.   -  person mr-sk    schedule 08.02.2017


Ответы (1)


  1. Kinesis более полезен для потоковой передачи данных или когда вам требуется строгий порядок сообщений. С другой стороны, ваш вариант использования больше похож на решение для буферизации между двумя службами. Итак, я бы предпочел SQS Kinesis. Кроме того, SQS дешевле и проще в работе, и с ним легко справиться с требуемым масштабом.
  2. В примере, которым вы поделились, используются низкоуровневые API-интерфейсы Kinesis. Однако лучше использовать KPL и KCL для реализации ваших производителей и потребителей соответственно, поскольку они предоставляют конструкции более высокого уровня, которые проще использовать.
  3. Вы можете запускать производителей и потребителей Kinesis и SQS на EC2 или Lambda. В последнем случае AWS позаботится об управлении вашим оборудованием.
  4. Да, вы должны пойти с TRIM_HORIZON. Если в ваших данных есть дубликаты, ваши потребители должны позаботиться о них, самостоятельно ведя учет. Что касается потребителей, уходящих из строя и т. д., KCL изящно обрабатывает эти случаи.
person ketan vijayvargiya    schedule 08.02.2017
comment
Спасибо за ответ. Вопросы: 1) Рассмотрю SQS как решение. Спасибо. 2) KPL и KCL кажутся более сложными для запуска с меньшим количеством документации, чем SDK API. Кроме того, похоже, что они работают только на Redhat/RHEL. (По крайней мере, из моего быстрого чтения документации по установке). 3) Понятно, это логично, об этом тоже надо почитать. 4) Итак, если я выберу TRIM_HORIZON, потребитель начнет чтение в начале потока... как мне отметить свое местоположение в потоке. Это shard_iterator, за которым я буду следить, или что-то еще? - person mr-sk; 08.02.2017
comment
я не знаю, используете ли вы низкоуровневые API. но KCL автоматически записывает контрольные точки в DynamoDB, так что вам не нужно беспокоиться об этом самостоятельно - person ketan vijayvargiya; 08.02.2017