Среди текстовых форматов файлов наиболее распространены три:
• 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-формате, например, интернет магазины передают информацию о товарах: структуру их каталога, цены, названия, атрибуты товаров.
Иван
Иванов
Московское ш., 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. Настоятельно рекомендую ознакомиться с этим языком программирования или хотя бы с его азами.
Глава 6
Хранилища данных
Зачем нужны хранилища данных
Хранилище данных содержит копию всех данных, необходимых для функционирования аналитической системы. Несколько лет назад появился модный термин Data Lakes (озеро данных) – это метод хранения данных системой или репозиторием в натуральном виде, то есть в формате, который предполагает одновременное хранение данных в различных схемах и форматах. Данные хранятся в том виде, в котором созданы: видеофайлы, изображения, документы, дампы таблиц из баз данных, CSV-файлы. Мое определение хранилища, которое я дал выше, очень сильно пересекается с озером данных. Также на кластере мы держали скачанные картинки, сырые и обработанные данные. Читателям я предлагаю меньше фокусироваться на терминах и не заморачиваться с ними, никто не даст вам четких инструкций, как хранить ваши данные. Это будет ваше решение, оно будет зависеть от ваших задач, которые предстоит решать именно вам.
