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), их внедрение и дальнейшее масштабирование. Именно такой подход позволяет нашим заказчикам получать не просто классное технологическое решение, а классное технологическое решение, которое обеспечивает потребности бизнеса и позволяет повысить эффективность предприятия.
Опубликовано 26.04.2022
