Часто задаваемые вопросы о сервисе Данные Amazon Firehose

API Firehose доступны в пакетах SDK Amazon Web Services. Перечень языков и платформ программирования, поддерживаемых SDK Amazon Web Services, см. на странице Инструменты для работы с Amazon Web Services.

Агент Kinesis – это готовое приложение Java, позволяющее легко собирать и отправлять данные в поток Firehose. Этот агент можно устанавливать в серверных средах Linux, включая веб‑серверы, серверы журналов или баз данных. Агент выполняет мониторинг определенных файлов и непрерывно отправляет данные в поток Firehose. В настоящее время Агент Amazon Kinesis поддерживает Amazon Linux, Red Hat Enterprise Linux и Microsoft Windows. Дополнительную информацию см. на странице Запись с помощью агентов.

Чтобы загрузить и установить Агент Kinesis, необходимо использовать указанные ниже команду и ссылку.

• В Amazon Linux: sudo yum install -y aws-kinesis-agent
• В Red Hat Enterprise Linux: sudo yum install -y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm
• Загрузка из GitHub: awlabs/amazon-kinesis-agent
• В Windows: https://docs.aws.amazon.com/kinesis-agent-windows/latest/userguide/getting-started.html#getting-started-installation

Добавить данные в поток Firehose можно с помощью Агента Kinesis или операций PutRecord и PutRecordBatch сервиса Firehose. Операция PutRecord позволяет одним вызовом API добавить одну запись данных, а операция PutRecordBatch – одним вызовом API добавить несколько записей данных. Дополнительную информацию см. в разделах PutRecord и PutRecordBatch.

При создании или обновлении потока данных Firehose через консоль AWS или API Firehose можно настроить кластер или тему Amazon MSK в качестве источника потока Firehose. После настройки Firehose будет автоматически считывать данные из темы MSK и загружать их в указанные корзины S3.

Вы можете уменьшить сложность операций и дополнительные расходы приложения, преобразовывая и загружая потоковые данные, полученные из своих тем Amazon MSK, в Amazon S3 без написания кода. Например, в Amazon MSK и Firehose нет кода, встроенных функций преобразования и трансформации данных (таких как преобразование форматов Parquet/ORC), а также буферизации и проверки данных на стороне сервера. Вы получаете доступ к другим функциям, например автоматической повторной попытке доставки, хранению данных, автомасштабированию и дублированию, что обеспечивает надежную доставку данных.

Чтобы использовать эту функцию, необходимо включить в кластеры MSK общедоступные адреса или частные ссылки.

Да, Firehose можно подключать к кластерам Amazon MSK, доступным в разных аккаунтах AWS. Сервис Firehose также может доставлять данные в корзины S3, которые принадлежат разным аккаунтам.

Контрольным временем для начала использования данных из темы Amazon MSK является время создания потока Firehose. Firehose не считывает пользовательские значения смещения.

При создании или обновлении потока данных Firehose через консоль AWS или API Firehose можно настроить поток Kinesis в качестве источника потока Firehose. После настройки Firehose будет автоматически считывать данные из потока Firehose и загружать их в указанные конечные точки.

Сервис Firehose выполняет вызов GetRecords() к потокам данных Amazon Kinesis один раз в секунду для каждого сегмента Kinesis.

Сервис Firehose начинает считывать данные с ПОСЛЕДНЕЙ позиции потока данных Amazon Kinesis, когда он настроено в качестве источника потока Firehose. Для получения дополнительной информации о позиции в потоке данных Amazon Kinesis см. раздел GetShardIterator руководства по API сервиса Потоки данных Amazon Kinesis.

Да, можно. Но обратите внимание, что вызов GetRecords() от сервиса Firehose учитывается при сравнении параметров потока с установленными лимитами для сегмента Kinesis, поэтому следует планировать работу потока данных Firehose с учетом других приложений Kinesis, чтобы убедиться, что лимиты не превышены. Дополнительную информацию см. в разделе Лимиты потоков данных Amazon Kinesis руководства по данному сервису для разработчиков.

Нет, нельзя. Если поток данных Kinesis настроен в качестве источника потока Firehose, операции Firehose PutRecord и PutRecordBatch отключаются. Добавлять данные в поток данных Amazon Kinesis следует через операции PutRecord и PutRecords данного сервиса.

