Загрузка данных (поэтапно) в Amazon Redshift, S3 vs DynamoDB vs Insert
У меня есть веб-приложение, которое должно отправлять отчеты об использовании, я хочу использовать Amazon RedShift в качестве хранилища данных для этой цели,
Как мне собрать данные?
Каждый раз, когда пользователь взаимодействует с моим приложением, я хочу сообщить об этом. Поэтому, когда я должен писать файлы на S3? и сколько?
Я имею в виду:
- Если вы не отправляете информацию немедленно, я могу потерять ее в результате потерянного соединения или из-за ошибки в моей системе, когда она была собрана, и приготовьтесь к отправке на S3...
- Если я пишу файлы на S3 при каждом взаимодействии с пользователем, у меня в итоге появятся сотни файлов (у каждого файла будут минимальные данные), которые нужно будет управлять, сортировать, удалять после копирования в RedShift.. эта доза не кажется как хорошее решение.
Что мне не хватает? Должен ли я использовать DynamoDB вместо этого, должен ли я использовать простую вставку в Redshift вместо этого??
Если мне нужно записать данные в DynamoDB, я должен удалить таблицу удержания после копирования. Каковы наилучшие методы?
В любом случае, какие наилучшие методы избегают дублирования данных в RedShift?
Цените помощь!
Ответы
Ответ 1
Рекомендуется, чтобы журналы событий заполнить, прежде чем принимать их в Amazon Redshift.
Преимущества:
-
Лучше используйте параллельный характер Redshift; COPY в наборе больших файлов в S3 (или из большой таблицы DynamoDB) будет намного быстрее, чем отдельные INSERT или COPY небольшой файл.
-
Вы можете предварительно сортировать свои данные (особенно, если сортировка основана на времени события) перед загрузкой в Redshift. Это также повышает производительность вашей загрузки и уменьшает необходимость в VACUUM ваших таблиц.
Вы можете накапливать свои события в нескольких местах, прежде чем агрегировать и загрузить их в Redshift:
-
Локальный файл для S3 - наиболее распространенным способом является объединение ваших журналов на клиенте/сервере, и каждый x Мб или y минут загружают их на S3. Существует много приложений для журналов, которые поддерживают эту функциональность, и вам не нужно вносить какие-либо изменения в код (например, FluentD или Log4J). Это можно сделать только с конфигурацией контейнера. Нижняя сторона заключается в том, что вы рискуете потерять несколько журналов, и эти локальные файлы журналов можно удалить перед загрузкой.
-
DynamoDB - как описано в @Swami, DynamoDB - очень хороший способ накопления событий.
-
Amazon Kinesis - недавно выпущенная услуга также является хорошим способом потоковой передачи ваших событий от различных клиентов и серверов до центральное место в быстром и надежном режиме. События в порядке вставки, что позволяет легко загрузить его позже, предварительно отсортированный в Redshift. События хранятся в Kinesis в течение 24 часов, и вы можете планировать чтение из кинезиса и загружать его в Redshift каждый час, например, для повышения производительности.
Обратите внимание, что все эти службы (S3, SQS, DynamoDB и Kinesis) позволяют напрямую удалять события у конечных пользователей/устройств без необходимости проходить через средний веб-сервер. Это может значительно улучшить высокую доступность вашего сервиса (как справиться с повышенной нагрузкой или сбоем сервера) и стоимостью системы (вы платите только за то, что используете, и вам не нужно использовать недоиспользуемые серверы только для журналов).
См. например, как вы можете использовать токены безопасности для мобильных устройств здесь: http://aws.amazon.com/articles/4611615499399490
Другим важным набором инструментов для прямого взаимодействия с этими службами являются различные SDK. Например, для Java, .NET, JavaScript, iOS и Android.
Относительно требования дедупликации; в большинстве опций выше вы можете сделать это на этапе агрегации, например, когда вы читаете поток Kinesis, вы можете проверить, что у вас нет дубликатов в ваших событиях, но анализируется большой буфер событий перед тем, как положить в хранилище данных.
Однако вы можете выполнить эту проверку и в Redshift. Хорошей практикой является COPY
данные в промежуточных таблицах, а затем SELECT INTO - хорошо организованная и отсортированная таблица.
Еще одна лучшая практика, которую вы можете реализовать, - иметь ежедневный (или еженедельный) раздел таблицы. Даже если вы хотите иметь одну большую таблицу длинных событий, но большинство ваших запросов работают в один день (например, в последний день), вы можете создать набор таблиц с аналогичной структурой (events_01012014, events_01022014, events_01032014...). Затем вы можете SELECT INTO ... WHERE date = ...
к каждой из этих таблиц. Если вы хотите запросить данные за несколько дней, вы можете использовать UNION_ALL.
Ответ 2
Один из вариантов рассмотрения - создать таблицы временных рядов в 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
Для копии Redshift DynamoDB: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB.html
Надеюсь, что это поможет.
Ответ 3
Хотя уже есть принятый ответ, AWS запустила новую службу под названием Kinesis Firehose, которая обрабатывает агрегацию в соответствии с пользовательскими интервалами, временная загрузка на s3 и загрузка (SAVE) на красное смещение, повторы и обработку ошибок, управление пропускной способностью и т.д.
Это, наверное, самый простой и надежный способ сделать это.
Ответ 4
Просто будучи немного эгоистичным и описывая, что именно Snowplow, платформа аналитики событий делает это. Они используют этот удивительный уникальный способ сбора журналов событий от клиента и агрегирования его на S3.
Они используют Cloudfront для этого. Что вы можете сделать, так это размещать пиксель в одном из ведер S3 и помещать это ведро за дистрибутив CloudFront в качестве источника. Включите журналы в ведро S3 для того же CloudFront.
Вы можете отправлять журналы в качестве параметров URL-адреса, когда вы вызываете этот пиксель на своем клиенте (аналогично аналитике google). Эти журналы затем могут быть обогащены и добавлены в базу данных Redshift с помощью Copy.
Это решает задачу агрегирования журналов. Эта настройка будет обрабатывать все это для вас.
Вы также можете заглянуть в Piwik, который является службой аналитики с открытым исходным кодом, и посмотреть, можете ли вы изменить ее, которая соответствует вашим потребностям.
Ответ 5
Вы можете записать данные в CSV файл на локальном диске, а затем запустить Python/boto/psycopg2 script для загрузки данных в Amazon Redshift.
В моем CSV_Loader_For_Redshift Я просто так:
-
Сжатие и загрузка данных на S3 с помощью boto Модуль 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 )
-
Используйте psycopg2 Команда COPY для добавления данных в таблицу 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)