Инженерия данных 101
Как создать первый проект по инженерии данных? Поэтапная дорожная карта проекта
Создавайте проекты обработки данных с помощью этого поэтапного подхода для гарантированного успеха.
16 апреля 2022 года я написал подробную Дорожную карту того, как изучить инженерию данных как новичок. Дорожная карта имела большой успех. Однако имелся существенный разрыв.
Людям часто не удается сохранять последовательность, изучая так много разных технологий. Им не удается собрать это воедино. Дорожная карта должна была решить проблему сокращения концентрации внимания. Мы попытаемся изучить, как дорожная карта поэтапного проекта может устранить этот пробел.
В Дорожной карте разработки данных перечислено множество тем, которые необходимо осветить, и которые по-прежнему актуальны. Также там был отличный трекер для планирования тем и отслеживания прогресса. Но ему не хватало некоторых элементов структуры относительно того, что изучать в первую очередь и что реализовать в реальном проекте.
Кроме того, план отлично подходит для новичков, но как насчет людей, которые имеют некоторый опыт в этой области и готовы реализовать его на практике?
При переходе от ETL-разработчика к инженеру по обработке данных я столкнулся с аналогичной проблемой. Сейчас, в 2023 году, оглядываясь назад, я чувствую, что с другим подходом я бы добился гораздо большего.
Осторожно, это будет довольно длинное чтение, но будьте уверены, это сэкономит много времени во время обучения. Так что расслабьтесь, возьмите чашку кофе и читайте дальше….
- Начните с проекта
- Метод поэтапного проекта
— Определение бизнес-задачи
— Определение требований к данным
— Поэтапное проектирование проекта
— — Спринт1: Создание простого конвейера приема данных
— — Спринт 2: Добавление идемпотентности в конвейер
— — Спринт 3: Добавление модульного тестирования
— — Спринт 4: Создание несколько конвейеров на одних и тех же принципах
— — Спринт 5: Оркестрация и управление рабочими процессами
— — Спринт 6: Автоматизация конвейера данных
— — Спринт 7: Качество данных и Валидация
— — Спринт 8: Непрерывная интеграция и непрерывное развертывание
— — Спринт 9: Инфраструктура как код (IaC)
— — Спринт 10: Масштабируемость и оптимизация - Заключение
Начните с проекта
Итак, в реальном мире вам дадут месяцы, чтобы изучить все необходимое для решения проблемы? Вам почти всегда дадут набор задач или формулировок проблем. Потом вы проанализируете, что для этого нужно. Верно?
«Иди и рисуй», возможно, станет настоящей мантрой в реальном проекте. Но у всех нас есть проблемы с обучением.
Мы попали в цикл ада обучения.
Как часто вы чувствовали себя неуверенно даже после окончания курса? Вы прекрасно себя чувствуете, следуя инструкциям, но как только вам дают набор задач, вы начинаете откладывать дела на потом. Почему? Потому что вы попадаете в Долину Отчаяния и теряетесь в обучающем аду.
Позвольте мне представить метод дополнительных проектов и то, как он может решить проблему снижения мотивации.
Метод поэтапного проекта
Метод поэтапного проекта меняет идею выполнения проекта после того, как вы все изучили. Скорее, мы начинаем с проекта, разбиваем его на более мелкие управляемые задачи и изучаем концепции и технологии, необходимые для решения этой конкретной задачи и достижения целей.
Итак, почему тогда это называется инкрементным?
Что ж, как только основные цели достигнуты, вы вводите новые сложности и функциональные возможности. Вы можете связать это с созданием MVP для проверки идеи. Как только идея будет проверена, вы добавляете функциональные возможности и масштабируете.
Итак, в чем же преимущества этой модели?
- Вы копируете реальную рабочую среду
- Вы учитесь решать проблемы с самого начала
- Мгновенное удовлетворение от завершения проекта помогает.
- Увеличение сложности гарантирует, что у вас появится новая задача.
- Помогает преодолеть плато обучения и двигаться к мастерству.
Хорошо, это здорово, но можете ли вы объяснить это на реальном примере?
Конечно, давайте попробуем создать очень простой проект по инженерии данных, а затем рассмотрим, как можно добавить новые сложности. Но сначала позвольте мне раз и навсегда разрушить миф:
Анализ данных Twitter или Uber — это не настоящий проект по разработке данных.
Не поймите меня неправильно: это отличные темы для начала изучения сквозного конвейера проекта по инженерии данных. У Даршила Пармара есть несколько отличных проектов по инженерии данных для начинающих, посвященных тем же темам. Но это почти все.
Это может быть отличным первым шагом в поэтапном плане проекта, но его нельзя рекламировать в резюме как настоящий личный проект производственного уровня.
Если у вас есть несколько лет опыта, это становится еще более очевидным. Любой интервьюер может сказать, что у вас нет реального опыта работы над проектами. Вы по-прежнему можете пройти много собеседований, но если вы добавите немного больше сложности, вы сможете вывести свои личные проекты на новый уровень.
Вот несколько реальных проектов по работе с данными, которые можно добавить в свое резюме:
1. Миграция локальных данных в облако
2. Создание решения для анализа настроений
3. Внедрение управления основными данными
4. Разработка автоматизированной среды приема данных
5. Проектирование новая система хранилища данных для аналитики
6. Внедрение анализа данных в реальном времени с потоковой передачей данных
7. Создание наборов данных для сценариев использования ML/AI и разработки функций
Звучат ли они пугающе?
Давайте разберем этот процесс, чтобы упростить его. Вы можете найти больше подобных вариантов использования. Важно начать с одного варианта использования, а затем согласовать его со своими интересами.
Итак, начнем.
Определите бизнес-задачу
Для новичка достаточно знания технических деталей, но для пожилых людей знание предметной области почти так же важно. Попробуйте определить проект в знакомой вам сфере бизнеса. Создайте пример бизнес-сценария для определения вашего проекта.
Давайте попробуем определить его на примере банковского/кредитного бизнеса (поскольку мой опыт связан с кредитованием).
«Great Lending Company — это кредитная компания, пытающаяся обслуживать тех, кто не пользуется услугами банков. Следовательно, они предоставляют кредиты людям, которые не имеют доступа к нормальным банкам.
У этих людей может не быть хороших кредитных рейтингов, но им также нужен доступ к капиталу. Поскольку они не могут получить кредит где-либо еще, с них может взиматься более высокая премия.
Но кредиты будут иметь более высокий риск, и, поскольку их кредитный рейтинг невелик, вам нужно полагаться на больше данных, чтобы минимизировать риск. Однако вы не можете иметь физический бизнес с огромным количеством сотрудников, так как риск очень высок.
Итак, компания Great Lending Company хочет реализовать следующие бизнес-процессы:
- Моделирование рисков клиентов.
- Автоматизированный процесс выдачи кредита
- Снижение зависимости от ручного труда
- Минимизируйте кредитные потери за счет надлежащего обслуживания кредитов.
- Прогнозируйте неплательщиков и отслеживайте их платежи по EMI.
Определить требования к данным
Теперь давайте разберемся с требованиями к данным для поддержки бизнес-задачи. Чтобы обеспечить автоматическую обработку, им необходимо собрать много данных.
- Персональная информация клиента (структурированная)
- Кредитные данные клиентов (полуструктурированные)
- Информация о занятости клиента (структурированная)
- Местоположение по данным ГИС (полуструктурированные)
- Данные документа (неструктурированные)
Как инженер по данным в Great Lending Company, мы должны быть в состоянии достичь следующих целей:
- Прием всех вышеперечисленных типов данных
- Процесс приема должен быть автоматизирован
- Он должен быть масштабируемым и надежным, чтобы минимизировать потерю данных.
- Нам необходимо очистить и преобразовать данные для нужд бизнеса.
- Данные должны быть доступны для отчетности в рамках согласованного соглашения об уровне обслуживания.
Поэтапное проектирование:
Теперь, когда мы разбили постановку задачи на требования к данным, давайте разобьем их дальше и создадим поэтапный план проекта. Мы будем использовать принципы Agile, чтобы гарантировать, что мы приносим пользу за счет дополнительных итераций.
Спринт1: построение простого конвейера приема данных
Давайте начнем с создания очень простого конвейера данных для нашего бизнеса. Это своего рода состояние POC, и мы можем быстро создать MVP (минимально жизнеспособный продукт) конвейера данных для Great Lending Company.
Разобьем задачу на более мелкие задачи:
- Определите источники данных. В этом случае у нас есть 3 структурированных, 2 полуструктурированных и 1 неструктурированный источник данных. Предположим, что источниками являются 3 базы данных SQL, 1 база данных NoSQL, общий сетевой путь для документов и API для получения кредитных данных. Разнообразие источников будет определять наш инструмент/технологию приема данных.
- Выберите инструмент приема данных. Это очень важный компонент, и его необходимо проанализировать на основе существующих наборов навыков, требований источников данных и т. д. Однако для простоты обучения давайте возьмем базовый Python. /Scala для приема внутрь. Мы можем экспериментировать с различными инструментами в реальной среде проекта.
- Настройка инфраструктуры вручную: установка Python/Scala, любых зависимостей и любой необходимой инфраструктуры (общая папка/облачное хранилище/хранилище HFDS).
- Извлечение данных. Напишите код Python/Scala для подключения к различным источникам и извлечения данных из них.
- Загрузка в озеро данных. Создайте папку в формате RAW/Bronze в локальной файловой системе, облачном озере данных или хранилище HDFS. Это будет рассматриваться как Datalake. Подключитесь к папке и скопируйте данные из источника в озеро данных.
- Преобразование данных. Создайте папку silver/refined в своем озере данных. Это второй уровень преобразования данных. Реализуйте базовые преобразования, такие как дедупликация, очистка данных, объединение в единый источник истины и т. д.
- Загрузить в пункт назначения (склад/золотой уровень): Это уровень данных, готовый к представлению. В идеале данные загружаются в хранилище данных со схемой «Звезда»/киоском данных/хранилищем данных. Моделирование данных реализовано на этом уровне. Вы также можете использовать здесь относительно новые таблицы дельтовых озер/айсбергов.
Поздравляем!! вы построили свой самый первый конвейер данных полностью с нуля. Время для вашего любимого мороженого.
При создании этого вы можете узнать о различных инструментах ELT/ETL, например. Fivetran, Airbyte, Фабрика данных Azure. Вы узнаете о механизмах преобразования, таких как Spark и MapReduce.
Весь этот процесс не должен занять у вас больше недели. На второй неделе давайте добавим в конвейер еще несколько сложностей.
Спринт 2: Добавление идемпотентности в конвейер
Хорошо, вы только что сказали, что нужно добавить некоторую сложность, но затем вы вводите совершенно новый термин. Что вообще означает идемпотентность?
Процитирую Start Data Engineering:
Идемпотентность — это свойство определенных операций в математике и информатике, благодаря которому их можно применять многократно, не изменяя результат за пределами первоначального применения — википедия
Определяется как
f(f(x)) = f(x)
В контексте разработки данных это может означать, что: запуск конвейера данных несколько раз с одними и теми же входными данными всегда будет давать один и тот же результат».
- Внедрить отслеживание. Для распознавания и игнорирования повторяющихся операций можно использовать уникальный идентификатор или механизм отслеживания. Это гарантирует, что даже если операция будет повторена, она либо не будет запущена снова, либо даст те же результаты. Удалить — можно использовать запись, запись-аудит-публикацию или сравнение и объединение. Подробнее об этом позже.
- Дедупликация. Когда конвейер данных случайно перезапускается или перезапускается в случае сбоя, данные могут дублироваться. Убедитесь, что дублирование данных не происходит даже при повторном запуске. Шаблоны из пункта 1 помогают и здесь.
- Восстановление пропущенных данных. Конвейер должен иметь возможность наверстывать данные за пропущенные дни. Один из способов реализовать это — регистрировать то, что уже загружено, и загружать только новые данные, которые были созданы с тех пор.
- Данные обратного заполнения. Конвейеры данных должны быть параметризованы, чтобы в случае необходимости перезагрузки данных за определенные дни конвейеры могли делать то же самое без каких-либо проблем или без дублирования данных. Шаблоны из пункта 1 и вход в систему из пункта 3 могут помочь в этом.
Прочтите эту статью Дэниела Бича об идемпотентности в конвейере данных.
Теперь вы не только создали конвейер данных, но даже реализовали один из ключевых принципов проектирования конвейера данных. Пришло время расслабиться, сделать перерыв и с новыми силами перейти к следующему испытанию.
Спринт 3: Добавление модульного тестирования
Добавление модульных тестов в ваш конвейер добавляет огромную ценность. Это гарантирует, что вы не сломаете что-либо на производстве и не вызовете простоев в бизнесе.
- Написание тестируемого кода. Используйте лучшие практики программирования вместе с функциональным программированием, чтобы создавать небольшие фрагменты кода в виде функций. Меньшие модули кода обеспечивают возможность тестирования всех функций.
- Написание тестовых примеров. Определите различные тестовые примеры с высоким покрытием. Определите необработанные входные данные (образец), а также ожидаемые данные. Напишите тестовые примеры, соответствующие одному и тому же.
- Автоматическое тестирование. Используйте процесс CI/CD для автоматического выполнения кодов модульных тестов вместе с блокнотами.
Здесь вы можете узнать о различных средах модульного тестирования, например:
Спринт 4: Создание нескольких конвейеров по одним и тем же принципам
Часто для создания полноценной системы анализа данных требуется принять несколько таблиц. Один из способов сделать это — создать отдельные конвейеры для каждой таблицы или иметь несколько динамических конвейеров, которые могут читать несколько таблиц. В любом случае вам часто придется использовать один конвейер в качестве шаблона для создания нескольких конвейеров.
- Создание шаблонов конвейеров. Убедитесь, что все компоненты конвейера написаны по модульному принципу, чтобы можно было создавать шаблоны, которые можно повторно использовать для нескольких конвейеров.
- Управление зависимостями. Любая зависимость должна создаваться как независимые конфигурации, классы или методы, чтобы их можно было использовать в разных конвейерах.
Спринт 5: Оркестрация и управление рабочими процессами
Все конвейеры необходимо объединить в организованный рабочий процесс. Часто создается главный конвейер, который запускает различные дочерние конвейеры на основе критериев успеха/неудачи/завершения.
Оркестровка конвейеров представлена в направленном ациклическом графе (DAG). Вы можете создать DAG, используя инструменты с низким кодом/без кода или такие инструменты, как Airflow или Mage.
- Рабочий процесс с основными данными
- Зависимость между дочерними конвейерами
Спринт 6: Автоматизация конвейера данных
После того как ваши главные конвейеры готовы и протестированы, важно их автоматизировать.
- Планирование. Запланируйте конвейер на определенное время, чтобы обеспечить его автоматическое выполнение по мере необходимости.
- Мониторинг: Как только график будет запущен, возникнут сбои. Важно добавить надежный механизм оповещения в случае сбоя. Журналирование можно использовать для хранения сообщений об ошибках. Важно постоянно отслеживать работу конвейера, чтобы гарантировать, что они не выходят из строя или не повторяются вовремя.
- Автоматический повтор и повторная попытка. Повторный запуск конвейера может произойти несколькими способами. Один из них — когда инженер службы поддержки/дежурный инженер видит ошибку, анализирует основную причину, а затем решает перезапустить конвейеры. Другой способ — автоматизировать весь процесс повторного запуска. На основании сообщения об ошибке конвейер можно запустить повторно. Кроме того, можно создать специальный набор правил для автоматического повторного запуска конвейера в случае сбоя. Можно определить количество повторных попыток.
После 6-го спринта у вас уже есть качественный результат, в котором реализованы лучшие практики, а также проверено, чтобы убедиться, что он обеспечивает правильные результаты. Вам удалось создать все конвейеры, необходимые для полноценного аналитического решения, а также автоматизировать процесс загрузки данных. Теперь вы можете запускать конвейеры несколько раз, наблюдать за повторяющимися сбоями или находить закономерности в сбоях.
В следующих нескольких спринтах давайте попробуем добавить больше функциональности, чтобы гарантировать, что повторяющиеся сбои не повлияют на наши конвейеры.
Спринт7. Качество и проверка данных
Качество данных является важным аспектом обеспечения надежности данных. Предприятия будут использовать создаваемые нами информационные продукты только в том случае, если они смогут доверять данным и аналитической информации. Следовательно, важно внедрить систему качества данных в конвейер данных.
Вот несколько очень простых задач, которые вы можете выполнить для постепенного создания базовой структуры качества данных. Обратите внимание, что в продвинутом проекте есть множество нюансов, однако эти задачи знакомят с основными понятиями.
- Определите показатели и правила качества данных. Определите все проверки качества данных и правила, которым необходимо следовать. Некоторые правила проверки данных могут быть такими: номера телефонов должны состоять только из 10 цифр, идентификаторы электронной почты должны иметь формат [email protected], имя клиента не может быть нулевым и т. д.
Наряду с правилами качества данных нам необходимо определить Метрики качества данных тоже, например, точность адреса клиента должна составлять 90 %, более 5 % столбцов данных не могут иметь пустые значения и т. д. - Автоматическая проверка данных. В соответствии с правилами качества данных автоматические проверки должны быть написаны в коде. Эти проверки будут выполняться после загрузки данных или завершения преобразования данных и т. д. Такая автоматическая проверка данных обеспечивает целостность, согласованность и точность данных. Проверка данных также должна быть добавлена при извлечении данных из источника.
- Мониторинг качества данных и оповещения.Результаты автоматизированной проверки качества данных необходимо отслеживать для исправления данных. Должны быть предусмотрены оповещения, чтобы отмечать любую неудачную проверку DQ. Если в самом источнике возникают проблемы с данными, необходимо предупредить вышестоящие команды. Данные, не прошедшие проверку, можно записать в журналы ошибок и удалить из процесса загрузки данных.
Спринт 8: Непрерывная интеграция и непрерывное развертывание (CI/CD)
Контроль версий для совместной работы и CICD для Devops — чрезвычайно важный аспект разработки данных. CICD в конвейере данных считается частью Dataops, и вам необходимо ознакомиться с концепциями и хотя бы одним инструментом.
- Контроль версий и ветвление. Почти необходимо создавать версии кода с помощью любого инструмента управления версиями кода (GIT). Кроме того, правильная стратегия ветвления обеспечивает бесперебойное сотрудничество между разработчиками в команде.
Итак, добавьте все свои коды в GIT и используйте правильную стратегию ветвления для извлечения, внесения изменений и объединения ваших кодов. - Автоматизация сборки. Как только вы закончите вносить изменения, вам следует реализовать автоматизацию сборки, чтобы всякий раз, когда вы вносите какие-либо изменения, ваш проект собирался автоматически, и все модульные тесты выполнялись автоматически. Убедитесь, что на этом этапе также созданы все группы обеспечения доступности баз данных.
Используйте инструменты CICD, такие как Azure DevOps/GitHub Actions и т. д., для создания автоматических сборок для вашего конвейера данных. - Автоматическое развертывание. После того, как будет создано правильное ветвление и автоматическая сборка, вам необходимо рассмотреть возможность автоматического развертывания в средах более высокого уровня. В вашем личном проекте вы можете не беспокоиться о различных средах, но в реальном проекте вы будете разрабатывать и модульно тестировать коды в среде разработки. Но коды для всех других более высоких сред (тестирование/стадия/производство) необходимо автоматически развертывать с использованием конвейеров CICD. Конвейер должен быть достаточно интеллектуальным, чтобы обрабатывать любые конфигурации, специфичные для среды, с использованием переменных.
Спринт 9: Инфраструктура как код (IaC)
Важной частью конвейера CICD также является автоматическое развертывание всей инфраструктуры. Инфраструктура как код (IaC) — относительно новый, но необходимый навык для инженеров данных.
- Определить инфраструктуру как код. Все требования к инфраструктуре необходимо определить в виде кода/конфигурации с использованием файлов YML. Инструменты IaC можно использовать для автоматического развертывания инфраструктуры из файлов YML.
- Контроль версий для IaC. Как и обычный код и файлы конвейера, коды IaC или файлы конфигурации также необходимо отслеживать с помощью систем контроля версий, таких как GIT.
- Автоматизация подготовки: используйте такие инструменты, как Terraform, Ansible, Chef и т. д., для автоматизации подготовки различных инфраструктур, таких как сервер/виртуальная машина/программное обеспечение/облачные компоненты и т. д. Эти инструменты позволят читать файлы YML и подготавливать необходимые ниже.
На этом этапе у вас есть полный сквозной конвейер производственного уровня. Поэтапное создание всего этого проекта будет поддерживать вашу вовлеченность на протяжении всего учебного пути.
Но каков дальнейший путь?
Спринт 10: Масштабируемость и оптимизация
Любое программное обеспечение большую часть времени проводит в работе, а не в разработке. Как и в случае с любым другим программным обеспечением, создание любого конвейера данных занимает меньше месяцев, но в реальной производственной среде он работает годами.
После перевода конвейеров в производство возникают новые проблемы с данными, некоторые могут нуждаться в исправлениях, а некоторые могут нуждаться в переработке.
Однако одна проблема, которая почти наверняка возникнет, — это узкие места в производительности. Наши данные в разработке слишком чисты или часто даже не составляют доли размера производственных данных. Независимо от того, сколько проверок и оптимизации выполняется во время разработки и тестирования, производственные данные и инфраструктура неизбежно создают проблемы с производительностью.
Здесь вам пригодятся ваши навыки повышения производительности, оптимизации времени загрузки и масштабирования размеров данных. Следовательно, в качестве последнего шага начните добавлять оптимизацию и масштабируемость в ваш конвейер:
- Стратегии масштабирования. Планируйте обработку растущих объемов данных путем оптимизации масштабируемости вашего конвейера. Структура проекта должна быть модульной, чтобы ее можно было повторно использовать и масштабировать до любого размера данных.
- Настройка и оптимизация производительности. Выявляйте узкие места и оптимизируйте конвейер для повышения производительности.
- Управление кластером. Если вы используете свои конвейеры в кластере, в идеале кластер должен разворачиваться и работать только во время процесса загрузки и преобразования данных. Если задание не выполняется, вам следует приостановить работу кластера, чтобы сэкономить на выставлении счетов. В идеале вам следует создать автоматизированный процесс приостановки кластеров сразу после завершения процесса загрузки данных. Вы также можете попробовать выполнить другие действия по управлению кластером.
В двух словах
Таким образом, создавайте свои проекты по инжинирингу данных постепенно,
- Начните с конвейера MVP
- Добавьте идемпотентность, модульное тестирование, оркестровку.
- Автоматическая сборка кода и инфраструктуры
- Используйте CICD для автоматического развертывания
- Мониторьте, тестируйте и оптимизируйте
Этот практичный, но постепенный подход поможет вам изучить различные концепции по ходу дела. Небольшие постепенные шаги будут продолжать давать вам заряд адреналина всякий раз, когда вы вычеркиваете какую-либо задачу из списка.
Ссылка:
