Фреймворк для понимания архитектуры корпоративных данных на AWS и Snowflake

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

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

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

Архитектура корпоративных данных: AWS + Snowflake

Прошло уже немало времени с тех пор, как мы начали нашу серию «Идеального конвейера не существует: версия X». В тех материалах мы попытались рассмотреть множество различных схем, которые появлялись в индустрии обработки данных: от Databricks, Azure и GCP до «Современного стека данных». Эти схемы охватывали знакомые шаблоны архитектуры данных, которые мы часто видели в индустрии обработки данных.

С тех пор кое‑что успело поменяться.

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

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

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

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

В этой статье мы обсудим несколько ключевых тем:

Как могло бы выглядеть оптимальное «домашнее» решение в AWS
Последовательность действий
Общая «лучшая в своем классе» архитектура данных, ориентированная на AWS
Предостережения и «подводные камни»

Когда вы задумываетесь о миграции из существующей или устаревшей облачной системы, такой как Talend или Informatica, или если вы рассматриваете возможность перехода с локальной базы данных SQL Server или Oracle, все это повлияет на ваше восприятие архитектуры данных.

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

Архитектура данных на чистом AWS: S3, Athena и AWS Glue

Стандартный подход, используемый архитекторами баз данных в AWS, заключается в использовании S3, AWS Athena и AWS Glue.

AWS S3 — это хранилище объектов, что означает, что в нем могут храниться файлы любого формата (или «неструктурированные данные»). Собственно это и будет слой хранения, где будут храниться все данные. Это мощный первый шаг, поскольку S3 обеспечивает прямую совместимость с открытой архитектурой (например, iceberg) или архитектурой lakehouse (Snowflake, Redshift или Databricks), что делает его использование практически беспроигрышным вариантом.

AWS Athena

AWS Athena можно рассматривать как warehouse‑интеграцию. По словам AWS:

Amazon Athena — это интерактивный сервис запросов, который позволяет легко анализировать данные, хранящиеся в Amazon Simple Storage Service (Amazon S3), с использованием стандартного SQL. Вы можете указать Athena на ваши данные, находящиеся в Amazon S3, и начать выполнять специальные запросы, используя стандартный SQL, и получать результаты за считанные секунд.

С помощью Athena вы можете легко запускать запросы для очистки, преобразования и агрегирования данных, сохраняя их в вашем облаке и в хранилище объектов. Важно отметить, что для корректной работы Athena метаданные файлов также должны быть в порядке. Поэтому ключевым моментом является обеспечение выполнения задания AWS Glue Crawler.

Здесь нам доступны такие важные функции, как доступ к API, однако опыта разработки по сравнению с такими инструментами, как Coalesce или dbt, немного не дотягивает.

AWS Glue

AWS Glue выполняет две важные функции в рамках типичной архитектуры AWS. Во‑первых, он обеспечивает пакетную передачу данных. Наиболее распространенным компонентом является AWS Glue для Python Shell, которая дает отделам обработки данных возможность создавать собственные скрипты для обработки данных и проверки их качества (что крайне важно в их работе), обеспечивая при этом бессерверное выполнение вычислений.

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

Движение данных: AWS Lambda, EC2 и ECS

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

Существует множество способов решения этой задачи. Наиболее распространенным является простой метод: написание скрипта на Python, который извлекает нужные данные по расписанию, и запуск его на облачной инфраструктуре, например, с помощью AWS Glue. Однако есть и более эффективные подходы, основанные на самых базовых элементах.

Если объем данных относительно невелик, то можно воспользоваться сервисами EC2 или ECS. Если объем данных небольшой, то может подойти даже AWS Lambda (за последние несколько лет время ожидания увеличилось до 15 минут).

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

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

Также стоит рассмотреть возможность использования python‑фреймворка с открытым исходным кодом для запуска приема данных в масштабах от низкого до среднего, таких как dlt, sling, pyairbyte (бета‑версия) и т. д.

None — *NonСистема перемещения данных Slinge*

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

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

Например, допустим, у вас есть инстанс Postgres RDS с таблицей «orders». Вы хотите проанализировать эти данные и объединить их с информацией из вашей CRM, чтобы понять, кто ваши самые прибыльные клиенты.

Вместо того чтобы пытаться напрямую реплицировать инстанс Postgres RDS с помощью AWS DMS или стороннего инструмента, возможно, будет быстрее настроить небольшой инстанс Kafka или очередь SQS с помощью функции AWS Lambda для получения события каждый раз, когда создается заказ. Обычно архитекторы сотрудничают с ведущими инженерами‑программистами для создания этих событий.

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

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

None — *Данные, требующие большого количества операций обновления*

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

