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

Предпосылка

  • Добро пожаловать в первый том этой серии из двух частей.
  • В этой первой части мы познакомим вас с новым подходом к инженерии данных, включающим эволюцию традиционных методов Enterprise Data Warehouse и Data Lake в новую парадигму Data Lakehouse, которая сочетает в себе предшествующие архитектуры с большим изяществом.
  • Далее мы разберем архитектуру Data Lakehouse, чтобы вы были знакомы с сервисами в экосистеме и с тем, как они будут использоваться в общем контексте проекта.
  • Наконец, мы закончим том 1, показав вам, как настроить Gitpod, интегрированную среду разработки, используемую для разработки проекта.
  • Во втором томе этой серии мы объясним, как настроить сервисы в нашей экосистеме Data Engineering для взаимодействия друг с другом и как создать шаблоны, на основе которых вы сможете реализовать свои собственные проекты данных, доказательства концепции и тесты на Платформа.
  • Data Lakehouse, который мы строим, во многом использует Apache Spark. Apache Spark — это унифицированный аналитический движок с открытым исходным кодом для крупномасштабной обработки данных, который предоставляет интерфейс для программирования кластеров, включающий параллелизм данных и отказоустойчивость. мы рассмотрели теорию и применение Apache Spark в этой статье.
  • Определения озера данных и хранилища данных были хорошо задокументированы в предыдущих статьях, пожалуйста, ознакомьтесь с ними, чтобы понять суть что и почему этого отчета.

Простыми словами;

  • Data Warehouse действует как столь необходимый центральный database (обычно реляционный, не транзакционный database), где аналитики данных или другие персонажи будут выполнять свои запросы бизнес-аналитики и генерировать идеи. Мы будем использовать PostgreSQL в качестве нашего хранилища данныхe.
  • По сути, Data Lake — это центральный репозиторий, в котором можно безопасно хранить различные типы данных всех масштабов для обработки и аналитики. Мы будем использовать Minio S3 Object Storage как наше озеро данных, то есть (центральное хранилище и источник достоверной информации для наших разрозненных данных).
  • Конечными пользователями этого решения будут потребители данных, такие как аналитики данных, специалисты по данным, инженеры бизнес-аналитики и любые другие потребители данных в организации.
  • То, чем я собираюсь поделиться с вами, уникально для практики Data Engineering, так что наберитесь терпения в этой статье.
  • Потребуется время, чтобы полностью внедрить и понять разработку этого озера данных, но тот факт, что вы здесь, означает, что вы открыты для понимания, спасибо за ваше время, давайте перейдем прямо к делу.

Смена парадигмы

Мотивация Data Engineering

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

Знакомство с парадигмой Data Lakehouse

  • Необходимо было создать новую парадигму, дисциплинированную в своей основе и гибкую на грани.

  • Адекватно спроектированный дом озера данных обеспечивает четыре ключевых преимущества.

1. Он извлекает полезную информацию как из структурированных, так и из неструктурированных данных.

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

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

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

Ле Архитектура

Мы обсудили системный контекст Data Lakehouse. Теперь приступим к разработке логического Data Lakehouse Architecture. Логическая архитектура фокусируется на компонентах, которые интегрируются для удовлетворения конкретных функциональных требований (FRs) и нефункциональных требований (NFRs).

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

FR — это требование, которое соответствует определенному поведению, связанному с бизнесом или доменом. Такого рода требования обусловлены задачами и потребностями конкретной бизнес-функции.

💡 Связанные с бизнесом ↔ Функциональные требования

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

💡 Технические/Для разработчиков ↔ Нефункциональные требования

Хорошо спроектированная система обеспечивает выполнение NFR без особых компромиссов. Следующая диаграмма изображает логическую архитектуру Data Lakehouse:

Технический стек

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

Давайте теперь подробно рассмотрим каждый из этих слоев.

Уровень приема данных {Apache Nifi}

  • Этот уровень является точкой интеграции между внешними поставщиками данных и хранилищем данных. Инструментом приема для этого проекта будет Apache Nifi.

