Этот пост является частью небольшой серии, начинающейся с: Данные как код - устранение производственных дефектов для наборов данных Google Analytics.
Данные как код - это простая концепция. Так же, как Инфраструктура как код. Он просто говорит: Обращайтесь с вашими данными как с кодом. И все же, после того как IaC появилась на Радаре ThoughtWorks в 2011 году, потребовалось около 10 лет, чтобы освоиться, и все еще находится в непростой ситуации, когда сторонники IaC считают, что им нужно напомнить людям следующее:
«…. Сказать «относиться к инфраструктуре как к коду» недостаточно; нам необходимо обеспечить последовательное применение с трудом извлеченных из мира программного обеспечения уроков в области инфраструктуры »
Вот и все. Поскольку я считаю, что нам не следует ждать еще 10+ лет, чтобы получить высококачественные приложения для обработки данных быстро, я написал эту статью (серию).
Итак, что такое DaC?
Данные как код: использование тех же передовых методов, которые мы изучили в программном обеспечении, и их применение к данным во всех областях данных, операционных данных, аналитических данных, данных науки о данных,… управления версиями, автоматического тестирования, систем CI,… с помощью цель - быстро предоставлять ценные данные.
Я опасаюсь, что внедрение данных как кода (DaC) займет даже больше времени, чем IaC, что приведет к огромным потерям благосостояния для всех нас. Я думаю, что в небольшом обсуждении концепции DaC не хватает трех важных концепций. Эти три концепции - это «дарфакты», «машиностроение с участием человека» и «интеграция данных».
Я объясню концепции и почему они так важны, а также объясню принципы, которые мы должны перенести в мир данных.
И хотя, вероятно, было бы разумно говорить обо всех причинах провала «старой модели», мне нравится сосредотачиваться на новом мире, новых концепциях и новых возможностях.
Что случилось? Старые обычаи в новом мире
Так было до сих пор и произойдет в следующие годы ...
Объем данных в наших приложениях растет экспоненциально. Он используется не только оперативно для хранения объектов, «запоминания вещей», но и аналитически для анализа вещей и принятия более эффективных решений. В-третьих, он используется «аналитически оперативно» в приложениях машинного обучения. Последние два приложения вызвали кембрийский взрыв использования данных.
Таким образом, как объем доступных данных, так и ценность данных находятся на кривой экспоненциального роста.
На мой взгляд, это приведет к эпохе, когда данные станут электричеством будущего, питая все.
Проблема: Мы продолжаем работать старыми способами в этом новом мире. В то время как мы должны применять золотой стандарт производственных технологий, которые мы уже научились применять к программному обеспечению, к данным.
Концепции в мире DaC
Люди говорят о данных как коде, но до сих пор я не видел ничего похожего на то, что должно происходить в моей голове. Что уже движется в правильном направлении, так это понимание того, что нам нужно версировать данные (см., Например, такие инструменты, как dvc или lakeFS) и тестировать их (см. Monte carlo или большие ожидания).
Я думаю, это потому, что в обсуждении данных как кода отсутствуют три важных концепции. Давайте посмотрим на них.
Дарфакты
Программные артефакты - это вещи, созданные в процессе разработки программного обеспечения. Обычно разработчик разрабатывает код, помещает его в центральный репозиторий, а затем в систему CI / CD, где он создается. Затем он доставляется на разные «стадии» для тестирования и, наконец, продвигается в рабочую среду.
С другой стороны, дартефакт также является артефактом, но не процесса разработки программного обеспечения в этом смысле. Это то, что создается системой, которая развертывается на любом из этих этапов и отправляется обратно в центральное место, как дротик. Особым примером, конечно же, являются данные.
Обратите внимание, что артефакт, созданный человеком, похож на набор «ограждений», тогда как теперь дартифакт представляет собой саморазвивающуюся систему. Это подводит нас к следующему пункту - программной инженерии будущего.
Человеческое машиностроение
Итак, служба должна фиксировать данные? Это здорово, но что, если что-то сломается, машина не может исправить ситуацию сама, верно? Собственно, мы уже используем правильный рабочий процесс именно для этой задачи в рамках CD4ML.
Для моделей машинного обучения непрерывного / онлайн-обучения ThoughtWorks рекламирует в чем-то похожий рабочий процесс. Выглядит это примерно так:
- Мы настроили конвейер тестирования и оценки в нашей системе компакт-дисков для нашей модели машинного обучения.
- Мы вводим такие тесты, как «если новая модель не превосходит предыдущую, не используйте ее, иначе разверните ее автоматически».
- Развертываем новую модель машинного обучения. Также с ним разворачиваем сборщик данных.
- Всякий раз, когда появляется пакет новых данных (скажем, за день), сборщик данных передает данные в git и запускает конвейер, оценивает новую модель и, возможно, публикует ее.
Конечно, когда конвейер выходит из строя, инженер по машинному обучению получает уведомление и может работать над моделью. Потому что, в конце концов, если с большим количеством данных ситуация ухудшится, это означает, что что-то, вероятно, сломается. Но теперь у него есть шанс просто поставить более надежные ограждения и позволить системе обрабатывать вещи с их помощью и, таким образом, постоянно улучшать себя.
Это машиностроение с участием человека, машины, занимающиеся «разработкой», когда люди приходят и делают «тяжелую работу». Пока я не видел, чтобы эта тема затрагивалась ни в одной из дискуссий, но я думаю, что это важная тема, потому что я не вижу другого будущего, кроме этого, для всех областей развития.
Вы когда-нибудь задумывались об этом? Зачем вам, как разработчику, решать проблему, которая уже решалась 10000 раз раньше и которая публично доступна где-то в миллионах строк кода в Интернете? Это очень похоже на то, что должна делать машина…
Интеграция данных²
До «Инфраструктуры как кода» было просто программное обеспечение. Теперь появилось две дополнительных точки интеграции. Вопрос, конечно, в том, что, поскольку инфраструктура просто существует для запуска программного обеспечения, когда я рассматриваю его как код, как мне поступить с программным обеспечением? Но у этой проблемы есть только два варианта:
- Инфраструктура + программное обеспечение как одно целое
- Возьмите их как отдельные единицы
Для данных как кода, с другой стороны, я чувствую, что у нас намного больше вариантов просто потому, что он третий в раунде, и потому, что на самом деле он используется по-разному.
Три практических типа данных
Я практически вижу, что сегодня используются три разных «типа данных» или «категории приложений данных». Рабочие данные, основная цель которых - запоминать. Кроме того, существует аналитическая цель, основная цель которой - помочь людям принимать более обоснованные решения. И, наконец, аналитически оперативный, который обычно также рассматривается как аналитический, цель которого - автоматически помогать кому-то принимать более правильные решения (будь то в системе рекомендаций, которая помогает вам сделать лучший выбор фильмов или в реальной системе поддержки принятия решений с помощью прогнозов и т. д.).
Мне нравится разделять последние два просто потому, что только приложения для аналитических операций с данными до сих пор были близки к данным в виде кода, как я понимаю с использованием рабочего процесса CD4ML / CML.
Принципы DaC
Практически все принципы DaC - это перевод 1–1 с принципов современной современной разработки программного обеспечения. Тем не менее, если мы посмотрим на мир данных, они вообще не используются ни в одной из трех областей данных, описанных выше ...
Почему мы должны это сделать? Потому что большинство этих принципов исходят из мира бережливого производства, где основное внимание уделяется одновременному увеличению объемов производства и качества потока. Это то, что сделало Toyota, и это то, что сделало большинство современных технологических гигантов. Так почему мы должны игнорировать то, что так хорошо работает, если нам важен поток данных?
Войдите, принципы.
(1) Все в системе контроля версий
Звучит легко, и это то, что часто называют «данными как кодом», но, как вы можете видеть, оно покрывает всего 5% от того, что представляют собой данные как код.
Принцип: храните данные в системе контроля версий. Все об этом.
(2) Небольшие коммиты - небольшие фрагменты данных
По какой-то причине мы «группируем данные» в огромные партии. Тем не менее, из мира программного обеспечения мы уже знаем, что если мы совершаем что-то серьезное, наши шансы что-то сломать очень велики, и усилия по исправлению также велики.
Принцип: фиксируйте небольшие изменения DaC.
Это изменение мышления. Если раньше мы переобучали нашу модель машинного обучения с использованием новых данных, когда у нас было много новых данных, то теперь мы выступаем за постоянное переобучение.
Не забывайте о компромиссе между скоростью и размером, но не более того. Я думаю, что обычно люди боятся «часто фиксировать данные», потому что они думают, что они будут чаще ломаться. Но правда как раз наоборот: чем меньше новый / измененный набор данных, тем легче его исправить.
Это, конечно, работает только в том случае, если «фиксация / проглатывание /… часто» не приводит к нарушению производственной системы, поэтому давайте взглянем на другие принципы.
(3) Локальные модульные тесты создателем кода
Мы все запускаем модульные тесты нашего кода перед тем, как отправить его в центральный репозиторий, потому что мы не хотим фиксировать сломанный код.
Тем не менее, приемники данных и другие системы обычно загружают данные прямо в производственную систему без каких-либо тестов.
Принцип: создатель дартифакта DaC также тестирует его «локально», прежде чем отправить в центральную систему.
Например, это будет означать, что ваша онлайн-система машинного обучения выполнит тест, например проверка его статистического распределения. Если это не удастся, он не отправит данные в систему для обучения, а скорее поместит новый фрагмент данных «на сторону».
(4) Выполнение заказа на продвижение
Сборки программного обеспечения сначала развертываются в песочнице, затем в среде интеграции и, наконец, в производственной среде.
Тем не менее, как приемники данных, так и некоторые онлайн-приложения для машинного обучения, а также операционные данные сбрасываются прямо в производственную систему.
Принцип: DaC отслеживает порядок продвижения, как и все остальное.
Это может показаться странным для операционных данных, но я считаю, что в этом есть ценность. Подумайте об этом, вы, вероятно, делаете резервную копию своей большой производственной базы данных. Почему вы просто предполагаете, что данные внутри него, например, не коррумпированный? Почему вы предполагаете, что можете использовать его для восстановления, не тестируя это сначала на этапе интеграции? Почему вы предполагаете, что он по-прежнему интегрируется со всем остальным?
(5) Одинаковые данные на всех этапах
Следствием этого является этот принцип. Мы сохраняем единый DaC на всех этапах. Обычно компании хранят лишь небольшую выборку или поддельные данные на непроизводственных этапах. Я выступаю за 180 по этому поводу. Почему? Поскольку мы хотим протестировать наш дарфакт в тех же условиях, с которыми он столкнется в производственной среде, в противном случае мы не сможем полагаться на наши тесты и снизить качество наших данных, произвести больше ошибок и в конечном итоге замедлить доставку данных.
Конечно, как и в случае с программным обеспечением, мы, конечно, можем применить конфигурацию вне среды, которая может быть:
- Конфигурация «выборки» на нижних ступенях или
- Конфигурация маскирования для маскировки данных PII
Для читателя, знающего о размерах: нет причин делать это физически. Это не означает, что мы должны постоянно копировать терабайты данных. Это может происходить как операция с метаданными без какого-либо копирования. Бонус: если мы используем только операции с метаданными, с моей точки зрения, это должно соответствовать GDPR (хотя я не юрист).
(6) Магистральная разработка, несколько филиалов
Принцип: мы сохраняем только 1-2 ветки, включая магистраль / главную для наших данных.
Это гарантирует, что мы действительно соблюдаем указанные выше принципы, такие как локальное тестирование и продвижение по служебной лестнице.
(7) Мы идем с осью перемен
Принцип: мы сокращаем DaC и сервисы данных вдоль оси изменений, а не ортогонально к ней.
Это означает, что мы стараемся урезать вещи до мелочей, но скорее на границах домена. Мы стараемся не отделять прием данных от нашей новой крутой системы машинного обучения, в конце концов, они должны работать вместе. Это означает, что мы не разделяем нашу систему бизнес-аналитики на части «прием / преобразование / очистка / сохранение / сохранение», а скорее на «бизнес-компонент Unit1 / Business Unit2 /…». биты.
Зачем это делать? Во-первых, это правильно, следуя всем идеям концепции сетки данных. Во-вторых, если мы направим прием данных для нашего компонента машинного обучения через крупномасштабное озеро данных, у нас практически не будет шансов проверить целостность системы. У нас не будет шансов на самом деле обеспечить качество фактической единицы, производящей ценность, компонента машинного обучения. Мы просто сможем обеспечить кусочную целостность, которая сильно отличается от целостности единицы, производящей ценность.
С другой стороны, если мы объединим все части в один архитектурный квант, довольно легко обеспечить полную целостность компонента и, таким образом, фактически позволить ему непрерывно улучшаться в течение всего дня.
(8) Часто интегрируйте кодовую базу и компоненты
Принцип: часто интегрируйте свои данные вместе с приложением, которое их создает, тем, которое их хранит, и его инфраструктурой.
Я думаю, что для любого, кто когда-либо восстанавливал резервную копию данных, это должно показаться знакомым: после восстановления из резервной копии все просто не работает так же, потому что вещи, связанные с данными, эволюционировали, но данные сделали шаг назад. Поэтому важно снова и снова интегрировать данные со всем остальным, с инфраструктурой и программными компонентами, точно так же, как мы продолжаем интегрировать все программные компоненты и инфраструктуру друг с другом.
(9-…) Я уверен, что есть еще
…
Что такого особенного в данных, разве не важнее?
Я думаю, что люди уже приближаются к мышлению, очень близкому к этому, потому что данные становятся самым ценным ресурсом на этой планете, но трубы для работы с ними еще не достигли этого.
Две вещи существенно отличаются от того, что до сих пор происходит в Code as Code и Infrastructure as Code:
- Здесь большую часть коммитов берут на себя машины.
- Огромный объем данных.
Но опять же, инфраструктура также сильно отличается от кода, по крайней мере, код просто отличается по размеру, инфраструктура на самом деле имеет другой внешний вид и, следовательно, требует обширного сопоставления кода с реальной физической инфраструктурой.
И, как объяснялось выше, я не думаю, что машины, работающие над кодом, на самом деле что-то новое.
Так что, возможно, данные как код - это сдвиг в сознании, но я не считаю, что это что-то важное, и преимущества с точки зрения повышения качества и скорости для этого нового ценнейшего продукта огромны.
Остается открытым вопрос, нужен ли нам слой абстракции поверх данных, как в IaC? Например, для маскировки данных? Я не знаю, еще неизвестно, что будет работать и еще много чего.
Чего еще не хватает - что нам нужно развивать?
Я загорелся этой темой, когда наткнулся на lakeFS. Потому что то, что я вижу отсюда, похоже, что они могут направиться в направлении, где они:
1. Умеют моделировать распределенные данные, по существу,
2. разделение модели чтения данных из хранилища данных.
Мне кажется, это именно то, что нам нужно, чтобы заставить все принципы работать как шарм, потому что, как уже упоминалось, «размер данных» не позволяет часто справляться, особенно когда мы стремимся ускорить работу, а не замедлить ее.
Это будет похоже на слой абстракции над инфраструктурой, которую мы используем для IaC.
Чего еще не хватает? Технически все возможно. Но большинство вещей еще не просты. По-прежнему сложно разветвлять данные внутри хранилища данных или передавать данные через систему CI.
Куда тебе идти дальше? Дальнейшее чтение
Если это привлекло ваше внимание, то неплохо было бы обратиться к прикладным статьям. Чтобы ознакомиться с приложением для оперативных аналитических данных, вам действительно следует прочитать статью ThoughtWorks.
Поскольку в аналитическом пространстве ничего не было, мне потребовалось время, чтобы написать сопутствующую статью об использовании данных как кода для устранения производственных дефектов в мире данных.
Я еще ничего не видел в мире операционных данных, но уверен, что есть умные люди, которые уже делают именно это, чтобы защитить свои резервные копии и т. Д.
Заключительные мысли
Это скорее мысленный эксперимент и шаг к тому, чтобы заставить людей думать о данных как о коде, чем он основан на опыте построения рабочих моделей. Так что, если у вас есть какие-либо примеры чего-то подобного в действии, я хотел бы о них услышать!