Добавление в поток Firehose данных из AWS IoT выполняется созданием действия AWS IoT, с помощью которого события отправляются в поток данных Firehose. Подробнее См. раздел Запись в сервисе Данные Amazon Firehose с использованием AWS IoT Руководства для разработчиков по Firehose.

При создании или обновлении потока Firehose через консоль AWS или API Firehose вы можете настроить Direct PUT в качестве источника потока Firehose. После создания потока вы можете настроить созданный поток Firehose в качестве потока Firehose в разделе Vended Logs консоли VPC Flow logs.

Добавить в поток Firehose данные журналов Amazon CloudWatch можно, создав фильтр подписки на журналы CloudWatch, который отправляет события в поток Firehose. Дополнительную информацию см. в разделе Использование фильтров подписки на журналы CloudWatch Logs руководства пользователя Amazon CloudWatch.

Чтобы добавить в поток Firehose данные Событий Amazon CloudWatch, требуется создать правило CloudWatch Events с потоком Firehose качестве конечной точки. Дополнительную информацию см. в разделе Запись в сервисе Данные Amazon Firehose с помощью События Amazon CloudWatch Руководства для разработчиков по Firehose.

Данные в поток Firehose добавляются из консоли AWS EventBridge. Дополнительные сведения см. в документации по AWS EventBridge.

Сервис Firehose позволяет шифровать данные после доставки в корзину Amazon S3. При создании потока Firehose можно настроить шифрование данных с помощью принадлежащего пользователю ключа Сервиса управления ключами AWS (AWS KMS). Дополнительные сведения о KMS см. на странице Сервис управления ключами AWS.

Firehose применяет указанную роль IAM для доступа к ресурсам, таким как корзина Amazon S3 или домен Amazon OpenSearch. Подробнее см. в разделе Управление доступом с помощью сервиса Firehose руководства для разработчиков Firehose.

Да, Firehose использует AWS PrivateLink для подключения к базам данных, находящимся в VPC.

Да, когда вы настраиваете поток доставки Firehose, можно выбрать определенные таблицы и столбцы в исходной базе данных. Firehose предоставляет обновления CDC только для выбранных таблиц и столбцов.

Да, когда вы настраиваете Firehose для доставки потоков CDC в таблицы Apache Iceberg на Amazon S3, можно задать поток для доставки записей из разных исходных таблиц в иные таблицы Apache Iceberg.

Firehose может преобразовать необработанные данные или данные Json в форматы, необходимые для целевых хранилищ данных (например, Apache Parquet и Apache ORC), без необходимости создания собственных конвейеров обработки данных. С помощью сервиса Firehose вы можете динамически разделять данные потоковой передачи перед их доставкой в S3 с помощью статически или динамически определенных ключей, например «customer_id» или «transaction_id». Firehose группирует данные по этим ключам и доставляет их в уникальные префиксы S3, что упрощает выполнение высокопроизводительного и экономичного анализа в S3 с помощью Athena, EMR и Redshift Spectrum.

В дополнение к встроенной функции конвертации формата данных в сервис Firehose вы также можете использовать функцию AWS Lambda для подготовки и преобразования необработанных входных данных в потоке Firehose перед их загрузкой в конечные точки. Настроить функцию AWS Lambda для преобразования данных можно при создании нового потока Firehose или изменении существующего. Amazon создал несколько версий Lambda, так что вы можете выбрать ту, что подходит вам для быстрого старта. Полный список см. в руководстве для разработчиков сервиса Данные Amazon Firehose.

Сервис данных Amazon Firehose позволяет сжимать данные перед их доставкой в Amazon S3. Сервис в настоящее время поддерживает форматы сжатия GZIP, ZIP и SNAPPY. Если в дальнейшем данные будут загружаться в Amazon Redshift, поддерживается только формат GZIP.

