от Киран Пракаш и Люси Чемберс

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

К нам часто обращаются клиенты, которые хотят дать импульс своим инициативам в области ИИ, создав озеро данных. Часто этот план рассматривается исключительно как усилие по созданию инфраструктуры - без четко определенных сценариев использования. Предполагается, что «если мы построим надежную инфраструктуру данных, варианты использования появятся позже».

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

Что такое озера данных?

Когда мы слышим термин озеро данных, он обычно подразумевает:

  • Централизованное хранилище данных (операционных, связанных с клиентами, потоков событий и т. Д.) С надлежащей документацией и детальным контролем доступа.
  • Что-то, созданное и поддерживаемое инженерами данных, чтобы специалисты по данным могли использовать данные и сосредоточиться на разработке сценариев использования машинного обучения и т. Д.

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

Это неточное определение часто приводит к незапланированному расширению объема, перерасходу бюджета и чрезмерному проектированию. Возможно, корзина Amazon S3 с правильной настройкой разрешений на доступ может быть всем, что вам нужно в качестве инфраструктуры озера данных для хранения необработанных данных. Важно с самого начала определить и сформировать общее понимание того, что означает озеро данных для вашей организации.

Большинству крупных организаций было бы выгодно ограничить объем озер данных для хранения только необработанных данных и создать межфункциональные продуктовые группы для разработки приложений машинного обучения с использованием собственных представлений (витрин на берегу озера), специфичных для их случая использования. Цитата из Поста Мартина:

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

Мы увидим пример того, как такая установка может выглядеть чуть позже в этом посте.

Построить это; они придут

Озера данных особенно склонны «строить; они придут »менталитеты. Для этого могло быть несколько возможных причин.

Часто специалисты по обработке данных и инженеры по обработке данных входят в состав разных команд. Специалисты по обработке данных обычно более тесно связаны с бизнесом, а инженеры по обработке данных - с инфраструктурой и ИТ. Это может вызвать разрозненное мышление и склонность рассматривать озеро данных исключительно как проблему инфраструктуры. Закон Конвея снова действует.

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

Наконец, распространенный аргумент, который мы слышим в пользу подхода «строить, они придут», заключается в том, что озера данных должны поддерживать широкий спектр сценариев использования и не должны ограничиваться каким-то одним из них. Мы согласны с предпосылкой, что озеро данных должно поддерживать более одного варианта использования. Мы просто выступаем против слишком большого количества предварительной архитектуры и дизайна, которое происходит до рассмотрения вариантов использования.

Ловушки

Проектирование озера данных по принципу «сверху вниз», без учета конечных вариантов использования, почти неизбежно приведет к плохой подгонке проблемы / решения.

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

В действительности около 70–80% усилий при создании приложения машинного обучения связано с очисткой и представлением данных в формате, специфичном для конкретного варианта использования. Нет смысла прилагать много усилий к предварительной обработке данных, не зная, как они будут использоваться для построения моделей машинного обучения. Людям, создающим модель, скорее всего, придется снова вложить усилия, чтобы проделать аналогичную работу.

Проиллюстрируем это на гипотетическом примере:

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

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

  1. Вероятно, не существует единого определения клиента, которое одинаково хорошо работало бы для всех будущих сценариев использования.
  2. Получение информации о клиентах, сопоставление и дедупликация их из 20 разнородных систем - нетривиальная задача. Это предполагает массовую координацию между различными продуктовыми командами.

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

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

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

Продуктовое мышление для озер данных

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

Он начинается со следующего начального набора вариантов использования:

  • Выявление мошеннических претензий, чтобы они могли выбирать претензии для более тщательного расследования вручную; у них есть бизнес-цель по сокращению мошенничества на 5% в этом году.
  • Прогнозирование погодных условий, чтобы они могли посоветовать клиентам защитить свои автомобили, поместив их внутрь, когда есть высокая вероятность шторма, тем самым уменьшив количество требований о повреждении транспортных средств на 2%.
  • Продажа клиенту других страховых продуктов на основе уже имеющихся у него продуктов. Цель состоит в том, чтобы увеличить коэффициент конверсии для апселлинга в Интернете на 3%.

Страховая компания приступает к реализации проекта следующим образом.

Перед стартом

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

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

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

Существует кросс-функциональная группа доставки, в состав которой входят как владельцы продуктов из бизнеса, так и инженеры по обработке данных, и специалисты по обработке данных для разработки сценариев использования.

Работа с вариантами использования

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

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

Такой подход повлечет за собой использование двух из 20 источников данных, что позволит сэкономить массу потенциально потраченных впустую усилий и более эффективно достичь цели в 5%.

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

Теперь компания может перейти к варианту использования предупреждений. Это более сложная модель, в которой используются все необработанные данные, которые они использовали до сих пор, и добавлен дополнительный источник: данные о погоде в реальном времени.

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

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

В итоге:

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

Первоначально опубликовано на www.gotitworks.com 29 января 2019 г.