Уровень озера данных {MinIO}

  • Как только уровень приема данных принимает данные, их необходимо поместить в хранилище, и над ними необходимо выполнить различные преобразования, чтобы преобразовать данные для потребления. Наконец, данные закрепляются в озере данных.
  • Вы знаете, что существует хранилище iCloud для продуктов Apple, облачное хранилище Google Диска и т. д. Объектное хранилище Minio S3 работает аналогично этому, это версия облака Amazon S3 без необходимости входа пользователя AWS IAM.
  • MinIO будет служить нашим центральным хранилищем для всех наших данных.

MinIOпредлагает высокопроизводительное объектное хранилище, совместимое с S3. Это означает, что мы можем использовать любые коннекторы, разработанные для AWS S3, с MinIO. Это позволяет нам разрабатывать концепции с объектным хранилищем локально — без необходимости размещать (и оплачивать) фактическую корзину S3 на AWS — и позже легко заменять соединение реальной корзиной S3, если мы того пожелаем.

Уровень озера данных имеет три основных категории хранилища, как показано здесь:

Необработанный слой:

  • Область, куда попадают данные от поставщика данных (Nifi/внешние источники), сортируется по папкам (бронза), которые отражают их происхождение (например, время и источник).
  • Как следует из названия, данные ( .csv / .json / .parq ) хранятся в хранилище необработанных данных в своей естественной форме, поэтому данные соответствуют исходному формату, структуре и содержанию. Иногда также называемая необработанной или промежуточной зоной, она используется для хранения необработанных принятых данных.

Курируемый слой:

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

Обработанный слой:

  • Этот уровень (золотой) указывает, что содержащиеся в нем данные готовы к работе, или cleansed указывает, что данные были обработаны инструментами контроля качества данных и/или процессом курирования для очистки (или очистки). проблемы с качеством данных.

Уровень обработки данных {Apache Spark и Apache Airflow}

  • Данные должны быть преобразованы или обработаны, чтобы их можно было использовать для понимания. Службы обработки данных выполняют работу по преобразованию поступающих данных в форму, которую мы можем предоставить заинтересованным сторонам.
  • С точки зрения вычислений Apache Spark — это золотой стандарт для всего, что связано с Lakehouse. Это многоязычный механизм для выполнения обработки данных, обработки данных и машинного обучения на одноузловых компьютерах или кластерах, который широко используется в Databricks и Synapse Analytics и обычно используется для вычислений в Lakehouse.

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

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

Уровень обслуживания данных {PostgreSQL}

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

Уровень аналитики данных {Jupyter Notebook}

  • Уровень аналитики данных включает в себя службы, которые извлекают информацию из данных.
  • Они служат площадкой для аналитиков, специалистов по данным и пользователей бизнес-аналитики, где они могут создавать отчеты, выполнять анализ и экспериментировать с моделями AI/ML.
  • Здесь вы можете использовать Spark для подключения к Minio S3 и нашему экземпляру Postgres через докеризованный экземпляр блокнота Jupyter. Реализация будет показана во втором томе.
  • Вы можете увидеть сервисы, которые делают нас этим уровнем, на следующей диаграмме:

Уровень безопасности данных и управления {Apache Ranger}

  • Принцип мусор на входе, мусор на выходе также применим к хранилищам данных. Данные в хранилище данных должны управляться соответствующим образом, и этот уровень заботится об этом.
  • Мы будем использовать Apache Ranger в качестве платформы для включения, мониторинга и управления комплексной защитой данных на платформе Data Lake.

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

Современная инженерия данных с Gitpod

Здравствуйте! Добро пожаловать в этот краткий обзор безупречного облачного решения для обработки данных — Gitpod.



Панель инструментов — Gitpod
Изменить описаниеgitpod.io