Возможность подписки на журналы CloudWatch можно использовать для потоковой передачи данных журналов CloudWatch в сервис Firehose. Все события из журналов CloudWatch уже сжаты в формате gzip, поэтому рекомендуется отключить сжатие в настройках Firehose, чтобы избежать двойного сжатия. Дополнительную информацию о функции подписки на Журналы Amazon CloudWatch см. в разделе Фильтры подписки с использованием сервиса «Данные Amazon Firehose» руководства для пользователей Журналов Amazon CloudWatch.

Все преобразованные записи из Lambda должны возвращаться в Firehose с указанными ниже тремя параметрами, иначе сервис Firehose будет отклонять эти записи и обрабатывать их как сбой, произошедший во время преобразования данных.

• recordId. Firehose передает параметр recordId вместе с каждой записью в Lambda во время вызова функции. Каждая преобразованная запись должна быть возвращена с точно таким же параметром recordId. Любое несоответствие между исходным параметром recordId и возвращенным параметром recordId будет рассматриваться как сбой при преобразовании данных.
   
• result. Статус результата преобразования каждой записи. Для этого параметра допустимы следующие значения. «Ok», если запись была успешно преобразована в штатном режиме. «Dropped», если в используемом алгоритме обработки запись была намеренно пропущена в штатном режиме. «ProcessingFailed», если преобразовать запись в штатном режиме не удалось. Сервис Firehose рассматривает возвращенные записи со статусами «Ok» и «Dropped» как успешно обработанные записи, а записи со статусом «ProcessingFailed» – как неудачно обработанные записи, когда он генерирует метрики SucceedProcessing.Records и SucceedProcessing.Bytes.
   
• data. Преобразованные полезные данные после кодирования по схеме Base64.

Если включить преобразование данных с помощью Lambda, сервис Firehose может регистрировать любые ошибки, связанные с вызовами функций Lambda и доставкой данных, в журналах Amazon CloudWatch Logs, поэтому при сбое вызова функции Lambda или доставки в журналах можно посмотреть, какая именно ошибка произошла. Дополнительную информацию см. в разделе Мониторинг с помощью сервиса Журналы Amazon CloudWatch.

Если используется преобразование данных с помощью Lambda, можно включить резервное копирование исходных записей, после чего сервис Данные Amazon Firehose будет сохранять входные данные (до преобразования) в отдельную корзину S3. Можно указать дополнительный префикс, который будет добавляться перед префиксом времени UTC в формате «ГГГГ/ММ/ДД/ЧЧ», генерируемым Firehose.

С помощью динамического разделения Firehose можно устранять сложности и задержки, связанные с ручным разделением в источнике или после сохранения данных, а также обеспечить более быструю аналитику для запросов, касающихся оптимизированных наборов данных. Благодаря этому наборы данных немедленно становятся доступными для инструментов аналитики для эффективного выполнения запросов, а контроль доступа к данным становится строже. Например, клиенты, занимающиеся автоматизацией маркетинга, могут на ходу разделять данные по идентификаторам клиентов, что позволяет конкретным клиентам запрашивать оптимизированные наборы данных и быстрее получать результаты. Клиенты, занимающиеся ИТ-операциями или мониторингом безопасности, могут создавать группы на основе меток времени событий, встроенных в журналы, чтобы иметь возможность запрашивать оптимизированные наборы данных и быстрее получать результаты. Благодаря этой функции, а также возможности сервиса «Данные Amazon Firehose» преобразовывать формат JSON в Parquet, сервис является идеальным вариантом потокового ETL для S3.

Настроить динамическое разделение данных в Firehose можно с помощью Консоли управления AWS, CLI или SDK. После создания или обновления потока Firehose выберите Amazon S3 в качестве конечной точки для потока Firehose и включите динамическое разделение. Вы можете указать ключи или создать выражение, которое будет оцениваться во время работы для определения ключей, используемых для разделения. Например, вы можете выбрать поле данных в потоке входящих данных, таких как ID пользователя, и определить выражение префикса S3, например customer_id=!{partitionKey:customer_id}/, которое будет оцениваться во время работы на основе полученных записей, чтобы определить, для каких префиксов S3 доставляются записи.

