Книга Роман с Data Science. Как монетизировать большие данные, страница 24 – Роман Зыков

Среди текстовых форматов файлов наиболее распространены три:

• CSV (comma-separated values) или TSV (tab-separated values).

• JSON (Java Script Object Notation).

• XML (eXtensible Markup Language).

Файлы CSV самые удобные и простые, выглядят они как обычная таблица, где разделитель между столбцами запятая (хотя это может быть табуляция, точка с запятой и т. д.), разделитель между строками (записями) – перенос строки. Парсить (прочитать и разметить поля в собственной программе) такие файлы одно удовольствие. Их очень легко просмотреть в любом редакторе или консоли. Есть у них только пара минусов. Если используется символ разделителя (запятая или иной), то в полях этот символ нужно экранировать, например, обернув все поле кавычками. В то же время в самом поле тоже могут быть кавычки. Придется это поддержать в парсере (программа или код, которая будет читать это файл). Это усложняет работу с такими файлами и иногда приводит к появлению битых записей, которые не удалось распарсить. Второй недостаток – то, что таблица плоская, поэтому невозможно использовать данные со сложной структурой или же придется упаковывать их в сложный формат, например JSON, и размещать в полях как обычный текст.

Year,Make,Model,Description,Price

1997,Ford,E350,"ac, abs, moon",3000.00

1999,Chevy,"Venture ""Extended Edition""","",4900.00

1999,Chevy,"Venture ""Extended Edition, Very Large""",5000.00

1996,Jeep,Grand Cherokee,"MUST SELL! air, moon roof, loaded",4799.00

JSON – формат гораздо более сложный, он является стандартом де-факто для обмена данными в интернете между сервисами. Главная его особенность в том, что там каждая ячейка имеет наименование. Это и плюс, и минус. Плюс – можно размещать сложные структуры, иерархии, очень удобно парсить, легко открыть в текстовом редакторе или браузере. Главный минус JSON – много лишней информации, в то время как в табличных данных именованы столбцы и нет смысла писать названия для каждого значения в таблице, что сильно увеличивает объем файла.

{

"firstName": "Иван",

"lastName": "Иванов",

"address": {

"streetAddress": "Московское ш., 101, кв.101",

"city": "Ленинград",

"postalCode": 101101

},

"phoneNumbers": [5-

"812 123-1234",

"916 123-4567"

]

}

XML-формат менее распространен, чем JSON, в нем любят хранить конфигурации параметров каких-либо систем. Этот формат – конкурент JSON. Для данных я бы все-таки предпочел JSON, он легче и проще. В XML-формате, например, интернет магазины передают информацию о товарах: структуру их каталога, цены, названия, атрибуты товаров.

Иван

Иванов

812 123-1234

916 123-4567

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

• pkl – бинарные объекты Python, прочитав которые с помощью этого языка программирования вы получите в памяти сразу нужную структуру данных, не заморачиваясь с парсингом.

• hdf – иерархический формат структуры данных. В этот формат можно поместить разнородные данные, например товарный каталог магазина, продажи и т. д. В файле содержится метаинформация: названия, типы данных и т. д. Лично я с такими файлами никогда не работал, но они могут быть удобны, когда нужно передать данные сложного проекта другой команде или опубликовать в интернете.

• parquet, avro – это уже форматы, заточенные для больших данных. Как правило, они содержат схему данных (метаинформацию) о типе и названии полей и оптимизированы для использования в таких системах, как Hadoop. Оба формата – примеры бинарного хранения данных, хотя avro может опираться на JSON.

Что еще полезно знать о файлах хранения? Как они хранят метаинформацию. Если кто-то захочет передать файл с данными, то, скорее всего, в CSV-файле в первой строке будут названия полей, но информацию о типе (это число, текст, дата и т. д.) вы не получите, нужно будет дополнительно передать описание полей с файлом, иначе вам придется самим строить предположения. Если же вам передадут JSON или XML, то там уже лучше с типами данных, в этом плане они удобнее.

Базы данных обсудим в главе про хранилища.

Есть три основных способа получить данные:

• прочитать файлы (обсуждали выше);

• сделать запрос к API;

• сделать запрос к базе данных.

Прочитать файл – это самый простой способ: если это CSV-файл, его можно открыть в Microsoft Excel, Google Spreadsheet, OpenOffice и т. д. Все пакеты анализа данных, библиотеки любых языков программирования поддерживают данный формат. Он очень прост и удобен. С JSON и XML придется повозиться и, скорее всего, даже написать небольшой код (маленькая программа) по извлечению нужных вам данных.

Второй способ – сделать запрос к сетевому API (Application Programming Interface). Вы пишете запрос в требуемом API формате, на выходе вам приходит, как правило, JSON, который вы можете обработать, сохранить в файл и т. д. Это требует кодирования, зато работать с такими интерфейсами бывает очень интересно.

Третий способ – базы данных через использование языка программирования SQL. Для разных систем баз данных существуют свои диалекты этого языка. Обычно это связано с оптимизациями и расширением стандартного языка. Чтобы получить данные из БД, необходимо к ней подключиться через драйвер API по сети, написать запрос SQL, и если все хорошо – получить данные на выходе. В какой бы компании я ни работал – везде писал на SQL. Настоятельно рекомендую ознакомиться с этим языком программирования или хотя бы с его азами.

Хранилище данных содержит копию всех данных, необходимых для функционирования аналитической системы. Несколько лет назад появился модный термин Data Lakes (озеро данных) – это метод хранения данных системой или репозиторием в натуральном виде, то есть в формате, который предполагает одновременное хранение данных в различных схемах и форматах. Данные хранятся в том виде, в котором созданы: видеофайлы, изображения, документы, дампы таблиц из баз данных, CSV-файлы. Мое определение хранилища, которое я дал выше, очень сильно пересекается с озером данных. Также на кластере мы держали скачанные картинки, сырые и обработанные данные. Читателям я предлагаю меньше фокусироваться на терминах и не заморачиваться с ними, никто не даст вам четких инструкций, как хранить ваши данные. Это будет ваше решение, оно будет зависеть от ваших задач, которые предстоит решать именно вам.