Что такое Gitpod?

  • Gitpod — это интегрированная онлайн-среда разработки, которую можно запустить с любой страницы GitHub.
  • В течение нескольких секунд Gitpod предоставляет вам полностью работающую среду разработки, включая IDE на базе VS Code и облачный контейнер Linux, настроенный специально для текущего проекта.
  • Gitpod — это приложение Kubernetes с открытым исходным кодом, предоставляющее готовые среды для совместной разработки в вашем браузере на базе VS Code..

Постановка задачи

  • Перед группой разработки данных в Oasis Corp была поставлена ​​задача разработать локальное решение для хранилища данных для клиента из нефтегазовой отрасли.
  • Проект включал использование Docker в качестве нашей основной среды разработки. Docker использует изображения, тома и Dockerfiles для выполнения кода для разработки.
  • В среднем установка Data Lake & Warehouse Environment займет не менее 20 ГБ памяти на ноутбуке и более 60% оперативной памяти системы.
  • Для добавления дополнительных служб и контейнеров потребуется надежная система с большим объемом ОЗУ и памяти, которых у нас нет.
  • Кроме того, запуск Docker в разных системах приводит к несоответствиям операционных систем, мы заметили, что у новых M1 Macbook Pro есть проблемы с образами докеров, а приложение Docker не может выполнять задания Spark в среде разработки.
  • Мы использовали Airflow в качестве основного инструмента планирования, а в процессе создания службы воздушного потока с помощью Spark, Postgres, Minio и других расширений команда инженеров данных ждала создания образов по 30–40 минут, что делало процесс разработки очень утомительным и отладка затруднена.
  • Мы также столкнулись с перегревом систем, постоянными сбоями и несоответствиями операционной системы, когда мы развернули наш код на ноутбуках друг друга.
  • Разработчики по-прежнему управляют средами разработки на своих локальных компьютерах. Они часто проводят свои дни в ожидании завершения тестов или сборок вместо того, чтобы кодировать.
  • Что, если бы существовала ускоренная разработка, более быстрая загрузка изображений и сервисов, поощрение совместной работы и предотвращение несоответствий операционной системы?

Представляем Gitpod

  • В чистом виде Gitpod служит облачным решением Docker для проекта Data Lakehouse.
  • Gitpod — это настоящее решение с открытым исходным кодом и поддержкой сообщества. Он работает волшебно быстро, может быть размещен самостоятельно и является единственным независимым от поставщика решением, которое работает практически с любым облачным провайдером и платформой для размещения кода, включая GitLab, GitHub и Bitbucket.
  • Gitpod избавляет от утомительной и трудоемкой задачи настройки и управления сложными средами разработки. Gitpod выполняет обещание среды разработки как код и предлагает полностью готовую безопасную среду, чтобы отдельные разработчики и группы могли сразу приступить к работе.
  • С момента принятия Gipod в проекте Data Warehouse Project наша команда добилась 5-кратного увеличения производительности и развития, мы смогли успешно интегрировать Spark в наш конвейер данных, Apache Nifi, Airflow, Minio, Postgres и другие ключевые сервисы. . Все в течение нескольких минут.
  • Принятие Gitpod позволило инженерам-стажерам лучше разбираться в отладке ошибок, опробовать новые подходы к хранению данных и расширить свои общие знания в области проектирования данных.
  • Gitpod поставляется с браузерной версией VS Code с предварительно настроенной настройкой Docker внутри, что позволяет убить двух зайцев одним выстрелом.
  • В целом это облегчило жизнь разработчикам при работе над крупномасштабными проектами.

Getting Started with Gitpod.

Шаг 0: Войдите.

  • Для начала перейдите на страницу авторизации.


Панель инструментов — Gitpod
Изменить описаниеgitpod.io



  • Решите, к какой платформе вы хотите получить доступ, для этого урока мы будем использовать Github.

Шаг 1: Предоставьте разрешения.

  • Этот шаг позволит вам отправлять запросы push/pull в GitHub прямо из вашего рабочего пространства Gitpod.
  • Перейдите к 👉🏼

Settings → Integrations→ Git Providers→ Github→ Actions Button.

