как использовать GZIP для сжатия JSON данных в python программе?

Question

У меня есть программа AWS Kinesis python - Producer для отправки данных в мой поток. Но мой файл JSON - 5 МБ. Я хотел бы сжать данные с помощью GZIP или других лучших методов. Мой код производителя выглядит следующим образом:

import boto3
import json
import csv
from datetime import datetime
import calendar
import time
import random



# putting data to Kinesis

my_stream_name='ApacItTeamTstOrderStream'

kinesis_client=boto3.client('kinesis',region_name='us-east-1')


with open('output.json', 'r') as file:
    for line in file:
        put_response=kinesis_client.put_record(
            StreamName=my_stream_name,
            Data=line,
            PartitionKey=str(random.randrange(3000)))
    
        print(put_response)

мое требование:

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

Поскольку я новичок в этом, может ли кто-нибудь помочь мне или предложить мне, какие программы я должен добавить в существующий код?

Answer 1

Есть 2 способа сжатия данных:

1. Включить сжатие GZIP / Snappy в потоке Firehose - это можно сделать через саму консоль

Firehose буферизует данные, и после достижения порогового значения он берет все данные и сжимает их вместе для создания объекта gz.

Плюсы :

• Минимальные усилия, необходимые на стороне производителя - просто измените настройку в консоли.
• Минимальные усилия, необходимые на стороне потребителя - Firehose создает объекты .gz в S3 и устанавливает метаданные для объектов, отражающие тип сжатия. Следовательно, если вы читаете данные через AWS SDK, SDK выполнит распаковку за вас.

Минусы :

• Поскольку Если вы используете Firehose, вы не будете экономить на расходах Firehose. Вы сэкономите на стоимости S3 (за счет меньшего размера объектов).

2. Сжатие кодом производителя - Необходимо написать код

Я реализовал это в Java несколько дней назад. Мы загружали более 100 петабайт данных в Firehose (откуда они записывались в S3). Для нас это была огромная сумма.

Итак, мы решили сделать сжатие на стороне продюсера. В результате в KF поступают сжатые данные, которые записываются в S3. Обратите внимание: поскольку KF не сжимает его, он не знает, какие это данные. В результате объекты, созданные в s3, не имеют сжатия ".gz". Следовательно, потребители не знают, какие данные находятся в объектах. Затем мы написали оболочку поверх AWS Java SDK для S3, которая считывает объект и распаковывает его.

Плюсы:

• Наше сжатие коэффициент был близок к 90%. Это напрямую привело к экономии 90% затрат на Firehose. Плюс дополнительная экономия S3, как в подходе 1.

Минусы:

• Не совсем минус, но потребуются дополнительные усилия по разработке. Чтобы создать оболочку поверх AWS SDK, необходимо выполнить тестирование и c.
• Сжатие и декомпрессия требуют больших ресурсов ЦП. В среднем, эти 2 вместе увеличили загрузку ЦП на 22%.