Больше, чем слова: проливаем свет на путаницу в терминологии данных

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

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

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

Показательный пример: управление данными и метаданными. Слышали ли вы раньше такие термины, как управление данными, наблюдаемость данных, фабрика данных, сетка данных, DataOps, MLOps и AIOps? Но знаете ли вы, что именно означает каждый из них и как они все связаны? Вот ваш шанс узнать.

Слои данных

Несмотря на то, что мы были активными аналитиками в более широком ландшафте данных, мы, признаемся, не все из вышеперечисленного было нам полностью ясно. Поэтому, когда мы встретились с Маартеном Масшелейном и Томом Байенсом, мы решили, что попросим их мнение. Масшелейн и Байенс — сооснователи компании Soda, стартап, который только что получил награду Gartner «Крутой поставщик в области управления данными»..

Помимо того, что они официально объявлены крутыми, есть еще одна причина, по которой они могут кое-что знать: они были рядом. Масшелейн был сотрудником номер пять в Коллибра, который, по его словам, был первым, кто продавал программное обеспечение директорам по данным — еще до того, как это стало чем-то особенным. Байенс был основателем и руководителем проекта в jBPM, легендарный проект с открытым исходным кодом по управлению бизнес-процессами (BPM).

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

Фабрика данных фокусируется на технологическом аспекте единого доступа к данным.

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

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

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

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

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

Мониторинг данных, тестирование, фитнес и совместная работа

Что касается Операции с даннымиРечь идет об использовании возможностей, связанных с данными, организованных в соответствии с лучшими практическими процессами, для доставки продуктов данных с возрастающей скоростью и повышенной надежностью. Чтобы лучше работать с данными, необходимо внедрить и стандартизировать множество небольших процессов, аналогично тому, что мы сделали с DevOps в области разработки программного обеспечения, — сказал Масшелейн.

МЛОпс, который, похоже, используется как взаимозаменяемый с AIOps, опирается на хорошую основу DataOps, но является более специализированным. Например, в DataOps мы не будем отслеживать точность прогнозов. Это специфично для продукта данных, а также для жизненного цикла продукта данных. Масшелейн думает об этом с точки зрения жизненного цикла:

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

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

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

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

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

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

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

Пена и сода

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

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

Существует уровень с открытым исходным кодом, предназначенный для инженеров данных. Байенс считает, что пользовательский сегмент не обязательно заинтересован в предложении SaaS. Soda SQL с открытым исходным кодом стремится быть простым и работать с технологиями, которые любит использовать его целевая аудитория — SQL и YAML, по словам Байенса.

Soda SQL демонстрирует хороший рост и распространение, и это способ для людей познакомиться с Soda. Однако, если им нравится то, что они видят, и их потребности растут и включают таких людей, как аналитики и директора по дизайну, тогда пришло время перейти на платную SaaS-версию Soda.

Компания недавно получил 11,5 миллионов евро в рамках серии А., что в сочетании с предыдущим начальным финансированием дает в общей сложности около 14 миллионов евро. Это должно предоставить Soda хорошую платформу для развития своего предложения с целью роста как инженерной команды, так и команды по выводу на рынок.

Основатели Soda, похоже, хорошо понимают ситуацию, в которой они работают.