[Эта запись в блоге изначально была опубликована Фредом Нунесом в блоге DareData под названием Как выглядит здоровая экосистема]

Введение

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

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

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

Что такое экосистема данных?

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

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

У нас есть сырая нефть на земле, которую добывают с помощью нефтяной вышки; затем он транспортируется на нефтеперерабатывающий завод, где модифицируется в соответствии с потребностями различных конечных потребителей. Наконец, рафинированное масло доставляется в разные места.

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

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

У вас есть резервуары для хранения нефти, в которых сырая нефть хранится навалом. В экосистеме данных эту роль берет на себя озеро данных.

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

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

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

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

Столпы надежной экосистемы данных

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

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

Они следующие:

  • доступность данных
  • обнаружение данных
  • происхождение данных
  • владение данными

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

Доступность данных

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

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

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

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

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

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

В Daredata мы склонны отдавать предпочтение упрощенным архитектурам озера/хранилища данных. Наша реализация обычно выглядит примерно так:

В итоге:

  • мы собираем все данные из ваших различных систем и сохраняем их в экономичном облачном озере данных (ваши нефтяные резервуары!). Это рекомендуемое нами решение для отслеживания истории данных вашей компании. Обычно это решает проблему доступности инженерии данных, поскольку обычно довольно просто построить коннекторы между любым источником данных, который у вас может быть, и современным озером данных.
  • мы загружаем данные из озера данных в решение для облачного хранилища данных с интерфейсом, подобным SQL (ваш перерабатывающий завод!). Именно здесь вся ваша сырая нефть будет переработана и преобразована во что-то пригодное для использования. Этот компонент решает проблему доступности для потребителей, устанавливая единую точку контакта с окончательными обработанными данными вместо нескольких разных баз данных/API, разбросанных по вашей инфраструктуре.

Эта архитектура очень хорошо сработала для нас, позволив нашим клиентам эффективно исследовать свои данные.

Подводный камень доступности данных: никогда не контролируйте доступ к данным на основе личных данных пользователей! Хотя может показаться заманчивым начать управлять разрешениями на уровне пользователя, в долгосрочной перспективе это обычно приводит к неуправляемо длинным спискам разрешений, которые, как правило, устаревают и заставляют вас терять информацию о том, кто именно имеет доступ к каким данным. Всегда используйте доступ на основе ролей! Это включает в себя назначение одной или нескольких ролей каждому потребителю данных, например, в зависимости от того, в каком отделе они находятся, а затем назначение разрешений ролям, а не отдельным лицам. Таким образом, вы можете включать/отключать роли для конкретных людей по мере изменения ландшафта вашей компании, что в долгосрочной перспективе гораздо более управляемо.

Обнаружение данных

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

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

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

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

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

Еще одна идея, которая меня интересовала, — это «самодокументирующийся код»: проектируйте свой код, связанный с данными, и конвейеры CI/CD таким образом, чтобы инженеры данных могли сосредоточиться только на функциональной стороне процессов обработки данных. Затем какой-то автоматический процесс генерирует документацию непосредственно из кода и комментариев к коду. Это упрощает для инженеров данных документирование своих процессов обработки данных, поскольку они могут делать это в ходе своего обычного рабочего процесса, а также имеет преимущество стандартизации стиля документирования для всех артефактов данных; но это, безусловно, сложная проблема, и ее необходимо тщательно реализовать.

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

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

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

Происхождение данных

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

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

Еще один хороший способ включить передачу данных — разработать процессы ETL данных (извлечение, преобразование, загрузка) в виде DAG — направленных ациклических графов — с помощью оркестратора, например, Airflow или Digdag. Это позволяет вам устанавливать зависимости и SLA (соглашения об уровне обслуживания) между вашими процессами данных и настраивать автоматические предупреждения в случае сбоя, чтобы можно было уведомить ответственных за последующие процессы.

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

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

Владение данными

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

Это кажется довольно простым, но важно учитывать последствия «эрозии времени» в ваших процессах владения данными:

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

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

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

Более экстремальная идея, которую я рассматривал, — это «агрессивная обрезка данных». Это заключается в том, чтобы пометить ваши артефакты данных как устаревшие, если они не обновлялись в течение нескольких недель, а затем автоматически уведомить их владельца. Затем, если владелец не обновит данные в течение нескольких дней, просто удалите их из своей экосистемы данных.

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

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

Заключение

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

DareData Engineering — это компания, занимающаяся консультированием данных и кадровым агентством, которая помогает компаниям устанавливать современные системы искусственного интеллекта. Найдите нас на следующих ресурсах:

Не стесняйтесь обращаться, мы будем рады услышать от вас!