Если вы вовлечены в захватывающий мир машинного обучения, поздравляем! Мы находимся в ключевом моменте в области ИИ, с беспрецедентным доступом к данным/вычислениям и новаторскими технологиями, которые продолжают нас регулярно удивлять. Но пока нам с вами не терпится поиграть со следующим transformer/GPT-x/SSL/RL алгоритм/модель, мы все понимаем тот факт, что 80 % работы по анализу данных заключается в сборе тщательно отобранных высококачественных данных [1]. Таким образом, основной потребностью, которая может перевесить другие действия с данными, является надежный конвейер данных, который может легко и безопасно извлекать данные для подачи в модели машинного обучения.

Но мы уже знаем, как это построить. Для доступа к большим данным мы обращаемся к подобным Apache Hadoop и Apache Spark и объединяем данные из множества разрозненных источников данных, начиная от CSVв Postgresв Salesforce в Kafka в озера данных и облачные хранилища данных, такие как Snowflakeи Databricks. Сейчас мы даже внедряем методологии DevOps в MLOps для автоматизации процессов и организуем сбор данных с помощью таких инструментов, как Apache Airflow. Так в чем проблема?

На самом деле их много. Во-первых, большинство этих инструментов и методов требуют приема данных того или иного рода, то есть данные должны быть перемещены из источника, такого как Salesforce, например, в озеро данных. У этого процесса есть свои преимущества, но есть и недостатки: это не реальное время; он делает копии данных, что может быть проблематично с точки зрения управления конфиденциальности/данных (для поддержки таких правил, как CCPA и GDPR); и, возможно, самое главное, требует от нас написания кода для перемещения данных. Хотя у нас есть соединители/поставщики для популярных источников данных и инструменты, такие как Fivetran и DBT/Jinja, чтобы помочь построить конвейер ETL, процесс все еще требует пользовательское кодирование, особенно для нетрадиционных конечных точек данных.

Это само по себе не может быть проблемой. Большинство инженеров данных могут написать собственный код для подключения к источникам данных, которые обычно предоставляют четко определенные API через коннекторы, драйверы и веб-интерфейсы. К сожалению, не все из нас, специалистов по данным, имеют опыт или время. Поскольку инструменты и задачи анализа данных быстро развивались за последние несколько лет, сейчас все чаще можно встретить людей, одновременно выполняющих роли специалиста по данным, аналитика данных, Инженер данных, Инженер машинного обучения и Инженер-программист (даже если мы сможем определить рамки этих должностей!) [2]. Например, вы можете быть специалистом по математике, ставшим специалистом по данным и сотрудником SRE, которому поручено написать код Golang/C++ для доступа к объектным данным из Microsoft Dynamics, и вы бы предпочли Low-Code/No-Code. Затем возникает утомительная задача заставить все инструменты конвейера от разных поставщиков/проектов работать вместе.

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

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

В продукте Datafi политика и правила устанавливаются владельцем данных через пользовательский интерфейс; но клиенты, такие как Jupyter Notebook, извлекают данные как обычно, а пограничные серверы прозрачно фильтруют данные. Посетите datafi.us для получения дополнительной информации.

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

Ссылки
[1] MLOps: From Model-centric to Data-centric AI, Эндрю Нг на YouTube
[2] Изучение Эволюция роли инженеров данных, подкаст Data Engineering