Для небольших таблиц с медленно меняющейся размерностью вы можете просто захотеть «захватить» данные и куда‑нибудь поместить их копию («снапшот»).

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

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

Ниже представлена схема архитектуры:

None — *NБазовая архитектура данных AWSone*

Движемся дальше: архитектура озера данных (Data Lake) AWS

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

Рекомендации по последовательности действий при переходе к архитектуре озера данных

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

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

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

Мы рекомендуем следующую последовательность действий, которая, как мы убедились, хорошо работает:

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

Также можно рассмотреть возможность настройки аналитической среды (Snowflake, Databricks, Redshift и т. д.) в качестве первого шага. Это позволит создать четкую инфраструктуру, процесс предоставления ресурсов и управления данными после их получения. Таким образом, компаниям не придется ждать целый год или даже больше, чтобы начать использовать эти данные. Настройка аналитической среды может происходить параллельно с испытаниями по перемещению данных с использованием таких инструментов, как AWS DMS или возможности миграции Snowflake. Это даст аналитикам статическую копию данных для работы во время автоматизации процесса перемещения.

Мы всегда рекомендуем использовать BI или этап активации в последнюю очередь. Это «последний рывок» аналитики и, следовательно, самый рискованный этап. Если провести аналогию, то очень неприятно, когда после транспортировки, приготовления и использования многочисленных цепочек поставок, когда еда уже доставлена, оказывается, что она испорчена.

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

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

Моделирование данных: Data Vault, схема звезды, медальон и одна большая таблица

Мы включаем примечание о моделировании данных, поскольку его значимость возросла, а риск «сделать что‑то не так» увеличился из‑за легко демократизуемых структур моделирования, таких как dbt.

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

None — *NoПример того, как схема звезды превращается в одну большую таблицу*

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

Лучшая в своей весовой категории архитектура обработки данных для AWS

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

Перемещение данных

Способы перемещения данных зависят от их источника, размера и скорости.

Инструмент для перемещения корпоративных данных обычно представляет собой экономичный способ передачи данных из приложений, таких как CRM и ERP, без особых требований к скорости. Примерами таких инструментов могут служить Fivetran, Rivery и Airbyte. Для создания пользовательских коннекторов можно воспользоваться услугами партнеров‑консультантов. Также могут быть полезны специализированные отраслевые инструменты, такие как Celonis для SAP или Corva для WHITSML в нефтегазовой отрасли.

Warehouse‑решения, такие как AWS Zero ETL, Databricks Lakeflow для Oracle или встроенные коннекторы Snowflake, также помогают минимизировать сложность.

None — *NoВстроенные ELT‑коннекторы в Snowflake*

Как правило, все, что требует задержки менее 5 секунд, должно поступать в механизм обработки на основе потоков и передавать данные в S3 или напрямую использовать что‑то вроде потоковой передачи по Snowpipe. Это гарантирует, что данные (большие и малые) могут быть эффективно и однородно загружены в хранилища объектов.

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

Если вы предпочитаете Kafka, можно рассмотреть управляемых провайдеров, таких как Confluent или RedPanda.

Для локальных баз данных рекомендуется использовать вендорное решение, основанное на концепции Change Data Capture (CDC). К таким решениям относятся Striim, Fivetran и Estuary. Если у компании есть сильная команда разработчиков платформ, самоуправляемый Debezium может быть хорошим выбором.

Сохранение объекта в warehouse

Если в качестве промежуточного слоя используется S3 или хранилище объектов, данные должны загружаться в warehouse с помощью SnowPipe, потоковой передачи Snowflake или внешних таблиц. Если выбран Iceberg, каталог Polaris от Snowflake обеспечивает совместимость и для этого решения.

Размещение данных в хранилище объектов в формате iceberg требует особого внимания. Confluent предлагает решение для этой задачи с помощью Tableflow, а iceberg‑ориентированные вендоры, такие как Upsolver, также успешно справляются с этим форматом. На момент написания статьи поддержка iceberg у всех этих вендоров была относительно новой.

Слой обслуживания warehouse и аналитики

В рамках архитектуры AWS мы предполагаем, что Snowflake используется совместно с остальным стеком данных AWS.

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

Snowflake также обладает тесной интеграцией с принципами обслуживания AWS, AWS private Link и Terraform.

Моделирование данных

Для моделирования данных предприятия могут рассмотреть два основных инструмента: dbt‑core и Coalesce.io. Dbt‑core можно запустить на AWS EC2 или ECS (или даже на самой Snowflake через Snowpark). Если на предприятии работает несколько аналитиков, которые нуждаются в облачной IDE, или если у вас недостаточно ресурсов для разработки платформы, dbt Cloud также может быть подходящим вариантом.

