Big Data: сколько стоят, как их хранить и кто этим занимается

В эпоху массфолловинга в социальных сетях, холодных продаж и определителей спам-звонков — к примеру, производства «Тинькофф» и «Яндекс» — о больших данных знает каждый. Разберемся детальнее в насущных вопросах Big Data.

Этимология больших данных

Трактовать термин Big Data можно по-разному — в зависимости от цели. Пока одни источники гласят, что речь идет о колоссальном объеме неструктурированных данных, другие подразумевают под ним инструменты и подходы к этим данным. Я же склонен считать, что это — не что иное как большой объем данных в произвольном виде.

Некоторые могут спросить: «а сколько вешать в граммах» или, как говорил один мой коллега, «а сколько должно быть той самой Data, чтобы она стала Big?». Я обычно считаю, что как только количество данных выходит за объем нескольких терабайт, то можно говорить о том, что данных действительно много, и надо задумываться над инструментами их хранения и грамотной обработки. Хотя, конечно, показатель должен быть интегральный, тот, что учитывает и типы данных, и количество, и скорость их поступления, и сложность операций обработки. Но для простоты можно взять лишь одну величину — объем.

Где «живут» большие данные? И сколько это стоит?

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

• -объемов и типов данных;
• - задач, решаемых с помощью данных;
• - требуемой скорости обработки данных;
• - разнообразия данных на входе;
• - возможности использования облаков;
• - уровня зрелости компании в части работы с данными.

При этом здесь мы не говорим про технологии и все, что с ними связано, т.к. технологии являются следствием вышеперечисленного.

Первый пункт — самый очевидный: хранить 10 Тб данных, при равных в технологическом плане и в абсолютных величинах, явно дешевле, чем 100Тб.

Задачи, на мой взгляд — основной драйвер стоимости, который должен компенсироваться теми ценностями, что бизнес получает от использования данных. Очевидно, что если потребитель данных — это аналитический отдел, который надо обеспечить качественными витринами, или модели ML, которые требуют сложных агрегатов, то сложность обработки информации в разы выше, чем в случае, когда нужно обеспечить хранение холодного архива. А сложность обработки — это процессорные мощности, память. Если же потребителю нужна еще и надежность в «пять девяток», то это еще и мультипликатор стоимости. Ну и не забываем — чем более сложный ETL необходимо сделать, тем дороже его написание и последующая поддержка.

Требуемая скорость обработки данных. Если нужно обеспечить потоком данных дашборд, который должен показывать обновление раз в минуту или антифрод-модель, которая должна ловить мошенников в режиме реального времени, то это будет намного дороже, чем те же витрины, которые можно обновлять раз в неделю по выходным, или тот же холодный архив, в который все сливается раз в месяц. Так что скорость тоже добавляет нам недешевых (особенно в последнее время) требований к процессорным мощностям, а еще больше — к памяти, плюс влияет на технологичность решения, что тоже добавляет иногда совсем не «копеечку».

Говоря о разнообразии данных на входе, мы влияем на технологическую сложность решения, а, значит, на дополнительные затраты на лицензии, расширенные требования к специалистам и поддержку решения в целом. Если нам надо работать с источниками разнородных данных — например, с реляционными таблицами, графовыми данными и документами, то становится понятно, что технологическая сложность решения будет намного выше, чем если бы нам пришлось делать все тот же бедный (а может и не очень) холодный архив с нескольких чисто реляционных источников.

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

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

Почему уровень зрелости компании по работе с данными так важен?