Шаг 2: Настройка ключей SSH.

  • Это позволит вам работать в VS Code Desktop, если вам надоест пользоваться браузером.
  • Мы будем создавать ключи SSH на нашем локальном компьютере и сопоставлять ключи на Gitpod. Подробнее о SSH ниже, но если вы знакомы с Git, вам следует понять, «почему» мы используем ключи SSH.


Создание нового ключа SSH и добавление его в ssh-agent — GitHub Docs
Вы можете получать доступ и записывать данные в репозитории на GitHub.com, используя SSH (Secure Shell Protocol) . При подключении через…docs.github.com



  • Для новичков это просто сертификат, который говорит вашей IDE: «хорошо, у вас есть разрешение на удаленный доступ к этой рабочей области».
  • Чтобы сгенерировать новый SSH-ключ, перейдите в свой терминал на локальном компьютере.
ssh-keygen -t ed25519 -C "[email protected]"
  • Нажмите Ввод, затем снова нажмите Ввод, чтобы сохранить пару открытого и закрытого ключей в нужной папке с файлами. {вы можете перейти по ссылке Github выше, если заблудитесь}
  • Перейдите в папку ., в которой вы сохранили свои ключи, для пользователей Mac перейдите в свою домашнюю папку 🏡 и нажмите shift 🔼 + cmd + . , чтобы отобразить скрытые папки {отсюда и серый цвет ниже}.

  • Откройте файл ключа ssh {с помощью Text Edit}, который заканчивается на .pub {открытый ключ, затем скопируйте содержимое этого файла, включая ваш адрес электронной почты.
  • Заходи в 👉🏼

Gitpod → SSH Keys→ New SSH Keys и вставьте открытый ключ.

Шаг 3: Среда разработки.

  • Отлично, вы были потрясающими до сих пор, теперь время для важного момента.
  • Перейдите на GitHub и создайте новый репозиторий под названием «modern-datalake».

  • Вернитесь к 👉🏼

Gitpod → Workspaces→ New Workspaceи вставьте URL вновь созданного репозитория.

  • Подождите секунду, пока он инициализируется.

Шаг 4: Готово!

  • Вуаля, у нас есть полнофункциональная интегрированная разработка для нашего Data Lakehouse, упакованная с расширением Docker и облачным экземпляром VSCode. Аккуратный.

Заключение {Gitpod}

  • Gitpod — это не очередная облачная IDE, призванная заменить разработку для настольных компьютеров.
  • Вместо этого Gitpod является естественным расширением GitHub. Ограниченные возможности редактирования GitHub слишком часто вынуждают переключаться на наши локальные компьютеры. Gitpod продлевает нашу жизнь на GitHub.
  • Gitpod освобождает команды инженеров от ручной настройки локальных сред разработки, экономит десятки часов и обеспечивает новый уровень совместной работы для создания приложений намного быстрее, чем когда-либо прежде.
  • Кроме того, Gitpod очень прост: вы не поддерживаете свои проекты или рабочие области, используя громоздкие и сложные информационные панели. Вместо этого любая конфигурация безопасно хранится и имеет версию на GitHub.
  • Для редактирования кода вы можете использовать VS Code в браузере, VS Code на рабочем столе и использовать IDE JetBrains через JetBrains Gateway. сильный>

Заключительные замечания

В этой части серии

  1. Мы представили новую парадигму в Data Engineering.
  2. Мы выделили ключевые части архитектуры Data Lakehouse.
  3. Мы работали над настройкой облачной среды разработки с Gitpod, чтобы настроить и запустить нашу инфраструктуру.

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

Подключиться к Оазису



le-oasis — Обзор
Специалист по работе с данными, специалист по применению библиотек Python, таких как Numpy и Pandas, для разработки помеченных…github.com



Вам понравился этот отчет?



Махмуд Ойинлой
ученый по данным. Писатель. Любовник.www.buymeacoffee.com



💌 Оставьте свой отзыв

Оставайтесь с нами и следите за мной на Medium, чтобы не пропустить новые статьи из этой серии!