В качестве более надежного инструмента, ориентированного на работу со Snowflake, мы также рекомендуем Coalesce.io. Coalesce представляет собой code‑first инструмент преобразования с графическим интерфейсом. Он обладает множеством нужных функций, таких как мощная непрерывная интеграция, что может значительно ускорить процесс работы предприятий.

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

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

Бизнес-аналитика и активация

Существует множество вариантов эффективной активации данных в среде AWS.

В этой статье мы не будем подробно рассматривать все эти возможности, но мы подготовили несколько ресурсов, которые, как мы надеемся, окажутся полезными:

На высоком уровне можно выделить две наиболее развитые платформы для чистой бизнес‑аналитики: Power BI и Tableau. Однако, стоит отметить, что обе эти платформы могут быть дорогостоящими. В AWS есть собственные инструменты, такие как Quicksight и управляемая Grafana, которые позволяют пользователям работать в рамках AWS без необходимости дополнительных вложений.

Для пользователей, которым требуется работа с электронными таблицами, стоит рассмотреть возможность использования Sigma. Эта платформа тесно интегрирована со Snowflake, что дает возможность использовать функции Snowflake Cortex и выполнять операции «записи» непосредственно внутри платформы.

В области Reverse ELT на рынке выделяются два ведущих игрока: Census и Hightouch. Однако создание собственной системы также может быть весьма привлекательной идеей. Это позволит полностью контролировать процесс, что особенно важно при разработке с нуля, а также обеспечит дополнительный уровень проверки пулл‑реквестов и Git‑контроля, который не всегда доступен на облачных платформах.

Кроме того, такие компании, как Fivetran и Hevo Data, активно расширяют свою деятельность в этой сфере, что позволяет уменьшить сложность, предварительно изучив решения уже существующих вендоров.

Организация и мониторинг

Внутри самой Snowflake управление SQL‑запросами осуществляется с помощью dbt‑core или Coalesce.io.

Для архитекторов крайне важно иметь единую плоскость управления данными, которая выполняет несколько ключевых функций:

Сквозная оркестровка

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

Видимость процессов обработки данных

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

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

Укрепление доверия и коммуникации

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

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

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

Для AWS и Snowflake была разработана специальная унифицированная платформа управления операциями с данными — Orchestra. На стороне AWS она поддерживает выполнение заданий в EC2, ECS, AWS Glue, Lambda, а также в облачных и локальных средах Python (см. Интеграции).

Что касается Snowflake, Orchestra тесно интегрируется с такими платформами преобразования, как dbt‑core и Coalesce, предоставляя организациям единое пространство для отладки, обслуживания и оптимизации конвейеров данных. Пользователи также могут быстро получить полный доступ к своим информационным ресурсам, используя тестирование качества данных и оповещения.

Альтернативным вариантом является создание собственной системы самостоятельно с использованием различных инструментов, включая пакеты Python для управления рабочими процессами с открытым исходным кодом, такие как Airflow. Согласование выполнения сотен, если не тысяч, задач требует огромного объема работы и исключительных инженерных навыков.

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

None — *NoКак на самом деле выглядит общая стоимость владения собственным дата‑стеком*

Управление данными

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

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

Data Lineage

Data lineage служит различным целям, и в зависимости от вашей отрасли, вам следует четко понимать, для чего оно предназначено.

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

Для компаний финансовой индустрии требование data lineage может регулироваться нормативными актами, такими как BCBS_239. В этом случае обычной схемой является инвестирование в специально созданный lineage‑инструмент, который предоставляет подробный журнал аудита для всех систем, таких как Power Center в Informatica или IBM.

В других отраслях, таких как здравоохранение, аудит и расчет показателей с течением времени являются обязательными. В таких случаях требуется некоторый вид lineage на уровне столбцов. Следует отметить, что Snowflake предоставляет это «из коробки» в схеме ACCOUNT_USAGE. В противном случае можно приобрести отдельный lineage‑инструмент.

Архитектура

Ниже представлен пример архитектуры.

Заключение

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

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

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

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

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

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

Orchestra

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

Социальные сети

Orchestra в Linkedin (ссылка)

Приглашаем вас на открытый урок «Домены и моделирование в корпоративной архитектуре: практический взгляд от экспертов Otus и Sila Union», который состоится сегодня (22 июля) в 19:00. На уроке рассмотрим ключевые аспекты моделирования в корпоративной архитектуре и подходы, которые активно используются в практике ведущих специалистов отрасли.

Глубокие знания о построении архитектуры на уровне предприятия, включая подходы к моделированию и управление архитектурными решениями, вы можете получить на курсе Enterprise Architect.

Чтобы узнать больше о других образовательных программах, ознакомьтесь с каталогом курсов.