Firehose поддерживает преобразование форматов Parquet и Orc без предварительной настройки при записи данных в Amazon S3. Firehose также имеет встроенную функцию Lambda, поэтому вы можете написать свой код для преобразования. Кроме того, с помощью сервиса Firehose можно извлекать ключевые поля данных из записей в формате JSON. Сервис Firehose также поддерживает язык синтаксического анализа JQ для преобразования этих ключей для разделения. Дополнительную информацию см. в руководстве для разработчиков Firehose.

Да. Сервис Firehose может создавать резервную копию всех непреобразованных записей в корзине S3 параллельно с доставкой преобразованных записей в конечные точки. Резервное копирование исходной записи можно включить при создании или обновлении потока Firehose.

Частота доставки данных в Amazon S3 определяется значениями размера и интервала буфера корзины S3, настроенными для потока Firehose. Прежде чем доставить входящие данные в Amazon S3, сервис Firehose выполняет их буферизацию. Можно настроить размер буфера корзины S3 (от 1 до 128 МБ) или интервал буферизации (от 0 до 900 секунд), в результате условие, выполненное первым, будет инициировать доставку данных в Amazon S3. Если включено динамическое разделение данных Apache Parquet, размер буфера определяется в МБ в диапазоне от 64 МБ до 128 МБ для конечной точки Amazon S3 при значении по умолчанию 128 МБ. Обратите внимание: в том случае, когда доставка данных в конечную точку отстает от записи в поток Firehose, сервис Firehose динамически увеличивает размер буфера, чтобы ликвидировать отставание и обеспечить доставку всех данных в конечную точку.

Размер буфера вычисляется до сжатия данных. В результате, если вы решите сжимать данные, размер объектов в корзине Amazon S3 может оказаться меньше заданного размера буфера.

Пользователь Redshift должен обладать правом на выполнение операции Redshift INSERT для копирования данных из корзины Amazon S3 в инстанс Redshift.

Если инстанс Redshift находится в VPC, для предоставления сервису Данные Amazon Firehose доступа к этому инстансу Redshift требуется разблокировать IP‑адреса Firehose в данном VPC. Дополнительную информацию о разблокировании IP‑адресов в VPC см. в разделе Предоставление Firehose доступа к сервису Amazon Redshift в качестве конечной точки руководства для разработчиков Данных Amazon Firehose.

Если в качестве конечной точки выбрано решение Redshift, сервис «Данные Amazon Firehose» доставляет данные сначала в корзину Amazon S3, а затем выполняет команду Redshift COPY для загрузки данных из корзины S3 в указанный инстанс Redshift.

В настоящее время один поток Firehose может доставлять данные только в одну таблицу Snowflake. Для доставки данных в несколько таблиц Snowflake необходимо создать несколько потоков Firehose.

Firehose использует для Snowflake семантику строго однократной доставки. Это означает, что каждая запись будет доставлена в Snowflake ровно один раз, даже в случае ошибок или повторных попыток. Но учтите, что строго однократная доставка не гарантирует отсутствия дубликатов в данных, поскольку дублирование может происходить на стороне источника данных или в других частях конвейера ETL.

Мы ожидаем, что большинство потоков данных будет доставляться не позднее 5-ти секунд.

Сервис Amazon OpenSearch упрощает интерактивный анализ журналов, мониторинг приложений в режиме реального времени, поиск на веб-сайтах и многие другие процессы. OpenSearch – это комплект с открытым исходным кодом для распределенного поиска и аналитики, созданный на базе Elasticsearch. В сервисе Amazon OpenSearch включены последние версии OpenSearch, поддержка 19 версий Elasticsearch (от версии 1.5 до 7.10) и возможности визуализации на базе панелей OpenSearch и Kibana (версии от 1.5 до 7.10). Нажмите здесь, чтобы получить дополнительную информацию об Amazon OpenSearch.

Firehose может выполнять ротацию индекса сервиса Amazon OpenSearch на основе интервалов времени. Интервал времени можно настроить при создании потока Firehose. Подробнее см. в разделе Ротация индекса для конечной точки сервиса Amazon OpenSearch руководства для разработчиков Данных Amazon Firehose.

При загрузке данных в сервис Amazon OpenSearch сервис Firehose может создавать резервную копию всех данных или только тех данных, которые не удалось доставить. Чтобы воспользоваться этой возможностью и предотвратить потерю данных, необходимо выделить резервную корзину Amazon S3.

