Лучший способ дедупликации от пожарного шланга - PullRequest
Новая
       28

Лучший способ дедупликации от пожарного шланга

0 голосов
/ 22 мая 2018

Каков наилучший и наиболее экономичный способ дедупликации событий, записанных из firehose в s3?

Мой сценарий: у меня есть несколько источников, которые записывают свои события в виде JSON в поток пожарных шлангов kinesis.Поток записывает события в корзину s3.Чем события должны быть проанализированы с помощью athena.

Итак, поскольку пожарный шланг не гарантирует отсутствие дубликатов, я должен каким-то образом дедуплицировать данные.И я также должен как-то разделить их для Афины.

Способы, которые я придумал до сих пор:

  • Использование кластера EMR (например, каждый день) для выполнения дедупликации исекционирования.Но это требует больших затрат и не рекомендуется запускать чаще, чем один день, чтобы быть экономически эффективным
  • Используйте запланированную лямбда-функцию, которая дедуплицирует текущее временное окно.И еще одна лямбда, которая разбивает данные.Затраты: я не знаю, потому что никогда раньше не использовал лямбду.

Есть ли лучший, более элегантный и экономичный способ?

1 Ответ

0 голосов
/ 30 мая 2018

Прежде всего, я думаю, вы должны подумать о том, сколько стоит отсеивать дубликаты, а не о том, как часто Firehose будет доставлять дубликаты.Я думаю, что очень редко вы получаете дубликаты из-за самого Firehose, но если у вас есть продюсеры, которые также могут в конечном итоге посылать дубликаты на ваш Firehose, вы все равно, возможно, захотите их обработать.

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

Если у вас нет много данных, вы можете оплатитьцена на стороне чтения вместо обработки, например, перезаписи данных.SELECT DISTINCT * FROM table должен удалить дубликаты строк.Если ваши запросы содержат агрегации, вы делаете SELECT column, COUNT(*) FROM (SELECT DISTINCT * FROM table) - или какой-то вариант SELECT foo, MIN(bar), MIN(baz) GROUP BY 1, если у вас есть столбец, который должен быть уникальным.Поскольку Athena взимает плату за отсканированные данные, а не за вычислительные ресурсы, это не будет стоить дополнительных затрат, но, конечно, будет медленнее.

Я бы не рекомендовал это решение, если у вас много данных, и в этом случае, я думаю,в любом случае вам нужно иметь дополнительный шаг в конвейере, потому что вам также не следует запрашивать данные, полученные Firehose как есть.Вам нужно создать секционированную таблицу и добавлять каждый час, день или месяц как отдельный раздел (в зависимости от того, сколько именно данных мы говорим).Вы можете сделать это, не перемещая данные, но, поскольку вы все равно должны сделать дополнительный шаг, вы также можете добавить дедупликацию туда же - и если вы посмотрите на использование Glue ETL, это может быть менее затратно для вас, чем EMR.

...