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

Второй способ – сделать запрос к сетевому 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 у меня был один раз случай, когда мой сотрудник, обращаясь напрямую к источнику данных, повредил данные клиента – разработчики тогда очень разозлились.

Неизменяемость уже загруженных данных в хранилище гарантирует, что ваши аналитические отчеты не будут меняться. Я буду лукавить, если скажу, что так не бывает. Бывает, но обычно из-за технических ошибок или расширения перечня хранимых данных. Такие инциденты нужно минимизировать по двум причинам. Во-первых, перезагрузка данных бывает очень длительной и блокирующей аналитическую систему. Например, у нас в Retail Rocket такая операция между Hadoop и Clickhouse могла занимать дни и даже недели. Во-вторых, доверие пользователей к вашей системе будет подорвано из-за изменения данных, а значит, отчетов и решений, которые были сделаны на их основе. Легко ли вам будет доверять данным, которые изменяются задним числом?