Конфигурацию потока Firehose после его создания можно менять в любое время. Это можно делать с помощью консоли Firehose или операции UpdateDestination. В процессе обновления конфигурации поток Firehose будет оставаться в АКТИВНОМ состоянии, что позволяет продолжать отправку данных в этот поток. Обновленные конфигурации обычно вступают в действие в течение нескольких минут.

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

Доставка данных Firehose в другую учетную запись в сервисе Amazon OpenSearch возможна только в том случае, если Firehose и сервис Amazon OpenSearch подключены через общедоступную конечную точку.

А также если Firehose и сервис Amazon OpenSearch подключены к частному облаку VPC. Поток Firehose и целевой домен сервиса Amazon OpenSearch должны находиться в одном аккаунте.

Нет. Поток Firehose и целевой домен сервиса Amazon OpenSearch должны находиться в одном регионе.

Частота доставки данных в сервисе Amazon OpenSearch определяется значениями размера и интервала буфера OpenSearch, заданными для потока Firehose. Firehose выполняет буферизацию входящих данных, прежде чем выполнить их доставку в сервис Amazon OpenSearch. При доставке в OpenSearch можно настроить размер буфера (от 1 до 100 МБ) или интервал буферизации (от 0 до 900 секунд), и условие, исполненное первым, будет инициировать передачу данных в сервис Amazon OpenSearch. Обратите внимание: в том случае, когда доставка данных в конечную точку отстает от записи в поток Firehose, сервис Данные Amazon Firehose динамически увеличивает размер буфера, чтобы ликвидировать отставание и обеспечить доставку всех данных в конечную точку.

Если в качестве конечной точки используется сервис Redshift, сервис Данные Amazon Firehose создает файлы манифеста, чтобы выполнить пакетную загрузку объектов Amazon S3 в инстансы Redshift. В папке manifests хранятся файлы манифеста, созданные Firehose.

Если используется режим «all documents», сервис Данные Amazon Firehose объединяет несколько входящих записей (в зависимости от настроек буферизации для потока Firehose), а затем передает их в корзину S3 как объект S3. Независимо от настроек режима резервного копирования, документы, при доставке которых произошел сбой, передаются в корзину S3 в определенном формате JSON. Он предоставляет дополнительную информацию, например код ошибки и время попытки доставки. Дополнительную информацию см. в разделе Резервное копирование в Amazon S3 при использовании Сервиса Amazon OpenSearch в качестве конечной точки руководства по использованию сервиса Данные Amazon для разработчиков.

В настоящее время поток Firehose может доставлять данные только в одну корзину Amazon S3. Если необходимо доставлять данные в несколько корзин S3, можно создать несколько потоков Firehose.

В настоящее время поток Firehose может доставлять данные только в один инстанс и одну таблицу Redshift. Если необходимо доставлять данные в несколько инстансов или таблиц Amazon Redshift, можно создать несколько потоков Firehose.

В настоящее время поток Firehose может доставлять данные только в один домен и один индекс сервиса Amazon OpenSearch. Если необходимо доставлять данные в несколько доменов и индексов Amazon OpenSearch, можно создать несколько потоков Firehose.

При включении сервиса Firehose для доставки данных в конечную точку сервиса Amazon OpenSearch в VPC сервис Данные Amazon Firehose создает один или несколько эластичных сетевых интерфейсов (ENI) нескольких аккаунтов в VPC для каждой подсети по вашему выбору. Сервис Amazon Firehose использует интерфейсы ENI для доставки данных в VPC. Количество ENI автоматически масштабируется в соответствии с требованиями сервиса.

Да, один поток Firehose может доставлять данные в несколько таблиц Apache Iceberg.

Да, Firehose поддерживает подключение к каталогу данных AWS Glue в другом аккаунте или в другом регионе AWS.

Да, вы можете использовать преобразование данных с помощью Lambda при доставке в таблицы Apache Iceberg. 

По умолчанию каждый поток Firehose может принимать до 2000 транзакций в секунду, 5000 записей в секунду и 5 МБ данных в секунду. Эти пороговые значения можно легко увеличить, отправив форму запроса на повышение ограничений.

