Когда мы думаем о данных, мы, естественно, представляем их в виде папок с файлами. Именно так представляют себе данные типичные руководители высшего звена, причем большинство из них ограничивается электронными таблицами. Это нормально, учитывая, что топ-менеджеры в основном выходцы из финансовой среды. Они могут говорить о базах данных, на самом деле имея в виду большие листы Excel. Задача технического директора – помочь топ-менеджерам понять, что их самый ценный актив представляет собой нечто большее, чем электронные таблицы. Другая задача CTO – продумать и спланировать долгосрочное размещение данных, чтобы бизнес мог использовать их эффективнее.

Как мы уже сказали, хранение данных никогда не стоило так дешево, как сейчас, и больше нет оправданий для того, чтобы не сохранять их. Но что это на самом деле означает? И действительно ли нужно хранить всё? Чтобы ответить на эти вопросы, для начала рассмотрим основные типы хранилищ, в которые можно загружать данные:

• Файлы/папки. На сегодняшний день файл – автономный именованный набор данных, находящийся на физическом носителе, – по-прежнему является наиболее универсальным способом хранения данных. Существует множество популярных форматов файлов, таких как JSON, XML, CSV и TXT, и этот способ хранения данных универсален, потому что почти каждый инструмент способен открывать файлы и работать с ними. Файлы легко копировать, шифровать и перемещать, и ими легко делиться. Не существует ограничений на виды данных, которые можно хранить в файле.

• Реляционные хранилища (базы данных SQL). Данные, которые имеют общие атрибуты (столбцы) и связаны друг с другом (строки), прекрасно вписываются в структуру, которую мы называем таблицами. Таблицы могут быть связаны с другими таблицами, а наборы таблиц известны как базы данных. К таблицам можно выполнять запросы, используя специальный псевдоязык (SQL), который описывает команды для получения данных, их изменения или записи в таблицу новых данных. Это очень популярный механизм для хранения больших объемов одинаково структурированной информации.

• Хранилища NoSQL. В хранилищах NoSQL, или документных, отсутствуют структурные ограничения, свойственные реляционным хранилищам. В них сохраняется только то, что вы передадите, и не остается пустот на месте отсутствующих данных, как в реляционных СУБД. Группы документов образуют коллекции, в которых каждый документ может значительно отличаться от другого.

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

• Корпоративное хранилище данных (Data warehouse). Хранилище – это специально разработанная база данных, которая в основном используется для анализа и бизнес-аналитики (business intelligence, BI). В нем хранятся большие наборы данных, организованных таким образом, чтобы упростить составление отчетов и годовой анализ.

До появления облака создание и обслуживание хранилищ любого из этих типов было непомерно дорого, и на каждом этапе подготовки принимались решения о сокращении количества данных до минимально необходимого на текущий день. Если бизнес развивался и решал, что ему нужны более подробные данные, то сохранять их можно было только начиная с этого момента, а исторические данные были утеряны.

Файлы и базы данных распространены повсеместно. В каждой организации есть своя база данных – SQL Server, Postgres, MySQL или Oracle. Тем не менее зачастую БД плохо организованы, например, одна БД может использоваться одновременно для нескольких областей (скажем, для клиентского веб-сайта и для предоставления отчетов о состоянии бизнеса). Вместо этого у каждой области бизнеса должна быть своя БД, и данные должны реплицироваться между ними. Таким образом, когда финансовый директор задумает сформировать масштабный отчет о квартальных продажах, он не положит весь сайт.

Базы данных NoSQL (такие как MongoDB, CouchDB, DynamoDB и Elasticsearch) становятся все более популярными, особенно на ранних этапах разработки проектов, когда еще нет полного представления об итоговой структуре. Их производительность с годами увеличилась настолько, что при правильно выбранной организации данных они способны работать так же эффективно, как и их реляционные аналоги. Будьте осторожны и не увлекайтесь: некоторые команды строят всю систему на архитектуре NoSQL. В этом случае возрастает риск нарушения единообразия данных (то есть в разных документах одни и те же данные будут храниться в разных форматах, например, число 2 может быть представлено в строковом и целочисленном форматах, потому что где-то при обработке данных они не были приведены к одному виду). NoSQL не обеспечит вам ни целостность, ни единую структуру данных.

Озеро данных (Apache Hadoop, Amazon S3) – это одно большое пространство для хранения файлов. Однако это не просто крупное файловое хранилище. В озере данных есть инструменты и механизмы для просмотра файлов, чтобы вы могли выбрать то, что вам нужно. Например, оно отлично подходит для размещения журналов продакшена. Вам не нужно беспокоиться о формате файлов, он может меняться со временем. При необходимости озеро данных предоставит удобный механизм для перебора файлов журналов, чтобы найти заданное ключевое слово или строку (этот подход называется map/reduce).

Наконец, корпоративное хранилище данных (Amazon Redshift, SQL Server) – это место, куда поступают данные, необходимые для отчетности. Оно специально разработано для упорядочивания данных таким образом, чтобы их можно было очень быстро проанализировать для получения отчетов, необходимых бизнесу. Данные в хранилище обычно агрегируются, обезличиваются и выстраиваются таким образом, чтобы отвечать на вопросы бизнеса. Такое хранилище будет полезно, только если накоплено значительное количество данных. Традиционная реляционная СУБД тоже может обрабатывать запросы к данным, но придет время, когда ее окажется недостаточно.

Заметки с полей

Ограниченные знания опасны

Я встречал множество глупейших ошибок в конфигурациях баз данных, в том числе сделанных теми, кто уверен, что нельзя использовать соединение таблиц. Однако особенно примечателен один случай, когда мою команду позвали помочь с очень медленно работавшей базой данных, из-за которой зависал весь сайт. Покопавшись, мы увидели множество операций дискового ввода/вывода, связанных с БД и указывающих на большое количество операций записи на диск, что было странно, поскольку данных сохранялось не так много. Оказывается, один из технарей вычитал, что для ускорения работы нужно добавить к таблице индексы. Исключительно из лучших побуждений он создал индексы для каждого столбца в каждой таблице. База данных утонула в собственных метаданных, поскольку в ней стало больше данных о данных, чем самих данных. Действительно, информация может нанести вред, если окажется не в тех руках!

В облаке все эти хранилища данных можно организовать без дополнительных затрат на запуск и управление серверами (и лицензиями). Подавляющее большинство команд, с которыми я работаю, только выиграли от переноса хранилищ данных в облако, где они масштабируются по требованию, поэтому нехватка места осталась в прошлом, а данные защищены гораздо лучше благодаря множеству инструментов, доступных по умолчанию.

Организация должна иметь хотя бы какую-то разновидность озера данных. Представьте, что это чердак – место, где хранится все, что вы не можете заставить себя выбросить, потому что однажды оно может вам понадобиться. Озеро данных – это место хранения данных, у которых нет постоянного дома, поэтому, если они однажды кому-то понадобятся, вы, по крайней мере, будете знать, что они у вас есть. Хотя поиск на чердаке может занять некоторое время, вы их там найдете.