Загрузка данных (постепенно) в Amazon Redshift, S3 vs DynamoDB vs Insert

У меня есть веб-приложение, которое должно отправлять отчеты о его использовании, я хочу использовать Amazon RedShift в качестве хранилища данных для этой цели, Как я должен собирать данные ?

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

Что я упустил? Я должен использовать в DynamoDB, я должен использовать простые вставить вместо красного смещения !?
Если мне нужно записать данные в DynamoDB, я должен удалить таблицу hold после копирования .. что самое лучшее практики ?

в любом случае, каковы наилучшие методы, чтобы избежать дублирования данных в RedShift ?

спасибо за помощь!

25
amazon-dynamodb amazon-ec2 amazon-redshift amazon-s3 amazon-web-services

5 ответов

желательно совокупность журналы событий, прежде чем принимать их в Amazon Redshift.

преимущества:

  • вы будете использовать параллельно природа красного смещения лучше; скопировать на наборе больших файлов в S3 (или из большой таблицы DynamoDB) будет много быстрее, чем отдельные вставки или копии небольшого файла.

  • Вы можете предварительной сортировки ваши данные (особенно, если сортировка основана на времени события) перед загрузкой в Redshift. Это также улучшить производительность нагрузки и уменьшить потребность в пылесос таблиц.

вы можете накапливать свои события в нескольких местах, прежде чем агрегировать и загружать их в Redshift:

  • локальный файл в S3 - наиболее распространенный способ-агрегировать ваши журналы на клиенте / сервере и каждые X MB или Y минут загрузки их С3. Есть много приложений журнала, которые поддерживают эту функцию, и вам не нужно вносить какие-либо изменения в код (например, FluentD или настройки log4j). Это можно сделать только с конфигурацией контейнера. Недостатком является то, что вы рискуете потерять некоторые журналы, и эти локальные файлы журналов могут быть удалены до загрузки.

  • в DynamoDB - как описал @Swami, DynamoDB-очень хороший способ аккумулировать события.

  • Amazon Kinesis - недавно выпущенный сервис также является хорошим способом для быстрой и надежной передачи ваших событий с различных клиентов и серверов в центральное расположение. События расположены в порядке вставки, что позволяет легко загрузить его позже, предварительно отсортировав в Redshift. События хранятся в Kinesis в течение 24 часов, и вы можете запланировать чтение из kinesis и загрузку в Redshift каждый час, например, для более высокая производительность.

обратите внимание, что все эти услуги (S3, SQS, DynamoDB и Kinesis) позволяют нажмите события непосредственно от конечных пользователей/устройств, без необходимости проходить через средний веб-сервер. Это может значительно улучшить высокую доступность вашего сервиса (как справиться с повышенной нагрузкой или сбоем сервера) и стоимость системы (вы платите только за то, что используете, и вам не нужно недоиспользовать серверы только для журналов).

см., например, как вы можете получить временные маркеры безопасности для мобильных устройств здесь:http://aws.amazon.com/articles/4611615499399490

еще один важный набор инструментов для прямого взаимодействия с этими сервисами-различные SDKs. Например, для Java, .NET, JavaScript, iOS и Android.

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

тем не менее, вы можете сделать эту проверку в Redshift. Хорошей практикой является COPY данные в промежуточные таблицы а потом ... --85-->ВЫБОР хорошо организованная и отсортированная таблица.

еще одна лучшая практика, которую вы можете реализовать, - иметь ежедневный (или еженедельный) раздел таблицы. Даже если вы хотите иметь одну большую длинную таблицу событий, но большинство ваших запросов выполняется в один день (например, последний день), Вы можете создать набор таблиц с аналогичной структурой (events_01012014, events_01022014, events_01032014...). Тогда вы можете SELECT INTO ... WHERE date = ... С каждой из этих таблиц. Когда захочешь. для запроса данных из нескольких дней можно использовать UNION_ALL.

43

один из вариантов - создать таблицы временных рядов в DynamoDB, где вы создаете таблицу каждый день или неделю в DynamoDB для записи каждого взаимодействия с пользователем. В конце периода времени (день, час или неделя) можно скопировать журналы в Redshift.

более подробную информацию см. В таблице временных рядов DynamoDB: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.TimeSeriesDataAccessPatterns

и этот блог:

http://aws.typepad.com/aws/2012/09/optimizing-provisioned-throughput-in-amazon-dynamodb.html

для копии DynamoDB Redshift: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB.html

надеюсь, что это помогает.

6

хотя здесь уже есть принятый ответ, AWS запустила новый сервис под названием Kinesis Firehose который обрабатывает агрегацию в соответствии с пользовательскими интервалами, временную загрузку в s3 и загрузку (сохранение) в redshift, повторные попытки и обработку ошибок, управление пропускной способностью и т. д...

Это, вероятно, самый простой и надежный способ сделать это.

2

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

Они используют Cloudfront для этого. Что вы можете сделать, это разместить пиксель в одном из ведер S3 и поместить это ведро за распределение CloudFront в качестве источника. Включите журналы в ведро S3 для того же CloudFront.

вы можете отправлять журналы как url параметры всякий раз, когда вы вызываете этот пиксель на своем клиенте (аналогично Google analytics). Затем эти журналы можно обогатить и добавить в базу данных Redshift с помощью Copy.

Это решает цель агрегирования журналов. Эта установка будет обрабатывать все это для вас.

вы также можете посмотреть на Piwik для, который является открытым исходным кодом Analytics и посмотреть, если вы можете изменить его в соответствии с вашими нуждами.

1

вы можете записать данные в CSV-файл на локальный диск, а затем запустить скрипт Python/boto/psycopg2 для загрузки данных в Amazon Redshift.

в своем CSV_Loader_For_Redshift Я делаю просто:

  1. сжатие и загрузка данных в S3 с помощью бото модуль Python и многострочная загрузка.

    conn = boto.connect_s3(AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY)
bucket = conn.get_bucket(bucket_name)
k = Key(bucket)
k.key = s3_key_name
k.set_contents_from_file(file_handle, cb=progress, num_cb=20, 
reduced_redundancy=use_rr )

  2. использовать psycopg2 копировать команду для добавления данных в таблицу Redshift.

    sql="""
copy %s from '%s' 
CREDENTIALS 'aws_access_key_id=%s;aws_secret_access_key=%s' 
DELIMITER '%s' 
FORMAT CSV %s 
%s 
%s 
%s;""" % (opt.to_table, fn, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,opt.delim,quote,gzip, timeformat, ignoreheader)
1