Сервис Amazon Firehose использует по меньшей мере одну семантику для доставки данных. В редких случаях (например при тайм-ауте запроса в момент попытки доставки данных) повторная попытка доставки данных сервисом Firehose может привести к возникновению дубликатов, если предыдущий запрос все-таки завершился успешно.

Если источник данных размещен в Direct PUT, а доставка данных в корзину Amazon S3 заканчивается сбоем, то сервис Данные Amazon Firehose будет повторять попытки доставки каждые 5 секунд на протяжении необходимого времени (до 24 часов). Если проблема сохраняется по истечении 24‑часового периода, сервис Amazon Firehose удаляет данные.

Если источником данных является сервис Потоки данных Amazon Kinesis, а доставка данных в корзину Amazon S3 заканчивается сбоем, то Amazon Firehose будет повторять попытки доставки каждые 5 секунд на протяжении времени, заданного в сервисе Потоки данных Amazon Kinesis.

Если доставка данных в инстанс Amazon Redshift заканчивается сбоем, сервис Данные Amazon Firehose повторяет попытки доставки каждые 5 минут на протяжении необходимого времени (до 120 минут). По истечении 120 минут сервис Данные Amazon Firehose пропускает текущий пакет объектов S3, подготовленных для копирования, и переходит к следующему пакету. Информация о пропущенных объектах будет доставлена в корзину S3 в виде файла манифеста, сохраненного в папке ошибок. Его можно использовать для последующей загрузки объектов вручную. Дополнительные сведения о копировании данных вручную с использованием файлов манифеста см. в разделе Определение файлов данных с помощью манифеста.

Если конечной точкой является сервис Amazon OpenSearch, при создании потока Firehose можно задать период повторных попыток в диапазоне от 0 до 7200 секунд. Если доставка данных в домен Amazon OpenSearch заканчивается сбоем, сервис Данные Amazon Firehose повторяет попытку доставки в течение заданного периода. По истечении периода повторных попыток сервис Данные Amazon Firehose пропускает текущий пакет данных и переходит к следующему пакету. Подробные сведения о пропущенных документах передаются в корзину S3 в папку opensearch_failed; ими можно воспользоваться для загрузки документов вручную.

Возможны два варианта возникновения сбоя при попытке сервиса Firehose вызвать функцию Lambda для преобразования данных.

• В первом случае сбой при вызове функции возникает из‑за превышения времени ожидания сети или при достижении лимита вызовов функции Lambda. В подобных случаях возникновения сбоя сервис Firehose по умолчанию повторит вызов три раза, а затем пропустит этот конкретный пакет записей. Пропущенные записи обрабатываются как записи, обработка которых закончилась ошибкой. С помощью API CreateDeliveryStream и UpdateDeliveryStream можно настроить количество попыток вызова (от 0 до 300). Для подобных случаев возникновения сбоя можно также использовать функцию регистрации ошибок Firehose для передачи данных об ошибках в Журналы Amazon CloudWatch. Дополнительную информацию см. в разделе Мониторинг с помощью сервиса Журналы Amazon CloudWatch.
   
• Во втором случае сбой возникает, когда в результате преобразования записи при возвращении данных из функции Lambda устанавливается статус «ProcessingFailed». Firehose обрабатывает эти записи как записи, обработка которых закончилась ошибкой. В подобном случае возникновения сбоя можно использовать возможности журналов Lambda для передачи данных об ошибках в CloudWatch Logs. Подробнее см. в разделе Доступ к сервису Журналы Amazon CloudWatch для AWS Lambda.

В обоих случаях возникновения сбоя неудачно обработанные записи записываются в корзину S3 в папку processing_failed.

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

В папку errors попадают файлы манифеста с информацией об объектах S3, не загруженных в инстанс Redshift из‑за возникновения сбоев. Эти объекты можно впоследствии загрузить вручную с помощью команды COPY сервиса Redshift. Дополнительные сведения о копировании данных вручную с использованием файлов манифеста см. в разделе Определение файлов данных с помощью манифеста.

В папке opensearch_failed хранятся документы, которые не удалось загрузить в Amazon OpenSearch. Что произойдет в случае сбоя доставки данных в домен Amazon OpenSearch? Эти документы можно переиндексировать для загрузки вручную.

