Введение в инженерию данных
Предлагаю начать книгу с введения в тему Инженерии данных, которую мы раскроем в последующих частях, а именно с истории и нынешнего состояния данной области.
Затем я расскажу Вам о том, при каких обстоятельствах я познакомился с этой сферой. Вернемся в прошлое, а именно в 2003 год, когда инженерия данных еще только начинала набирать обороты, отследим путь ее развития вплоть до 20-х годов XXI века, когда она стала самой популярной темой в области работы с данными, а также поговорим о том, как и почему шумиха вокруг нее понемногу сошла на нет (спойлер: началась эпоха генеративного ИИ).
История инженерии данных
Термин инженерии данных появился не так уж и давно. Однако его история уходит глубокими корнями в прошлое и отсылает нас к достаточно известным концепциям. Когда я еще только начинал свой пусть в области работы с данными (это было в 2003 году), самыми «горячими» темами были BI, разработка DWH и ETL процессы. Именно их изучение и развитие привело к тому, что сегодня мы называем инженерией данных.
Формальной предпосылкой становления инженерии данных как отдельной дисциплины стал совершенно новый подход к работе с данными, появившийся в конце 2010 – х годов. Он обозначился не внезапно, а развивался постепенно, начиная с момента появления таких традиционных понятий, как SQL и модели Кимбалла, и заканчивая более сложными системами и архитектурами.
Плавному перехода от классических моделей хранилищ данных к невиданным до того времени решений в области данных способствовали инновации в сфере MPP и облачных вычислений. Технологии наподобие MapReduce, Hadoop, а также облачные сервисы (AWS) значительно расширили возможности обработки и хранения данных, став началом эры беспрецедентной масштабируемости и доступности информации.
С течением времени менялась и роль дата-инженеров. Если раньше эти специалисты занимались исключительно BI решениям, то сегодня они принимают непосредственное участие в создании сложнейших современных стеков данных. Эта эволюция ознаменовала собой переход от эры Big Data к более сложносочиненной сфере инженерии данных, о чем подробно говорится в статье Максима Бошемина под названием «Восхождение дата-инженера» (“The Rise of the Data Engineer”).
Каждый новый этап развития, начиная с появления SQL и заканчивая современными облачными экосистемами, сформировал динамичный и многогранный мир инженерии данных таким, каким мы знаем его сегодня.
Инженерия данных сегодня
Понимание нынешнего состояния инженерии данных так же важно, и как знание истории ее развития. В этом разделе мы поговорим о последних трендах и инновациях, определяющих состояние изучаемой области сегодня. Изучим методологии и технологии, навсегда изменившие облик одной из самых интересных сфер в мире данных.
2022 и 2023 годы были решающими в плане определения направления развития инженерии данных. В это время появились инновационные декларативные подходы в работе с данными, а также новые методики в области метаданных. Заметных успехов добился язык программирования Rust, бросивший вызов традиционным фреймворкам. Бурный рост искусственного интеллекта, развитие векторных баз данных, а также технологий, гарантирующих конфиденциальность данных и многое другое – все это также приходится на эти два года.
Умение ориентироваться в современном ландшафте инженерии данных очень важно. По мере углубления в эту тему мы убедимся в том, что современный стек данных оказывает огромное влияние на моделирование данных, особенно в сложных корпоративных средах. Поговорим и о динамичном ландшафте MDS и растущей популярности открытых стандартов, а также дефрагментированных стеков.
Основные вызовы современной инженерии данных
В мире инженерии данных, как и в любой другой области, существуют трудности и вызовы, разрешение которых поможет раскрыть весь потенциал данных, имеющих ключевое значение для принятия обоснованных решений. Этот раздел посвящен трудностям, с которыми дата-инженерам приходится сталкиваться ежедневно.
В основе всех этих проблем и трудностей лежит жизненный цикл инженерии данных - путь от сбора данных до получения ценной информации на их основе. На каждом этапе данного процесса есть свои сложности и задачи - от обеспечения качества и согласованности данных до получения важных инсайтов, необходимых для принятия стратегически важных решений. Мы рассмотрим все эти этапы и их болевые точки, а также предложим эффективные способы их преодоления.
Еще один аспект, который мы изучаем, - это пирамида результатов работы, которая отображает функции и результаты деятельности в области инженерии данных. Эта структура помогает понять, как конкретные задачи (от создания инфраструктуры данных до обеспечения доступа к ним) способствуют достижению общей цели – формированию критически важных инсайтов. Мы рассмотрим то, как можно оптимизировать наш подход к решению этих задач, сбалансировать использование инструментов и ресурсов для достижения наилучших результатов.
Наконец, мы рассмотрим жизненный цикл инженерии данных (Data Engineering Lifecycle), в рамках которого особое внимание уделим процессу реализации проекта инженерии данных. Такой комплексный взгляд поможет нам выявить и решить проблемы по всем основным направлениям, включая поиск, хранение, передачу, преобразование и использование данных.
Как я познакомился с инженерией данных
Сравним историю развития инженерии данных с моим личным опытом работы в этой области.
С чего все началось
Область инженерии данных - это термин, который появился сравнительно недавно. В 2003 году, когда я начинал свою карьеру, его еще не было. Тогда это называлось бизнес-аналитикой. Сильно ли это отличалось от того, что есть и сегодня? И да, и нет.
В те времена основное внимание уделялось бизнес-логике, приносящей пользу пользователю, способы получения информации были менее сложными. Обычно для работы с данными мы выбирали одного из самых популярных поставщиков - Oracle, SAP или Microsoft.
Для ежедневного перевода данных из исходные БД в хранилища данных Вы добавили триггеры и столбцы даты. У нас же для быстрого и точного представления данных на регулярной основе было ODS (Operational Data Store), а также ядро и карты данных. Для обработки огромных SQL-запросов, содержащих обширную бизнес-логику, и сохранения их в быстро извлекаемых таблицах мы использовали материализованные представления.
Для визуализации данных мы использовали OBIEE, SAP BO и другие BI-инструменты. Дашбордов еще не было, но уже тогда мы умели отправлять достаточно информативные отчеты по электронной почте! Процесс сбора данных воедине и их оформления в читабельный PDF можно было сравнить со сборкой конструктора LEGO =).
Мы занимались автоматизацией с помощью сценариев bash, PL/SQL, T-SQL и всего того, что было доступно в то время. В некотором смысле это были зачатки оркестратора для последовательного запуска нужных задач. Мы даже называли хранимые процедуры i<something>, поскольку считали, что процедуры настолько прогрессивны, что обладают особым интеллектом.
В то время я еще только знакомился с такими терминами, как оперативное хранилище данных, представления, витрины данных и многими другими. С моими коллегами мы часто обсуждали то, как как можно получить доступ к данным и извлечь из них полезные инсайты. Можем ли мы получить доступ к источнику напрямую? Только один раз? Можем ли мы экспортировать его в Excel? Руководители компании постоянно подкидывали нам новые задачи и спрашивали, как мы можем получить достоверные данные и т.д.
Что мы имеем сегодня
Но все чаще я замечаю, что большинство задач, инструментов и стратегий решают те же самые задачи, что и 20 лет назад. Конечно, тогда они назывались по-другому, но по сути были очень похожи на то, что мы имеем сегодня.
При этом я замечаю, что понемногу мы отдаляемся от основ. В те времена мы тратили все свое время на моделирование данных или размышления об архитектуре данных, тогда как сегодня речь идет только о том, как можно объединить как можно больше инструментов.
Конечно, сейчас другие времена, но забывать об основах не стоит.
История, нынешнее состояние и проблемы инженерии данных
Понимание истории инженерии данных и ее современного состояния закладывают фундамент для изучения конвергентной эволюции и проектирования паттернов.
История и нынешнее состояние инженерии данных
Чтобы подготовить почву для знакомства с паттернами проектирования инженерии данных, давайте обсудим ее состояние на момент написания этой книги, историю развития, а также общие проблемы, с которыми мы сталкиваемся сегодня.
История инженерии данных
Об инженерии данных написано много, но как давно она существует и откуда вообще взялась?
Когда я начинал свою карьеру в качестве компьютерного ученого в 2003 году, таких понятий, как инженерия данных, Big Data, Data Science и так далее просто не существовало. В те времена в Швейцарии все это мы называли ВI , созданием DWH или разработкой ETL процессов.
Так когда же зародилась инженерия данных? Я отчетливо помню, как в марте 2018 года я выпустил свою первую вирусную статью под названием Инженерия данных или ближайшее будущее DWH. С тех пор новые технологии и концепты инженерии данных появляются чуть ли не каждую неделю …
в те времена 200 лайков – это ооочень много
Как мы к этому пришли?
Как уже говорилось ранее, когда я начинал свой профессиональный путь, создание хранилищ данных было в порядке вещей. Самыми обсуждаемыми темами в те времена были: противостояние Инмона и Кимбалла, сложности выбора оптимальной архитектуры и проблемы, которые можно было решить с помощью BI.
Но давайте будем последовательными.
DWH берут свое начало в 1980-х годах, когда слово «хранилище данных» было официально определено Биллом Инмоном и заложило теоретическую основу для принципов хранения данных в этом формате. Именно Билла Инмона очень часто называют отцом DWH.
SQL
1980-е годы также ознаменовались тем, что в это время официальным языком для работы с данными был признан SQL. В 1970 году SQL был предложен Эдгаром Коддом как способ абстрагироваться от сложностей механизмов хранения данных, позволяющий сосредоточиться только на их управлении.
С годами SQL видоизменялся, появились его подвиды, такие как Transact-SQL (T-SQL), используемый в Microsoft SQL Server, и Procedural Language/SQL (PL/SQL), используемый в Oracle Database. Эти разновидности расширили функциональность стандартного SQL, позволяя разработчикам писать процедурный код и так называемые хранимые процедуры, в которых можно задавать простые порядковые команды.
Размерное моделирование
Чуть позже, а именно в 1996 году, в книге Ральфа Кимбалла Инструментарий хранения и анализа данных были описаны основы размерного моделирования данных, того самого подхода, который мы используем сегодня.
От BI к Big Data
Я помню время, как появились MPP БД - вычислительные системы, использующие множество процессоров (или компьютеров) для одновременного выполнения вычислений. Они позволяли обрабатывать такие большие объемы данных, о каких мы даже и не подозревали. Это было время инженеров по бизнес-анализу, чья основная задача заключалась в управлении новыми большими хранилищами данных и Big Data.
В 2000-х годах лопнул «пузырь доткомов», положив начало развитию технологических титанов, которых мы знаем сегодня. Речь идет о Yahoo, Google и Amazon. Но по мере технологического прогресса усложняли и вызовы. Доступные базы данных переставали справляться с новыми задачами. Нужно было что-то принципиально другое.
MapReduce и Hadoop
Так появились MapReduce и Hadoop. В начале 2000-х годов на первый план вышла компания Google, такая же амбициозная, как и сегодня. На свет появились целых 2 статьи, наделавших много шума – Основные принципы построения Google File System (2003 г.) и Основные принципы MapReduce (2004 год).
Это был первый проект, ознаменовавший эру Big Data. Чтобы не отставать от своего главного конкурента, компания Yahoo в 2006 году представила широкой публике распределенную файловую систему Hadoop - набор прогрессивных на тот момент инструментов для инженеров, работающих с Big Data:
- Hadoop Common: по сути, что это основные библиотеки и утилиты Hadoop, основа, которая обеспечивает бесперебойную связь и слаженную работу всех компонентов платформы.
- Hadoop Distributed File System (HDFS): Огромное хранилище Hadoop распределяет большие массивы данных по сети машин, обеспечивая быстрый доступ и надежное резервное копирование данных благодаря их репликации.
- Hadoop YARN: маэстро управления ресурсами который гармонично распределяет ресурсы кластера и гарантирует то, что каждая задача получит столько ресурсов, сколько необходимо для ее решения.
- Hadoop MapReduce: мозг параллельной обработки данных, разбивающий массивные задачи на управляемые фрагменты, одновременно обрабатывает их, а затем объединяет полученные результаты воедино.
Именно тогда усложнилась задача BI-инженеров и первых инженеры по Big Data - они должны были разбираться не только в традиционных реляционных базах данных, но и в новых файловых системах с открытым исходным кодом. Таким образом, они прошли сложный и при этом увлекательный путь от моделирования данных до разработки ПО, а также освоили Hive и Spark, значительно расширив круг своих компетенций.
Облачная революция
А потом появились «облака». Помните, как Amazon анонсировала AWS? Тогда казалось, что это фантастика. Google Cloud и Microsoft Azure не отставали и изобретали свои решения. Ситуация на рынке поменялась кардинальным образом – компаниям больше не нужно было тратиться на собственное оборудования, ведь теперь все можно было сделать в облаке.
В начале 2010-х годов появились новые революционные технологии - от Amazon Redshift до Snowflake. Теперь любая компания, большая или маленькая, могла позволить себе совершенно одинаковые мощнейшие инструменты работы с данными. Это была первая волна открытого исходного кода в области разработки данных:
- Оркестрация с помощью Airflow (2014)
- Superset - первый open-source BI инструмент (2015)
- Преобразование данных с помощью dbt (2016)
Появление инженерии данных
Именно тогда появился «инженер по работе с большими данными». А поскольку в то время все данные казались нам «большими», мы со временем переименовали его просто в «дата-инженера».
В 2017 году Максим Бошемин, создавший к тому времени Airflow и Superset , опубликовал свой бестселлер под названием «Восхождение дата-инженера» ("Rise of the Data Engineer"), в котором впервые определил, что такое инженерия данных и объяснил переход от бизнес-аналитики к принципиально новой области. Позже, в январе 2018 года, он обозначил основы и паттены ИД и описал Функциональную инженерию данных .
Позднее все это переросло в современный стек данных (Modern Data Stack, MDS), или Open Data Stack (ODS) (если Вы используете открытый исходный код).
Нынешнее состояние инженерии данных
Итак, Вы убедились в том, что по мере своего развития инженерии данных претерпела множество транформаций. Да и сегодня данная область не стоит на месте – появляются новые профессии, инструменты и методологии для решения возникающих проблем. В этой части мы как раз и рассмотрим все эти изменения, постараемся понять настоящее инженерии данных, а также заглянем в ее будущее.
Основные тренды
Ниже представлен перечень тенденций в развитии ИД, обозначившиеся за последние два года, а также интересные цитаты моих коллег. Надеюсь, это поможет нам приоткрыть дверь в будущее инженерии данных.
2022 год
- Преобладание декларативного подхода различных областях, от «кода как инфраструктуры» Kubernetes до «оркестровки как кода» и «интеграции как кода». Данный подход лежит в основе развития семантического слоя - декларативной стратегии определения метрик, а также всех других направлений;
- Появление интересных тенденций в области метаданных, ориентированных на каталогизацию данных, их историю и обнаружение;
- Возросшая популярность Rust – языка программирования, известного своей надежностью и производительностью при работе с Big Data. Поясним, что сравнивать Rust с Apache Spark - все равно, что сравнивать яблоки с апельсинами (в данном случае акцент делаем на фреймворки типа Ballista - Arrow-Rust). Вдохновленная Spark, Ballista предлагает такие преимущества, как детерминированное использование памяти, превосходная эффективность использования памяти (иногда до 10 раз меньше, чем у Spark), а также возможность обработки большего объема данных на одном узле за счет снижения накладных расходов на распределенные вычисления;
- С ростом требований к конфиденциальности данных, включая GDPR и CCPA, предприятия стали уделять больше внимания безопасности данных.
2023 год
- Благодаря признанию потенциальной возможности потери контроля с помощью Modern Data Stack моделирование данных пережило «эпоху Ренессанса». Однако имейте в виду, что использование MDS сопряжено с серьезными трудностями, особенно в масштабах предприятия.
- Технологии ИИ, особенно генеративные модели ИИ, такие как ChatGPT, продвинулись от хайпового понятия к применению на практике. Широкое признание получили векторные базы данных, такие как Pinecone и Qdrant, ставшие главными конкурентами традиционных БД, а также более современные решения, такие как DuckDB.
- Популярность набирает дефрагментация, в частности "Open Data Stack". Parquet становится основным форматом файлов, а Iceberg и Delta – ключевыми форматами таблиц. Стремительно развивается и семантический слой, упорядочивая определения метрик в YAML.
Мнения других специалистов
Выдержки из "State of Data Engineering 2023":
- “Экономический спад, похоже, повлиял на спрос на специалистов по работе с данными. Однако технологии с открытым исходным кодом по-прежнему популярны. Скорее всего, они будут развиваться и дальше, даже в условиях экономического спада”
- “В области озер данных обозначилось четкое разграничение между хранилищами и механизмами обработки запросов и вычислений. Особого внимания заслуживает сотрудничество Snowflake с S3-совместимыми решениями для хранения данных”
- “В управлении метаданными лидерами стали Apache Hudi, Apache Iceberg и Delta Lake - решения с открытым исходным кодом”
- “За счет единогласного признания преимуществ git-подобного версионирования данных на первый план вырвался lakeFS. Все более востребованными становятся аналитические механизмы на базе Apache Arrow, такие как Arrow Datafusion и InfluxD”.
- “Мы стали свидетелями нетривиальных событий, таких как покупка IBM компании DataBand. Кроме того, стремительно возрастает популярность генеративного ИИ, оказывающего серьезное влияние на Data Science и аналитику данных”
Выдержки из "Modern Transactional Stack":
- “Транзакционные базы данных по-прежнему являются идеальным решением для проектирования приложений. Появились эффективные решения, призванные обеспечить управление состоянием транзакций в огромных распределенных приложениях, которые можно разделить на две категории: Оркестрация рабочих процессов и баз данных + рабочие процессы”.
- “Сближение подходов, ориентированных на рабочий процесс и базу данных, определило наше будущее, в котором все эти методы объединяться воедино и предложат нам наиболее оптимальное решение для современных транзакционных приложений”
Выдержки из "The Future of Data":
- “Практики программной инженерии по-прежнему востребованы среди команд, занимающихся данными, поскольку обеспечивают более эффективное управление сложными структурами данных.”
- “Мечта о едином семантическом слое так и осталась мечтой, компании борются за право предложить лучшие из возможных open-source инструментов. Тем не менее, фундаментальная проблема для команд, работающих с данными, - это по-прежнему понимание и поддержка бизнес-логики ”
Будущее
Ландшафт данных продолжает стремительно развиваться, сочетая в себе технологические достижения с новыми серьезными вызовами. По мере того как декларативные подходы приобретают все большую популярность, все более и более востребованными становятся технологии, гарантирующие конфиденциальность и безопасность данных. Будущее инженерии данных – это открытые стандарты и интегрированные подходы.
История инженерии данных - это свидетельство головокружительных инноваций. Переход от бизнес-аналитики до больших данных - это череда различных проблем и их решений, которой нет ни конца, ни края. Сейчас, когда я пишу эту книгу, широкую популярность приобретает ИИ, в частности генеративный ИИ. Но в любом случае, что бы ни происходило, все эти решения основаны на потребности в свежих, структурированных и проверенных данных.
В этой книге мы постараемся сосредоточиться на шаблонах, которые использовались в разные времена. Мы сосредоточимся на конвергентной эволюции, а также постараемся выделить основные паттерны проектирования.
