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

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

В наши дни руководители заинтересованы в управлении данными из-за таких статей:

  1. Недавнее исследование Gartner показало, что организации считают, что низкое качество данных является причиной убытков в среднем 15 миллионов долларов в год.
  2. Первым крупным штрафом GDPR стал штраф в размере 57 миллионов долларов США от французского агентства по обработке данных.
  3. Утечка данных Equifax обошлась фирме в 1,4 миллиарда долларов (и продолжает расти), несмотря на то, что данные так и не были найдены.

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

Текущие «лучшие практики» управления данными нарушены

По моему опыту, причина отсутствия прогресса заключается в том, что мы неправильно выполняли управление данными, и оно перестало работать по прибытии. Стэн Кристианс получил это право в своей статье в Forbes, несмотря на то, что по сути это была реклама (очень эффективная) его компании. Я согласен с ним в том, что основная причина неудач управления в прошлом заключается в том, что технология просто не была готова, и организации не могли найти способов мотивировать людей следовать процессам, которые заполняли технологические пробелы. Однако я не согласен с тем, что современные инструменты каталогов данных предоставляют полный технологический ответ, необходимый нам для успеха (хотя они являются шагом в правильном направлении).

Если инструменты каталога данных - не ответ, то что?

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

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

Предыстория: как управление исходным кодом и компиляция создали программную инженерию

Основные инновации, которые создали дисциплину программной инженерии:

  1. Возможность компилировать набор входов в исполняемые выходы
  2. Системы контроля версий для отслеживания вводимых данных

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

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

Путем добавления согласованной системы версий ко всем изменениям, внесенным в код, который в итоге привел к созданию системы, искусство кодирования стало «измеримым» с течением времени (в смысле известной цитаты Питера Друкера: «вы не можете управлять тем, что вы не могу измерить »). Оттуда были добавлены всевозможные дополнительные инновации, такие как автоматические тесты, статический анализ качества кода, рефакторинг, непрерывная интеграция и многие другие, чтобы определить дополнительные меры. Что наиболее важно, команды могли регистрировать и отслеживать ошибки в конкретных версиях кода и давать гарантии в отношении конкретных аспектов поставляемого ими программного обеспечения. Очевидно, что было много других инноваций для улучшения разработки программного обеспечения, но трудно придумать те, которые не зависели бы каким-либо образом от компиляторов и контроля версий.

Все как код: применение основных инноваций программной инженерии в другом месте

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

Первым направлением расширения было предоставление инфраструктуры. В этом примере код представляет собой набор файлов конфигурации и сценариев, определяющих конфигурацию инфраструктуры в разных средах, а компиляция происходит на облачной платформе, где конфигурация считывается и выполняется вместе со сценариями для API облачных служб для создания и настройки виртуальной инфраструктуры. . Хотя может показаться, что движение «Инфраструктура как код» охватило все группы разработчиков инфраструктуры в одночасье, масса удивительных инноваций (виртуальные машины, программно-определяемые сети, API-интерфейсы управления ресурсами и т. Д.) Позволила сделать этап «компиляции» возможным. Вероятно, это началось с проприетарных решений таких фирм, как VMWare и Chef, но стало широко распространяться, когда поставщики общедоступных облаков сделали базовые функции бесплатными для использования на своих платформах. До этого перехода команды инфраструктуры управляли своими средами, чтобы обеспечить согласованность и качество, поскольку их было трудно воссоздать. Это привело к появлению уровней управления, предназначенных для применения контроля на различных контрольных точках в процессе разработки. Сегодня команды DevOps создают инженеры в своих средах, и элементы управления могут быть встроены в «компилятор». Это привело к значительному улучшению возможностей развертывания изменений, переходящих от месяцев или недель к часам или минутам.

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

Ближе к делу: то же самое произойдет и с управлением данными

Следующее поле, которое будет использоваться этим явлением, - это управление данными / управление данными. Я не уверен, как будет называться (DataOps, Data as Code и DevDataOps кажутся немного неуместными), но его эффекты, вероятно, будут даже более эффективными, чем DevOps / инфраструктура как код.

Конвейеры данных как компиляторы

«С помощью машинного обучения ваши данные пишут код». - Крис Скринак, руководитель сегмента ML в AWS

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

«Конвейеры данных - это просто компиляторы, которые используют данные в качестве исходного кода».

Эти «компиляторы данных» имеют три отличия, но также более сложные по сравнению с компиляторами для программного обеспечения или инфраструктуры:

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

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

Текущий набор технологических платформ управления данными (Collibra, Waterline, Tamr и т. Д.) Создан для обеспечения этого рабочего процесса, и они неплохо справляются со своей задачей. Однако рабочий процесс, который они поддерживают, по-прежнему делает определение управления данными ручным процессом, выполняемым на обзорных встречах, что сдерживает те улучшения, которые мы наблюдали после появления DevOps & Infrastructure as Code.

Недостающее звено: контроль версий данных

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

Настал переломный момент в управлении версиями данных

Такие платформы, как Palantir Foundry, уже относятся к управлению данными во многом так же, как разработчики относятся к управлению версиями кода. На этих платформах наборы данных могут быть версионированными, разветвленными, на них можно воздействовать версионным кодом для создания новых наборов данных. Это позволяет проводить тестирование на основе данных, при котором сами данные тестируются во многом так же, как и код, который их изменяет, может быть протестирован с помощью модульного теста. По мере того, как данные проходят через систему таким образом, система автоматически отслеживает их происхождение, как и продукты данных, которые производятся на каждом этапе каждого конвейера данных. Каждое из этих преобразований можно рассматривать как этап компиляции, на котором входные данные преобразуются в промежуточное представление, прежде чем алгоритмы машинного обучения преобразуют окончательное промежуточное представление (которое группы данных обычно называют набором данных Feature Engineered) в исполняемую форму для прогнозирования. Если у вас есть 10-40 миллионов долларов, которые готовы пойти ва-банк с поставщиком, интеграция всего этого в Foundry будет довольно впечатляющей (отказ от ответственности: у меня нет большого опыта работы с Foundry; эти утверждения были основаны на демонстрациях реальных реализаций, которые я видел на клиентах).

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

Следующим шагом будет восстановление управления данными.

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

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