Каким же образом данные попадают к специалистам по данным и инженерам по машинному обучению?

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

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

Итак, что определяет инженера данных?

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

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

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

Просто сборка трубопроводов больше не является базой.

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

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

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

Итак, приступим.

Словарь инженеров данных

Для начала давайте перечислим некоторый словарный запас, который важен для DE.

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

Хранилище данных

Хранилища данных - это центральное место, куда могут пойти аналитики данных и профессионалы бизнес-аналитики, чтобы получить доступ ко всем своим данным. Есть много споров о хранилищах данных, витринах данных, Кимбалл против Инмона и о том, что все это означает.

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

Он отличается от базы данных приложения, потому что хранилища данных предназначены для работы с аналитическими запросами, а не с транзакционными запросами.

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

Кроме того, в современную эпоху многие системы данных, такие как BigQuery, Redshift и Snowflake, были разработаны специально для управления запросами в стиле хранилища данных. Это означает, что запросы, выполняющие большие объемы анализов, сумм и агрегатов, не часто ориентированы на транзакции.

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

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

Но перейдем к конвейерам данных.

Конвейеры данных и ETL

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

ETL относится к извлечению, преобразованию и загрузке (иногда это действительно может быть ELT), но мы не будем усложнять ситуацию.

ETL и конвейеры данных - это автоматизированные рабочие процессы, которые берут данные из точки A в точку B и по ходу трансформируют их, чтобы улучшить их способность к анализу.

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

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

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

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

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

После преобразования данные будут загружены в хранилище данных.

Группы DAG

DAG означает направленный ациклический график.

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

Вот где в игру вступают группы DAG.

Группы DAG всегда существовали в мире инженерии данных. Просто долгое время ими управляли с помощью комбинации CRON, некоторых специально созданных мета-баз данных и скриптов Bash, Python и PowerShell.

Это было очень беспорядочно и отнимало много времени.

Сегодня существует множество современных инструментов и библиотек, которые могут помочь в управлении вашими конвейерами ETL. К ним относятся Airflow, Luigi, petl и Dagster (для начала). Существуют десятки, если не сотни инструментов и библиотек, посвященных именно этой теме.

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

Таблицы фактов

А как насчет таблиц, в которые ETL загружают свои данные? Почему у них такие странные приставки?

Когда вы начнете работать с хранилищем данных, вы увидите префикс «fact_» или «f_», прикрепленный к таблице.

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

В общем, факты будут иметь какое-то агрегируемое значение, такое как общее количество купленных товаров или общая сумма продаж, а также так называемые dim_ ключи таблицы, такие как store_id, product_type_id и т. Д.

Факты обычно можно рассматривать как центральную таблицу.

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

Таблицы размеров

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

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

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

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

Это поможет вам описать и сгруппировать фактические данные.

О чем мы будем говорить дальше?

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

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

Спасибо.