Пионерская наблюдаемость данных данные, код, инфраструктура и ИИ

Передовые технологии в области искусственного интеллекта, кодирования данных и инфраструктуры пионерская перспектива

Когда мы запустили категорию “наблюдаемость за данными” в 2019 году, это было что-то, что я едва мог произнести.

Четыре года спустя, эта категория прочно заняла свое место в современном стеке данных. Наблюдение за данными – это категория G2, признанная Гартнером, Форрестером и многими другими, и, что самое важное, широко принятая сотнями компаний, включая некоторые из самых передовых организаций по работе с данными в мире.

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

Хотя я по-прежнему не всегда могу правильно произнести это слово (ESL в помощь), наблюдение за данными стало неотъемлемой частью современных команд по работе с данными, и мне несказанно гордо за то, как далеко мы продвинулись в этом движении и куда мы идем дальше.

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

С чего мы начали

В середине 2010-х годов команды по работе с данными начали переходить в облако и принимать технологии хранения данных и вычисления — Redshift, Snowflake, Databricks, GCP, ох уж эти технологии! — для удовлетворения растущего спроса на аналитику. Облачные технологии сделали обработку данных более быстрой, трансформацию данных проще и доступность данных выше.

По мере того, как данные становились все более широко распространенными, конвейеры стали более сложными, в появление которых вступили новые персонажи для управления этим хаосом (привет, data engineers), и число возможных сценариев использования данных взорвалось.

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

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

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

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

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

  1. Обнаружение: наблюдение за данными обнаруживает аномалии и другие проблемы в ваших данных и предупреждает соответствующих владельцев команды по работе с данными до того, как о них узнают заинтересованные стороны.
  2. Устранение: одновременно платформы наблюдения за данными предоставляют командам инструменты для устранения проблемы, включая линеаграммы на уровне полей, автоматический анализ корневой причины и анализ влияния, информацию о прошлых событиях, влияющих на этот атрибут, связанные журналы запросов и модели dbt, затронутые отчеты и многое другое.
  3. Предотвращение: в конце концов, наблюдение за данными также предоставляет механизмы для предотвращения возникновения проблем с данными в первую очередь, такие как внедрение прерывания в конвейеры и создание прозрачности относительно изменений кода, которые могут повлиять на данные, среди других проактивных мер по предотвращению входа некорректных данных в ваши конвейеры.

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

Расширение обнаружения и решения проблем за пределами данных

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

С увеличением объема работы команды по работе с данными в организации и расширением сферы применения данных, роль команды по работе с данными становится более значимой для финансовых показателей, чем когда-либо ранее. Теперь каждый сотрудник компании ежедневно использует данные для получения новых идей, разработки цифровых сервисов и обучения моделей машинного обучения. Фактически, мы перешли от простого отношения к данным как к продукту. В 2023 году данные САМИ являются продуктом.

По мнению сотен клиентов, включая команды Pepsi, Gusto, MasterClass и Vimeo, мы поняли, что для обеспечения надежности данных необходимо обратить внимание не только на данные, а также на достижение надежности кода кода и инфраструктуры.

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

В сфере данных часто ситуация аналогична, и пришло время начать рассматривать ее именно так.

Давайте рассмотрим гипотетический пример из мира данных.

Представьте, что у вас есть панель управления, на которой отображаются устаревшие результаты. Сначала вы можете посмотреть на ваши данные, в данном случае, возможно, это таблица полученная из Google, описывающая ваши рекламные кампании. Может быть, кто-то изменил название кампании, что нарушило жесткую связь в канале данных? Или, возможно, в таблице событий клика у вас появились пустые значения вместо идентификаторов пользователей UUID? Неудача — что дальше?

Вы анализируете код. Возможно, ваш аналитический инженер внес изменения в SQL-запрос, которые фильтруют самые последние данные? У них были благие намерения, но, возможно, это имело непредвиденные последствия? Вы заглядываете в свой репозиторий dbt. Нет — там все в порядке.

Наконец, вы исследуете вашу инфраструктуру. Вы быстро переходите к веб-интерфейсу Airflow — может быть, вы запустили его на малом экземпляре, и у него закончилась память (не нужно было загружать эти строки в память!!), что вызвало проблемы с обновлением данных. Еврика — вы нашли причину!

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

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

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

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

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

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

Надежные данные и будущее ИИ

Ставить на большие модели языка (LLM) как на будущее [вставьте отрасль здесь] уже стало почти клише, но влияние на отрасль данных отличается.

Сегодняшние случаи использования генеративного ИИ в данных и инжиниринге почти полностью сосредоточены на масштабировании производительности, таких как GitHub Co-Pilot, Snowflake Document AI и Databricks LakehouseIQ. Во многом мы не знаем, что принесет будущее генеративного ИИ, но мы знаем, что команды по работе с данными сыграют в нем большую роль.

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

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

Поддерживая этот подход, во время финансового отчета Snowflake за первый квартал 2023 года генеральный директор Snowflake Фрэнк Слутман заявил: “Генеративный ИИ питается данными. Вот каким образом модели обучаются и становятся все более интересными и актуальными… Вы не можете просто безраздельно пускать эти [LLM] на данных, которые люди не понимают с точки зрения их качества, определения и происхождения”.

Мы уже видели последствия ненадежного обучения моделей. В прошлом году глобальный кредитный гигант Equifax, сообщил, что модель ML, обученная на плохих данных, привела к отправке кредитным учреждениям неверных кредитных рейтингов для миллионов потребителей. И немного ранее компания Unity Technologies сообщила о потере прибыли в размере 110 миллионов долларов из-за неправильных данных об объявлениях, питающих свои алгоритмы таргетинга. В следующие годы это неизбежно станет еще большей проблемой, если мы не приоритезируем доверие.

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

Как предлагают сооснователи Databricks Матей Захария, Патрик Венделл, Рейнольд Ксин и Али Годси предсказание: “Приложения для предприятий также плохо переносят галлюцинации или неправильные ответы… В каждом этапе жизненного цикла машинного обучения данные и модели должны совместно поддерживаться для создания самых лучших приложений. Это еще более важно для генеративных моделей, где качество и безопасность так сильно зависят от хороших обучающих данных”.

Я полностью согласен. Первый шаг к лучшему, более значимому ИИ? Хорошие, надежные данные — и много их.

Статья оригинально опубликована здесь. Размещено с разрешения.