Многие знают или слышали, что такое уровни зрелости тех или иных процессов. Например, если мы говорим про ИТ, то можно открыть ITIL — там все хорошо описано. И примерно такие же, пусть пока и менее формализованные, уровни зрелости есть и в работе с данными. Приводить здесь эти уровни не буду, т. к. единого подхода к ним пока нет, а описывать то, что еще не стало хотя бы стандартом де-факто, — это тема отдельной дискуссии или статьи. Потому предлагаю приравнять уровень зрелости компании в части данных с широтой внедрения практик Data Governance на предприятии. Если вы не знаете, что это такое, и никаких практик по работе с данными у вас нет, будем считать, что вы на 0 или на 1 уровне. Но тогда и никакого влияния на стоимость хранения и обработки этот самый «уровень зрелости» не оказывает.

Но как только вы начинаете внедрять практики DG, это повышает ваш уровень зрелости, но также увеличивает накладные расходы на работу с данными: вначале на разработку и внедрение этих практик, а потом и на поддержку и обслуживание. При этом не так важно, с чего вы начинаете — с ролевой модели владельцев данных, с института дата-стюардов, с создания и поддержки бизнес-глоссария, с обеспечения качества данных или других активностей. И, как водится, зависимость ни разу не линейная, а вполне себе экспоненциальная — т. е. каждый последующий уровень обходится дороже предыдущего.

Наверное, может показаться, что практики DG — это зло и лишние накладные расходы. Но, конечно же, это не так: они повышают качество, доступность и управляемость данных. Как следствие, тот дата-продукт, который приносит ценность для бизнеса из данных, становится более качественным, а, значит, более ценным. Или повышается скорость создания нового дата-продукта и получение новой бизнес-ценности. Поэтому и в уровне зрелости важно найти тот баланс между затратами и ценностью, который устроит обе стороны.

Ведь очевидно — нет смысла разгонять уровень зрелости до 5-го уровня, если бизнес не понимает, как монетизировать эти прекрасные, быстрые, описанные до последней запятой данные. Как говорил мой коллега, «каждый атрибут в вашей витрине стоит четко определенную сумму денег — покажите мне, какой эффект вы от них получаете»: и это правильный вопрос, хотя найти на него ответ порой бывает крайне сложно.

Кто отвечает за работу с большими данными?

Исходя из вышесказанного, основное искусство в подборе решения — в поиске баланса между тремя аспектами: текущими задачами, которые обеспечивают бизнес-ценность данных, перспективными задачами и стоимостью хранения и обработки.

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

А задачи офиса данных, в свою очередь, это:

• - Понять бизнес-задачу или требований, которые предъявляются к данным;
• - Найти оптимальные ответы на поставленные в начале статьи вопросы, т. е. минимизация стоимости решения при требуемом уровне качества;
• - Обеспечить нужный, сбалансированный уровень зрелости работы с данными в компании.

Но это идеальная картина мира, когда есть грамотная аналитическая служба, когда бизнес понимает, что такое данные, и как с ними работать. А в текущей реальности зачастую CDO сам должен идти по бизнес-заказчикам и нести свет в массы, рассказывая, что хорошего еще можно сделать из данных сейчас, и что можно будет сделать, если поменять технологическую платформу, внедрить DG, перейти к обработке данных в реальном времени и т. д. Ну а поскольку для CDO это задача во многом непрофильная, а бизнес не готов, то результат не всегда получается таким, как мы ожидаем.

Мы в ICL хорошо понимаем, как создается бизнес-ценность из данных, и как работать с данными на всех уровнях — от уровня организации хранения, подбора и реализации хранилища, до уровня аналитики и машинного обучения, где рождается основная ценность из данных, так и на уровне бизнеса, который эту ценность должен понять, принять и монетизировать. Подход нашей команды к работе с Big Data — это подход через консалтинг: от понимания бизнес-задачи и потенциальных бизнес-ценностей, через пилоты и MVP для проверки гипотез и потом уже подбор решений (и не только по хранению — а решений полного цикла, от хранения до аналитики и ML), их внедрение и дальнейшее масштабирование. Именно такой подход позволяет нашим заказчикам получать не просто классное технологическое решение, а классное технологическое решение, которое обеспечивает потребности бизнеса и позволяет повысить эффективность предприятия.