Согласно недавнему исследованию Accenture Technology Vision 2018, на сегодня выделяется пять основных технологических трендов, которые радикально изменят бизнес уже в течение ближайших трех лет. Это внедрение искусственного интеллекта, виртуальной и дополненной реальности, развитие партнерств на базе единых технологических платформ, создание распределенных интеллектуальных систем и, конечно, забота о достоверности данных. В сущности, последний тренд является ключевым, ибо данные — жизненная основа любого интеллектуального предприятия.
Инвестиции в грамотное построение процесса управления данными (Data Governance) позволят компаниям извлекать куда большую выгоду из уже имеющихся информационных ресурсов и обеспечат успех других инициатив по цифровому преобразованию.
Неслучайно многие передовые компании выделяют в составе высшего руководства новую штатную единицу — директора по данным (Chief Data Officer, CDO). Его основная задача — реализация стратегии развития информационных ресурсов, включая контроль других подразделений на предмет соблюдения соответствующих регламентов. В некоторых западных компаниях уже сейчас действует практика, когда до 30% зарплаты сотрудника зависит от того, насколько он выполняет KPI по вводу и учету данных. И это не блажь — для бизнеса качество данных год от года становится все более критичным параметром, а предотвращение внесения некорректных данных значительно снижает трудоемкость их очистки при загрузке в Data Lake и корпоративное хранилище. На основе этих данных проверяются гипотезы и принимаются управленческие решения. В конечном счете даже самые продвинутые аналитические системы хороши ровно настолько, насколько полны и достоверны обрабатываемые ими данные.
А что же в российских реалиях? Весьма распространен сценарий, когда в компании есть хранилище данных, но его нарезали на множество локальных областей (нередко пересекающихся по смыслу), которые относятся к разным подразделениям. Как следствие — противоречивые данные в отчетах, большие трудности в подготовке консолидированной отчетности, не говоря уже о невозможности проведения кросс-анализа и тем более использовании технологий Machine Learning. Другой вариант: есть единое хранилище, но оно безнадежно устарело — логика его работы заточена под старые бизнес-процессы и технологии, а за счет увеличения объема информации оно иногда не способно обеспечить даже прежнюю скорость предоставления данных для отчетов.
Все эти проблемы влекут множество материальных издержек для бизнеса (от неверно принятых решений, упущенного времени или даже некорректно сформированной регуляторной отчетности) и становятся стопором развития компании. То есть для специалистов по построению правильных и современных архитектур хранилищ и Data Lake фронт работ огромный. Начиная с реорганизации существующего хранилища или построения нового до внедрения полноценной стратегии управления данными всего предприятия.
«У нас несколько аналитических систем и данные в них не сходятся»
Такую жалобу мы нередко слышим от наших заказчиков из различных отраслей. Дело тут, разумеется, не в использовании нескольких BI-инструментов, а в отсутствии единой достоверной корпоративной бизнес-модели данных. Подразделения накапливают и обрабатывают данные для своей операционной деятельности локально, подчас используя различные «исторически сложившиеся» бизнес-термины и алгоритмы расчета для одних и тех же параметров. Либо наоборот — одним термином называют разные сущности. В результате возникает путаница и фактические ошибки при попытке консолидировать такую отчетность для представления руководству компании.
Подобную ситуацию мы наблюдали у одного из наших заказчиков — фармацевтической компании. Финансовый департамент при планировании использовал один инструмент, а бухгалтерия для составления план-факт анализа — другой. В результате расхождения в их показателях для годового отчета составляли в среднем 1–2%, что в денежном эквиваленте было непростительно много. Тут можно подивиться искусству представления данных и чудесам арифметики, а можно просто устранить лазейки для разночтений. И главная из них — отсутствие единой бизнес-модели данных компании, что приводит к разрозненному хранению и обработке информации.
Проблема решается формированием единой стратегии управления данными, требующей построения единого хранилища и создания в его рамках конвейера по преобразованию данных, который будет обслуживать запросы всех аналитических систем. За счет этого будет исключено неконтролируемое использование информации при формировании витрин данных для BI-систем. Такой подход снимет противоречия и значительно упростит расчет данных при формировании отчетности.
Единое хранилище имеется… разночтения в данных — тоже
Создание единого хранилища данных отдельно от проработанной методологии по его развитию и поддержанию единой модели не гарантирует решения описанных выше проблем. То есть в компаниях нередки ситуации, когда оно как бы есть, но выгод от него никаких: данные от подразделений все равно разнятся, а провести кросс-анализ или тем более внедрить Machine Learning для нужд бизнеса становится запредельной мечтой.
Причина тут простая: единым хранилище является только формально, на деле же к нему прилагается набор разрозненных витрин данных, которые далеко не всегда загружаются из центрального хранилища. Просто потому что в организации не внедрена унифицированная модель хранения, а подразделения сосредоточены на локальных задачах, которые решают в своих системах. Вот и получается, что ценных данных много, но использовать весь их массив для получения целой картины по компании — практически невозможно. А кроме того, периодически возникает путаница из-за того, что разные департаменты используют одно и то же обозначение атрибута для неравнозначных категорий данных. Так под загадочным наименованием «сумма ограничения» могут скрываться совершенно не связанные друг с другом сеты данных, если речь идет, к примеру, об отделах маркетинга и логистики. А для понятия «выручка» подразделения пользуются подчас разными формулами и допусками.
Похожую картину мы наблюдали у одного из крупных ритейлеров, который, помимо самого хранилища, располагал десятком отчетных витрин, построенных над системами-источниками. Причем заведение данных в самом хранилище или только в отдельной витрине зависело не только от их бизнес-назначения, но и от «исторических» причин (точнее «привычек»), да и просто в силу понимания конкретных ответственных на местах.
Хранилище есть, но как же все медленно…
Такие жалобы нередки в финансовой отрасли. Созданием хранилищ банки озаботились довольно давно, однако по мере их эксплуатации появились новые бизнес-требования к уровню детализации обрабатываемых в отчетах данных, которым уже не соответствуют прежние модели хранения и вычислительные ресурсы. Ситуация осложняется лавинообразным ростом данных. В результате банки сегодня столкнулись с серьезной проблемой: загрузка данных и формирование аналитики в разы замедлились.
Еще 5 лет назад стандартом была подготовка отчетов в режиме T–1 (то есть с отставанием на 1 рабочий день). Сегодня актуальность данных в отчетах нередко составляет 3 и более дней. Такое положение дел, разумеется, не устраивает бизнес, вынужденный принимать управленческие решения на основе устаревшей информации. В результате остро стоит вопрос о реорганизации хранилищ данных. И наиболее перспективным вариантом здесь является построение гибридного Data Lake. Хранение и обработку «сырых данных» можно реализовать на базе свободно распространяемых программных решений Hadoop и при этом использовать существующую бизнес-модель данных без глобального перестроения всех имеющихся витрин данных.
В отличие от классического хранилища у Hadoop сбалансированная производительность для любого объема хранимой информации (при проектировании определяется объем и производительность одного узла, а затем по мере роста объема информации в кластер просто добавляются очередные узлы). Еще одно ключевое отличие заключается в том, что в Data Lake можно хранить и обрабатывать неструктурированную информацию, например, потоковое видео с камер офиса или торгового зала, что открывает возможности для реализации инновационных бизнес-идей.
Одному нашему заказчику из ритейла нужно было провести анализ спроса на новые товары/коллекции. Решили проанализировать с помощью модели машинного обучения данные с камер видеонаблюдения: как часто и к каким витринам клиенты подходят. Поток и объем данных был такой высокий, что классическое хранилище не смогло решить эту задачу, а Data Lake прекрасно с ней справился.
Аналогичную задачу по анализу видеопотока мы решали на производстве. Требовалось проанализировать перемещения сотрудников по помещениям, соблюдение ими техники безопасности, вовлеченность в процесс. И снова не обошлось без Data Lake.
Пример из телеком-отрасли. Заказчик хотел обрабатывать интернет-трафик и оперативно реагировать на просмотр абонентами определенного контента (например, сайтов партнеров — для определения эффективности сотрудничества с ними). Единственным решением тут тоже стало построение Data Lake и реализация потоковой обработки данных.
Совсем свежий пример из практики: крупный ритейлер попросил нас развернуть систему персональных рекомендаций для клиентов в реальном времени. Стандарт обслуживания на кассе — полминуты, а хранилище было способно выдать ответ только через несколько минут. Ни один клиент столько ждать не будет, поэтому для бизнес-процесса в итоге использовали решение для Big Data от Hortonworks, которое при небольшой стоимости владения обеспечило требуемую производительность.
И опять история с производства. На заводе нашего клиента объем данных, собираемых со станков в хранилище, составлял около 250 Гб в день. В построенном нами Data Lake тот же поток данных за счет сжатия и изменения структуры хранения уменьшился до 12 Гб в день. Сокращение объема хранения в 20 раз позволяет радикально снизить расходы на ИТ. Что уж говорить о ситуации, когда нужно хранить показания не с 200 станков, а десятков тысяч датчиков Интернета вещей (IoT)?
Помимо перечисленных выгод, Data Lake дает возможность полноценно использовать машинное обучение для выявления скрытых закономерностей в данных, проверки аналитических гипотез, а в конечном итоге — увеличения прибыли и сокращения издержек. Тут и персональные предложения клиентам онлайн и офлайн, и снижение затрат на логистику и маркетинг, и удержание клиента, и оптимизация расхода ресурсов, и решение задач по информационной безопасности. При этом окупаемость проекта по созданию Data Lake происходит в перспективе 2–3 лет. Но все это возможно только при наличии достоверных данных, собранных в одном месте, благодаря качественному процессу data management.
Словом, такие проекты способны приносить огромную выгоду бизнесу, однако требуют тщательной предварительной оценки со стороны экспертов. Советую не пренебрегать этой возможностью, тем более что расчеты и консультацию по проектам создания Data Lake наша команда предоставляет совершенно бесплатно.