В папке processing_failed хранятся записи, которые не удалось преобразовать с помощью функции AWS Lambda. Можно повторить обработку этих записей вручную.

Консоль Firehose отображает основные метрики операций и производительности, например объем входящих данных и объем доставленных данных. К тому же сервис Данные Amazon Firehose интегрирован с метриками Amazon CloudWatch, что позволяет собирать, просматривать и анализировать метрики потоков Firehose. Подробнее о метриках сервиса Данные Amazon Firehose см. в разделе Мониторинг с помощью метрик Amazon CloudWatch руководства по Данным Amazon Firehose для разработчиков.

Сервис «Данные Amazon Firehose» интегрирован с сервисом Журналы Amazon CloudWatch, поэтому при сбое преобразования или доставки данных можно посмотреть соответствующие журналы ошибок. При создании потока Firehose можно включить регистрацию ошибок. Подробнее см. в разделе Мониторинг с помощью сервиса Журналы Amazon CloudWatch руководства для разработчиков сервиса Данные Amazon Firehose.

Сервис «Данные Amazon Firehose» интегрирован с Управлением идентификацией и доступом AWS, благодаря чему можно безопасно управлять доступом пользователей к сервисам и ресурсам AWS. Например, можно создать политику, которая позволит только определенному пользователю или группе пользователей добавлять данные в поток Firehose. Дополнительные сведения об управлении доступом к потоку и контроле такого доступа см. в разделе Управление доступом с помощью сервиса Данные Amazon Firehose.

Сервис «Данные Amazon Firehose» интегрирован с сервисом AWS CloudTrail, который записывает вызовы API AWS для определенного аккаунта и доставляет пользователю файлы журналов. Дополнительную информацию о регистрации вызовов API, а также список поддерживаемых сервисом Данные Amazon Firehose API см. в разделе Регистрация вызовов API сервиса Данные Amazon Firehose с помощью AWS CloudTrail.

В настоящее время сервис Firehose недоступен на уровне бесплатного пользования AWS. Уровень бесплатного пользования AWS – это программа, в рамках которой предлагается бесплатно воспользоваться пробной версией ряда сервисов AWS. Подробнее см. в разделе Уровень бесплатного пользования AWS.

В Firehose вы платите только за используемые ресурсы. Сервис не предусматривает авансовой оплаты или минимальных стартовых взносов. Цены на использование сервиса Данные Amazon Firehose основаны на объеме данных (ГБ), поступающих в Firehose, с округлением каждой записи до ближайших 5 КБ для Direct PUT и потока данных Kinesis в качестве источников. Для журналов Vended в качестве источника ценообразование основано на объеме данных (ГБ), поступающих в Firehose. Дополнительные сведения о сервисе «Данные Amazon Firehose» см. на соответствующей странице цен.

Округление до ближайшего значения, кратного 5 КБ, происходит на уровне записи, а не на уровне операций API. Например, если вызов PutRecordBatch содержит две записи по 1 КБ, объем данных для этого вызова составит 10 КБ (5 КБ на каждую запись).

Нет, расходы, связанные с использованием сервисов Amazon S3, Amazon Redshift, Amazon OpenSearch и AWS Lambda, в том числе стоимость хранилища и запросов, необходимо оплачивать отдельно. Дополнительную информацию см. на страницах цен на Amazon S3, Amazon Redshift, Сервис Amazon OpenSearch и AWS Lambda.

Соглашение об уровне обслуживания (SLA) сервиса Данные Amazon Firehose гарантирует бесперебойную ежемесячную работу сервиса на уровне не менее 99,9 %.

Компенсация по соглашению об уровне обслуживания сервиса Данные Amazon Firehose по условиям нашего соглашения об уровне обслуживания в отношении данного сервиса предоставляется, если его бесперебойная ежемесячная работа в рамках нескольких зон доступности одного региона, в которых запущено задание, составила менее 99,9 % в течение любого оплачиваемого месяца.

С условиями и положениями Соглашения, а также подробностями оформления заявки на компенсацию можно ознакомиться на странице сведений о Соглашении об уровне обслуживания сервиса «Данные Amazon Firehose».