Роман Зыков - Роман с Data Science. Как монетизировать большие данные [litres]

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-формате, например, интернет магазины передают информацию о товарах: структуру их каталога, цены, названия, атрибуты товаров.

Иван

Иванов

Московское ш., 101, кв.101

Ленинград

101101

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-файлы. Мое определение хранилища, которое я дал выше, очень сильно пересекается с озером данных. Также на кластере мы держали скачанные картинки, сырые и обработанные данные. Читателям я предлагаю меньше фокусироваться на терминах и не заморачиваться с ними, никто не даст вам четких инструкций, как хранить ваши данные. Это будет ваше решение, оно будет зависеть от ваших задач, которые предстоит решать именно вам.

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

С моей точки зрения, хранилища данных:

1) являются цифровым архивом компании;

2) являются копией данных в источнике;

3) не изменяемы;

4) хранятся в виде, максимально приближенном к данным в источнике;

5) позволяют объединят данные из разных источников.

Относитесь к хранилищу как к архиву компании [34], ведь там хранятся данные с момента ее создания. Часть данных вы уже нигде не найдете, так как источники периодически чистятся. В Retail Rocket, например, мы периодически архивируем все данные: товарные базы интернет-магазинов (они изменяются со временем), их структуры каталога, сами рекомендации. Ни в каких источниках их уже нет, но они есть в нашем хранилище и помогают решать важные задачи: искать причины проблем и моделировать новые алгоритмы рекомендаций.

Напрямую с источником данных не стоит работать по двум основным причинам. Во-первых, запросы к данным на чтение оказывают очень большую нагрузку на диски и увеличивают время ответа рабочих машин, и клиенты получают ответы ваших систем с задержкой. Во-вторых, может быть нарушена конфиденциальность данных, хранящихся в источниках. Не все данные нужно забирать оттуда в исходном виде, чувствительную информацию клиентов лучше не трогать или шифровать при загрузке в хранилище. Само хранилище проводит незримую границу между вашей рабочей системой, которая должна работать надежно, и данными, которые будут использованы для анализа. В Ozon.ru у меня был один раз случай, когда мой сотрудник, обращаясь напрямую к источнику данных, повредил данные клиента – разработчики тогда очень разозлились.