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

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

Если вы хотите поддержать это, поделитесь им в Twitter, LinkedIn или Facebook.

На этой неделе я наткнулся на ряд вещей: слабое сообщество для изучения сетки данных, введение в Reverse ETL и SLA для продуктов данных.

1 Сообщество Slack для обучения сетке данных

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

2 Обратный ETL или Просто еще один конвейер данных

Новые категории инструментов в мире данных важны, мы все еще находимся на первом дне с данными, поэтому многое еще впереди. Новая запись — это категория инструментов «Reverse ETL». В мире инженерии данных вы в основном сосредоточены на том, чтобы получать данные в свой контейнер данных, преобразовывать их и предоставлять конечным пользователям через какой-либо графический интерфейс или API.

Но в последнее время многие требования к командам по разработке данных предъявляются с другой стороны, они касаются отправки преобразованных и объединенных данных в другие инструменты, такие как Google Analytics, CRM-системы, инструменты автоматизации маркетинга и т. д. Вы можете написать новый интерфейс для каждого из них. из них, но это умножается довольно быстро, и обслуживание будет неприятностью.

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

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

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

Ресурсы

3 SLA/SLO для продукта данных

Я читал обе, замечательную книгу SRE от Google, а также ориентированное на данные продолжение «Инженерия надежности базы данных». Оба предоставляют отличные концепции для SLA и SLO. Эта статья — хорошее напоминание о том, почему SLA и SLO так важны для групп обработки данных. И, честно говоря, у меня такое ощущение, что у большинства команд по работе с данными их нет.

На мой взгляд, самая важная часть наличия конкретного соглашения об уровне обслуживания (согласованного вместе с заинтересованными сторонами) или цели уровня обслуживания (возможно, самостоятельно установленной) — это прозрачность, которую они привносят в работу группы обработки данных. Потому что, честно говоря, куча моих SLO, когда я работал инженером по данным, гласила: «обеспечивать 80% точность данных» или «предоставлять правильные данные в 60% рабочих дней».

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

С другой стороны, если вы довольны уровнем обслуживания, я рекомендую взять инструмент под названием «бюджетирование ошибок» и преобразовать его в инструмент «бюджетирования качества данных». Основная идея заключается в том, что вы должны договориться со своими заинтересованными сторонами об определенных уровнях качества данных, например, «95% дней данные должны обновляться на 1 час». Теперь, если показатель падает ниже этого уровня, скажем, на 90% ваша команда перестает разрабатывать новые функции и начинает работать над качеством, пока уровень сервиса не станет удовлетворительным. Таким образом, вы сможете справиться с напряжением, которое существует между разработкой функций и качеством.

Ресурсы

  • Статья Барра Мозеса об SLA продукта данных
  • Инженерия надежности сайта, Google
  • Инженерия надежности базы данных

P.S. Я делюсь важными, а не самыми последними новостями. Я делюсь книгами, исследовательскими работами и инструментами. Я пытаюсь дать простой способ понять все эти вещи. Но я склонен быть самоуверенным. Но вы всегда можете нажать кнопку отказа от подписки!