00:00:08 Озера данных и их важность.
00:00:39 Определение озер данных и их назначение в бизнесе.
00:02:13 Эволюция озер данных от хранилищ данных.
00:04:15 Сдвиг в мышлении и философии, связанной с озерами данных.
00:07:43 Обеспечение точности данных в озерах данных.
00:10:06 Как технологии улучшили хранилища данных за последние 20 лет.
00:12:14 Преимущества систем по требованию в озерах данных.
00:13:31 Ограничения бизнес-аналитики и её устаревший подход.
00:15:22 Сравнение бизнес-аналитики с озёрами данных и их способности информировать принятие решений.
00:16:49 Сложность внедрения: доступ к источникам данных и влияние на транснациональные компании.
00:18:32 Применение озёр данных: преимущества для технологически ориентированных компаний и их использование в кросс-функциональной оптимизации.
00:20:08 Будущее озёр данных: повышение доступности и внедрения, следующие шаги с API.
00:22:45 Заключительные замечания и выводы.
Резюме
В этом интервью Киаран Чендлер и Жоаннес Верморель, основатель Lokad, обсуждают озера данных и их роль в оптимизации цепочки поставок. Озера данных — это централизованные хранилища необработанных данных, которые позволяют приложениям на основе машинного обучения принимать обоснованные решения. Верморель подчеркивает ограничения традиционных инструментов бизнес-аналитики, отмечая, что озера данных предлагают более эффективный и автоматизированный анализ данных. Он считает, что технологически ориентированные компании уже внедрили озера данных и перешли к использованию программных интерфейсов (API) для своих подсистем, что позволяет реализовать сквозную автоматизацию. Верморель прогнозирует, что крупные компании в ближайшие пять лет все активнее будут использовать озера данных и API для принятия более обоснованных решений.
Расширенное резюме
В этом интервью Киаран Чендлер обсуждает озера данных с Жоаннесом Верморелем, основателем Lokad, софтверной компании, специализирующейся на оптимизации цепочки поставок. Они начинают с определения озер данных и их происхождения. Озера данных представляют собой тип базы данных, предназначенной для консолидации всех ключевых транзакционных данных компании, таких как продажи, закупки и уровни запасов. Эти базы данных предназначены для использования приложениями, а не людьми, что позволяет доменно-специфичным приложениям, основанным на данных, принимать обоснованные решения в области маркетинга, цепочки поставок, управления персоналом и не только.
История озер данных уходит корнями в эпоху хранилищ данных и витрин данных, тенденции, появившиеся более 20 лет назад. Верморель объясняет, что основное отличие озер данных от хранилищ данных заключается в технологии и принципах, лежащих в их основе. Озера данных более эффективны для хранения и обслуживания больших объемов данных, в то время как облачные вычисления сделали их более доступными и экономичными.
Двадцать лет назад компаниям приходилось покупать дорогостоящие устройства, такие как оборудование от Oracle, для размещения своих хранилищ данных. Сейчас же, благодаря облачным платформам, компании могут использовать озера данных по модели pay-as-you-go, которые масштабируются и предлагаются по конкурентоспособным ценам. Такая гибкость позволяет бизнесу при необходимости легко корректировать подход к хранению данных.
Философия, лежащая в основе озер данных, также изменилась по сравнению с хранилищами данных. Ранее подход создавал огромное давление на ИТ-отделы, заставляя их правильно организовывать и управлять данными. Хранилища данных проектировались с витринами данных для различных подразделений, таких как маркетинг, цепочка поставок и финансы. Это создавало проблемы при управлении и доступе к данным между разными отделами.
Озера данных стремятся консолидировать данные более централизованным и доступным способом, что облегчает их обработку приложениями и принятие обоснованных решений. Такой сдвиг в подходе позволил добиться большей эффективности и гибкости в управлении и использовании данных.
Двадцать лет назад хранилища данных были популярным методом управления и организации информации. Этот подход требовал значительных технических усилий для объединения различных таблиц данных и предполагал наличие единой модели данных компании. Однако этот метод часто приводил к тому, что ИТ-подразделения оказывались перегружены огромным объемом работы, что приводило к множеству неудачных проектов.
Сегодня озера данных появились как более оптимизированный и эффективный подход к управлению данными. Озера данных служат хранилищем необработанных данных, извлеченных из различных систем, таких как CRM, ERP и веб-платформ. Вместо попыток организовать или объединить данные, они просто сбрасываются в озеро данных, которое способно справляться с большими объемами информации без проблем.
Одна из проблем при использовании озер данных заключается в обеспечении точности и актуальности данных. ИТ-отделы отвечают за то, чтобы озеро данных точно отражало исходные системы, однако им не требуется разбираться в бизнес-аспектах данных. Ответственность за понимание данных в, например, CRM, ложится на подразделения, которые их используют, такие как продажи или маркетинг. Такой подход позволяет более специфично интерпретировать данные для решения конкретных задач, поскольку различные подразделения могут иметь разные потребности и взгляды на данные.
Технологический ландшафт значительно изменился со времён хранилищ данных, что сделало озера данных более жизнеспособным вариантом. Во-первых, качество инструментов для передачи данных через интернет улучшилось, что облегчает консолидацию данных из распределённых систем, таких как цепочки поставок. Кроме того, инфраструктура интернета также улучшилась, позволяя даже небольшим компаниям без труда перемещать большие объемы данных.
Более того, облачные вычислительные платформы сделали озера данных более доступными и экономичными. Эти платформы позволяют быстро проводить итерации и использовать ресурсы по требованию, что позволяет компаниям экспериментировать с озёрами данных без значительного финансового риска.
Хотя инструменты бизнес-аналитики были полезными для получения инсайтов из данных, они изначально предназначены для восприятия человеком. Это означает, что компании вынуждены платить сотрудникам за анализ данных, вместо того чтобы автоматизировать этот процесс. Озера данных, напротив, позволяют проводить более эффективный и автоматизированный анализ, что делает их привлекательным вариантом для транснациональных компаний, стремящихся улучшить управление данными.
Верморель объясняет ограничения традиционных инструментов бизнес-аналитики (BI), преимущества озер данных и будущее управления данными в оптимизации цепочки поставок.
Верморель описывает бизнес-аналитику как устаревшую технологию, предоставляющую лишь базовый анализ данных в режиме, близком к реальному времени. Эта технология была революционной 30 лет назад, позволяя компаниям получать доступ и агрегировать свои данные, но она не предоставляет действенных инсайтов или решений. В отличие от этого, озера данных являются частью более широкой картины, служа хранилищем необработанных данных из различных источников. Приложения на основе машинного обучения затем эффективно обрабатывают эти данные для генерации действенных решений, которые влияют на компанию и создают ощутимую ценность.
Внедрение озера данных зависит от сложности доступа к источникам данных компании. Для крупных транснациональных компаний этот процесс может быть сложным, поскольку в каждой стране может действовать своя система. Однако альтернатив нет, если компания хочет получать инсайты и принимать решения на основе данных. Верморель считает, что небольшие, технологически ориентированные компании уже внедрили озера данных и даже перешли дальше, реализовав программные интерфейсы (API) для своих подсистем. Это обеспечивает кросс-функциональную оптимизацию и умное принятие решений.
Верморель прогнозирует, что крупные компании будут все активнее внедрять озера данных в ближайшие пять лет, поскольку они становятся более доступными и экономичными. Компании, не внедряющие озера данных, рискуют уступить конкурентам, которые уже это сделали. Однако озера данных — это не конечный этап управления данными. Верморель предполагает, что API — это будущее, позволяющее компаниям не только читать и анализировать данные, но и оперативно действовать на их основе. API могут обеспечить сквозную автоматизацию, автоматически генерируя решения и внедряя их в систему.
Жоаннес Верморель подчеркивает важность перехода от традиционных инструментов бизнес-аналитики к внедрению озер данных для более эффективного принятия решений на основе данных в оптимизации цепочки поставок. Он видит будущее, в котором крупные компании реализуют озера данных и API для автоматизации своих процессов и принятия более обоснованных решений.
Полная транскрипция
Kieran Chandler: Сегодня в Lokad TV мы подробнее обсудим концепцию озер данных и поймем, почему этим компаниям стоит уделить им больше внимания. Итак, Жоаннес, как всегда, возможно, нам стоит начать с более подробного определения того, что такое озера данных и откуда они произошли. Joannes Vermorel: Озеро данных, как правило, представляет собой своего рода базу данных с определёнными особенностями, предназначенную для консолидации практически всех ключевых данных вашей компании, особенно всех транзакционных данных, таких как то, что вы продали, что купили, уровни запасов и так далее. Цель и конечное назначение озера данных — быть инструментом для приложений, а не для людей. Идея заключается в том, чтобы создать озеро данных для поддержки доменно-специфичных приложений, которые опираются на данные и могут использовать огромные объёмы данных из озера для генерации обоснованных решений в области маркетинга, цепочек поставок, кадровых ресурсов и прочего. Что касается второй части вашего вопроса, озера данных имеют долгую историю, уходящую корнями в концепцию хранилищ данных и витрин данных. Kieran Chandler: Хранилища данных были популярны, вероятно, более 20 лет назад. Итак, что изменилось с тех пор, и каковы ключевые отличия? Joannes Vermorel: Это интересно. Сегодня в моде термины «озеро данных» и «data scientist», в то время как двадцать лет назад доминировали понятия «хранилище данных» и «data mining» — по сути, это та же эволюция идей, лишь повторно осмысленная спустя двадцать лет. Изменилось достаточно много. Во-первых, технологии озер данных изменились, и теперь они гораздо эффективнее хранят и обслуживают большие объемы данных. Затем на сцену вышли облачные вычисления, что означает, что сегодня можно иметь озера данных с моделью оплаты по мере использования с ценами за терабайт. Это существенно отличается от двадцатилетней давности, когда приходилось покупать очень дорогое оборудование, например от Oracle, для хранения всех ваших данных. Сегодня, благодаря облачным платформам, можно пользоваться терабайтами по модели оплаты по мере использования и при этом предлагать весьма агрессивные цены. Kieran Chandler: Это, скорее, техническая сторона вопроса. А как насчет философии? Что изменилось в подходе и как мы используем озера данных по сравнению с хранилищами данных? Joannes Vermorel: Действительно, произошла значительная эволюция. Проблема хранилищ данных, как они представлялись 20 лет назад, заключалась в том, что они оказывали огромное давление на ИТ по части правильной организации данных. У вас даже было хранилище данных, которое должно было организовывать витрины данных, по одной для каждого подразделения, такого как маркетинг, цепочка поставок, финансы и так далее. Витрины данных были как подмножества или элементы внутри вашего хранилища. Проблема этого подхода, который в духе отчасти похож на современные озера данных, заключалась в том, что требовалась значительная организация и управление со стороны ИТ. Kieran Chandler: В сфере бизнес-аналитики ожидалось, что всё будет предварительно подготовлено, организовано — например, связывание клиентов с продажами и возвратами. То есть, все элементы объединятся вместе. На самом деле, это требует огромных усилий, технически это связано с объединением таблиц, их корректным соединением. Таким образом, двадцать лет назад философия заключалась в том, чтобы сделать многое, и это было довольно похоже на то, что делалось в BI и естественно для реляционных систем. Проблема этого подхода заключалась в том, что объем требуемой работы был просто колоссальным, вследствие чего ИТ-подразделения часто оказывались полностью перегружены требованиями, поступавшими в результате этих проектов по созданию хранилищ данных. В итоге, часто всё проваливалось, потому что ИТ не справлялось. А как насчет сегодня? Ведь, похоже, ситуация будет немного запутанной с появлением озер данных. Joannes Vermorel: Философски, озера данных гораздо проще, поскольку они представляют собой просто приемник для чистого извлечения, то есть откровенного сброса всех данных из других систем. Вы не пытаетесь делать какую-либо изысканную перекомбинацию данных, поступающих из CRM, ERP или вашего веб-сайта. Вы просто извлекаете данные из этих источников и сбрасываете их в озеро данных. И озеро данных ведет себя отлично благодаря технологиям, что позволяет сбрасывать огромные объемы данных, и оно справляется с нагрузкой без нареканий. Если вы используете облако, за это взимается плата. Kieran Chandler: Как вы узнаете, что данные, которые вы используете, являются качественными? То есть, как вы отслеживаете, какие данные актуальны? Если вы просто сбрасываете их в озеро, как вы это контролируете?
Joannes Vermorel: Ответственность IT при использовании data lake заключается в том, чтобы обеспечить, что data lake точно отражает содержимое исходных систем. Но это не требует понимания бизнес-процессов. У вас есть CRM с 200 таблицами, реляционными таблицами, и вы просто зеркально копируете их в data lake — и все. Вам не нужно разбираться в том, что происходит в CRM.
Kieran Chandler: Так кто же должен понимать, что происходит в CRM?
Joannes Vermorel: Оказывается, что именно подразделения сами хотят использовать данные, и проблема в том, что трактовка данных крайне специфична для конкретной задачи. Например, способ анализа данных о продажах различается, если вы решаете маркетинговую задачу или задачу в цепочке поставок. Вот почему, и это была одна из основных причин провала многих инициатив по созданию хранилищ данных двадцать лет назад. Видение заключалось в том, чтобы создать единую модель компании, но оказалось, что это вызывало большое разочарование в каждом подразделении, поскольку маркетинг говорил: “О, это не совсем соответствует моему представлению о моей области”, а цепочка поставок и финансы выражали то же самое. Таким образом, идея в том, что теперь это скорее инициатива самих подразделений, таких как цепочка поставок, маркетинг, финансы, HR.
Kieran Chandler: Это означает, что сегодня они не потерпят неудачу. То есть, снова: многое меняется. Особая сложность, особенно в цепочке поставок, заключается в том, что по замыслу мы имеем дело с распределёнными системами. Что я имею в виду под распределёнными? Я имею в виду, что не всё находится в одном месте, ведь, по определению, если у вас есть несколько складов, они не расположены вместе. Ваши поставщики находятся не там же, что и склады, и клиенты тоже. Таким образом, по определению, мы имеем дело с системами, которые распределены, и вы хотите консолидировать все эти данные в одном месте — в вашем data lake, что технически должно происходить через сеть.
Joannes Vermorel: Конечно, двадцать лет назад интернет уже был изобретён. Он существовал, но качество инструментов для передачи данных по интернету было совершенно иным по сравнению с тем, что у нас есть сегодня. И сама сеть также имела совершенно иное качество. Сегодня, если вы хотите передавать, скажем, для не слишком крупной компании, компании с 1 000 сотрудниками — вы значительны, но не мегакорпорация, — двадцать лет назад, если вы хотели передавать один гигабайт данных в день по интернету, это было сложно.
I mean, you needed to have access to fiber, for example, in Paris. Двадцать лет назад в Париже был только один район, где можно было получить доступ к оптоволокну, а именно район у фондовой биржи. Это была примерно одна квадратная километрная зона, где можно было легко получить доступ к оптоволокну. В любом другом месте приходилось прокладывать собственное оптоволокно, если вы этого хотели. Так что мегакорпорации могли это сделать, а даже значительный бизнес с 1 000 сотрудниками — нет. Это изменилось. Теперь всё очень просто. Инструменты стали лучше, и вы можете буквально передавать гигабайты без лишних заморочек.
And the fact that you have on-demand systems, эти data lake не только очень дешёвые благодаря экономии от масштаба облачных платформ, но и то, что они доступны по требованию, означает, что вы можете пробовать и ошибаться. Если вы настроите data lake, и это будет полный провал, вы можете просто нажать «удалить» и попробовать снова, и вы платите только за то, что используете. Таким образом, вы можете быстро итеративно развиваться. Это не похоже на двадцать лет назад, когда вам приходилось вкладываться в покупку очень дорогостоящего устройства, и если вы ошибались, это было большой проблемой.
Kieran Chandler: И я уверен, что у финансовых подразделений, вероятно, до сих пор самый быстрый интернет. Что бы вы сказали большой транснациональной компании, которая уже отлично управляет своими данными, уже использует инструменты бизнес-аналитики? То есть, почему им должен быть интересен data lake?
Joannes Vermorel: Проблема бизнес-аналитики в том, что, по сути, она предназначена для людей. Это хорошо, но означает, что каждая минута, когда люди смотрят на эти цифры, — это минута, за которую вы платите сотруднику, чтобы он смотрел на числа, вместо того чтобы заниматься чем-то другим. Вы очень легко можете создать миллионы чисел, обработка которых потребует тысячи часов труда, что крайне дорого.
So, the problem is that business intelligence, на мой взгляд, — это технология, которая довольно устарела. Раньше это был способ получить базовый анализ ваших данных почти в реальном времени. Это было очень интересно, потому что, если мы вернёмся на 30 лет назад, когда была основана Business Objects, они были той компанией, которая… Иначе вы просто не могли выполнять синхронные запросы, которые давали бы вам информацию: сколько единиц продаётся в день, по продукту и так далее. Это было невозможно с бизнес-аналитикой. Внезапно стало возможным создать этот куб, можно даже использовать гиперкубы, и даже лучше — сделать всё очень качественно. Но в конечном итоге вы просто смотрите на супербазовую агрегацию ваших данных, а эта агрегация не является решением. Она не подсказывает, стоит ли повышать или понижать цену, производить больше или меньше, не говорит, что из партии в 1000 единиц нужно отправить 100 единиц на самолёте для ускоренной доставки. По сути, речь идёт всего лишь о получении количественных данных. Главное различие между BI и data lake заключается в том, что data lake даёт понимание, что он является лишь шестерёнкой в большей системе, где, сидя перед data lake, у вас обычно есть приложение на основе машинного обучения, которое обрабатывает данные с огромной эффективностью и автоматически генерирует решения. И эти решения оказывают физическое влияние на вашу компанию и создают ощутимую ценность.
Kieran Chandler: Хорошо, если мы согласны, что инструменты бизнес-аналитики имеют свои ограничения, то насколько на самом деле легко реализовать data lake? Это просто вопрос загрузки всех данных в облако, и всё готово?
Joannes Vermorel: Сложность реализации data lake строго пропорциональна сложности доступа к вашим источникам данных, то есть буквально доступа к ним, а не обработки их каким-либо умным способом. Это означает, что для больших транснациональных компаний, если в каждой стране вашей компании существует своя система, угадайте что: вам придётся развернуть столько data lake, сколько стран, чтобы собрать данные из каждой страны в один data lake. Но, к сожалению, у вас нет выбора, потому что единственная альтернатива — это прямая интеграция с каждой страной, и это ещё более затратно, ведь если у вас есть два подразделения, скажем, маркетинг и цепочка поставок, которым нужен доступ к данным о продажах, вы заплатите за эту интеграцию дважды. Идея data lake в том, что, настроив его один раз, данные становятся доступными для всей компании. Таким образом, сложность полностью зависит от того, что у вас есть. К тому же, если вернуться к вашему изначальному высказыванию: если у вас нет данных, вы всего лишь человек с мнением. В таком случае у вас нет другого способа получить эти данные, если вы хотите проводить какие-либо измерения.
Kieran Chandler: Давайте подытожим. Если data lake имеет так много положительных сторон и кажется довольно простым — ведь это всего лишь большой резервуар данных — почему же он не используется широко в промышленности на данный момент?
Joannes Vermorel: Оказывается, что очень маленькие технологически ориентированные компании приняли data lake довольно давно, и пошли дальше, внедрив, можно сказать, API-фикацию своей компании, то есть установили API (Application Programming Interface) на каждый компонент системы, что является следующим шагом после data lake. Так что, умная электронная коммерция, например, уже консолидировала свои данные, и так далее.
Kieran Chandler: Нужно взглянуть и на то, что происходит сегодня: с веб-сайта, что вы платите за маркетинг поисковой продукции, знаете, Google AdWords и тому подобное, а также через кросс-заказы. Они способны принимать умные решения в плане прямых маркетинговых действий и тому подобное. Что касается чисто технологичных компаний, таких как Microsoft или Google, они занимаются подобными вещами, вы знаете, буквально десятилетиями. То есть, Google существует всего два десятка лет, а прочие технологичные компании делают это уже очень давно. Так что, если они занимаются этим десятилетиями, что дальше? Что будет следующим? Будем ли мы иногда погружаться в океан данных?
Joannes Vermorel: Да, я имею в виду, что я вижу будущее за компаниями, ориентированными на цепочку поставок: теперь, когда data lake стали очень доступными и дешевыми, они будут внедряться. Мы видим среди наших клиентов, что многие из тех, у кого год назад не было data lake, теперь имеют его. Я бы сказал, что произошёл переломный момент за последние два года в вопросах data lake. Поэтому я подозреваю, что большинство крупных компаний в течение, возможно, ближайших пяти лет действительно внедрят свои собственные data lake, иначе они окажутся полностью вытесненными крупными игроками, которые это сделают за них.
Но есть и ограничения, в частности, data lake — это всего лишь копия для чтения всех данных, находящихся в других подсистемах. Вот почему я говорил, что следующий шаг — это заставить все подсистемы предоставлять API, интерфейсы прикладного программирования, как это сделала Amazon. Эти API позволяют делать ещё больше: внезапно вы получаете не просто возможность чтения, но и возможность действия. Идея в том, что вы можете консолидировать все данные, прочитать их, проанализировать, принять решения, а затем что делать с достигнутыми решениями? Ответ в том, что вы можете отправить Excel таблицу в нужное подразделение, чтобы они реализовали ваши решения, например, по закупкам. А если есть API, вы можете напрямую вызвать его, чтобы просто ввести заказ на покупку для данного продукта, в указанном количестве, от этого поставщика, с заданной транспортировкой и так далее. Таким образом, если у вас есть API, можно организовать сквозную автоматизацию, при которой вы не только автоматически генерируете решение, но и физически автоматически его реализуете, поскольку оно повторно интегрируется в одну из систем.
Kieran Chandler: Ладно, нам придётся на этом остановиться, но спасибо за ваше время сегодня. Это всё на этой неделе. Большое спасибо за внимание, и мы вернёмся в следующий раз. Пока!
