Введение. Объемы и разнообразие данных в современном мире растут стремительно, и вместе с ними эволюционируют способы структурирования, хранения и обработки этих данных. За несколько десятилетий мы наблюдаем смену де-факто стандартов: форматы данных переходят от громоздких XML к легковесным JSON и потоковому JSON Lines, базы данных – от классических решений вроде MySQL к мощному PostgreSQL и его современным облачным инкарнациям вроде Supabase, а архитектуры хранения – от строгих Data Warehouse к гибким Data Lake и новейшим гибридным Data Lakehouse. В этом обзоре мы проследим развитие этих технологий, поймём причины смены поколений и рассмотрим современные тенденции в работе с данными. Статья рассчитана на технически подкованных читателей, интересующихся биографией технологий хранения данных и текущими трендами индустрии.
Когда-то XML (eXtensible Markup Language) был доминирующим форматом обмена данными. В эпоху раннего веба и SOA XML использовали повсеместно – от конфигурационных файлов до веб-сервисов. Его строго структурированный, иерархический формат с тегами позволял описывать сложные данные и валидировать их по схеме. Однако со временем недостатки XML стали очевидны: документы XML крупногабаритны из-за обилия служебных тегов, ихParsing требовал специальных парсеров, что усложняло и замедляло обработку. JSON (JavaScript Object Notation), появившийся в начале 2000-х, предложил более лёгкую и гибкую альтернативу. Формат JSON основан на понятии пар «ключ-значение» и требует гораздо меньше избыточных символов, благодаря чему записи получаются компактнее. В отличие от XML, для которого необходим XML-парсер, JSON можно распарсить штатными средствами JavaScript, практически на лету, что оказалось идеальным для веб-приложений.
JSON быстро завоевал популярность. Уже к 2010-м годам он стал фактически стандартом для веб-API и приложений: как отмечает AWS, JSON – язык-независимый формат обмена, понятный человеку и машине, и сегодня это наиболее гибкий и популярный вариант обмена данными между приложениями. Простота – ключевой фактор успеха JSON: несмотря на то, что XML появился раньше, именно лаконичный JSON покорил сердца разработчиков своей эффективностью и универсальной поддержкой. По словам экспертов, синтаксис XML слишком многословен и интерес к нему год от года снижается, тогда как JSON, изначально задуманный как «облегчённая» замена XML, прочно занял лидирующую позицию (хотя XML все еще используется в нишевых сценариях). JSON не поддерживает некоторых возможностей XML (например, встроенных комментариев или столь же строгих схем), но его достаточная простота и расширяемость (существуют отдельные спецификации схем JSON) сделали его выбором номер один для передачи структурированных данных в вебе.
Следующий шаг в эволюции форматов данных – JSON Lines (JSONL), также известный как newline-delimited JSON. Этот формат представляет собой просто множество JSON-объектов, записанных каждый с новой строки. Зачем это понадобилось? Дело в том, что обычный JSON-файл обычно представляет собой единый объект или массив, что затрудняет построчную обработку. JSONL же позволяет хранить или передавать поток записей, не обрамляя их единым корневым массивом – каждую запись можно обработать отдельно, не читая весь файл целиком. Такой подход оказался особенно полезен для больших объемов данных и потоковой обработки: например, лог-файлы, где каждая строка – самостоятельный JSON объект, или датасеты для машинного обучения, которые удобнее считывать и парсить итеративно. В ситуациях, когда нужно передать тысячи записей, разделенных новыми строками, формат JSON Lines выигрывает у монолитного JSON-массива по эффективности использования памяти и простоте парсинга. Кроме того, если несколько процессов или сервисов одновременно пишут данные в общий поток (например, по сети), использование разделителя newline позволяет избежать конфликтов – записи просто дописываются строка за строкой. Сегодня JSON Lines стал де-факто стандартом для логов и некоторых потоковых API, дополняя JSON там, где требуется обработка данных на лету и масштабируемость по объему.
Таким образом, эволюция форматов данных отражает общий тренд к упрощению и повышению эффективности. Мы отошли от тяжеловесного XML к легковесному JSON, который благодаря простоте и человекочитаемости стал незаменимым в веб-разработке. А формат JSONL развил идеи JSON дальше, адаптировав их к задачам больших данных и стриминга, где ценится возможность быстрого построчного чтения/записи. Несмотря на то, что XML все еще находит применение (например, в специфичных интеграционных решениях или там, где критична строгая схема), основным «языком данных» в современной разработке однозначно является JSON и его производные.
Не менее впечатляющие изменения произошли в мире систем управления базами данных (СУБД). В 2000-х годах типичным выбором для веб-приложений была связка MySQL – открытая реляционная СУБД, прославившаяся как часть классического стека LAMP. MySQL ценили за простоту в освоении, высокую производительность на простых операциях и сообщество. Однако с тех пор ландшафт значительно изменился. PostgreSQL, еще один открытый реляционный движок, долгое время считался «нишевым» или академичным, но к 2020-м вышел в лидеры благодаря богатству возможностей и надежности. По результатам опроса разработчиков Stack Overflow 2023, PostgreSQL стал самой популярной базой данных в мире, впервые обогнав MySQL по доле использования (45,6% опрошенных профессиональных разработчиков использовали PostgreSQL против 40,6% у MySQL). MySQL, долгие годы носивший титул «самой популярной открытой СУБД», уступил пальму первенства – PostgreSQL уверенно наращивает сообщество и популярность, тогда как популярность MySQL начала снижаться. Более того, PostgreSQL лидирует не только по факту использования, но и по показателям «любви» и «желания использовать» – его предпочитают и рекомендуют все больше разработчиков, в то время как интерес к MySQL стагнирует.
Почему так произошло? PostgreSQL изначально строился как «самая продвинутая открытая СУБД» – он строго следует стандартам SQL, поддерживает сложные запросы, транзакции, хранимые процедуры, оконные функции, CTE и множестводругих “адвандс”-фич, которых раньше не было в MySQL. Особенно важно в контексте современных требований, что PostgreSQL поддерживает JSON/B как тип данных, позволяя хранить и индексировать JSON-документы прямо в таблицах. Это сближает реляционную СУБД с миром документов – разработчики могут получать лучшее из обоих миров: надежность транзакций и SQL плюс гибкость схемы там, где нужно хранить полуструктурированные данные. MySQL лишь в более поздних версиях получил поддержку JSON-типа, и он все еще менее гибок в этом плане (ограниченные индексы и функции работы с JSON). Кроме того, PostgreSQL имеет расширяемую архитектуру: существует система плагинов-расширений (PostGIS для геоданных, pgVector для ML-векторных поисков, Foreign Data Wrappers для подключения внешних хранилищ и др.), позволяющих существенно расширять возможности БД без форков. MySQL же более монолитен: хотя у него модульная архитектура движков хранения, по сути почти все используют один InnoDB, и возможностей для сторонних расширений куда меньше. В результате за последние годы вокруг PostgreSQL сложилась бурно развивающаяся экосистема – многие облачные платформы предлагают DBaaS на базе Postgres. Как удачно отметили обозреватели, почти каждый новый сервис, предоставляющий облачную базу данных, выбирает именно Postgres: от Heroku в начале 2010-х до современных Supabase, Render, Fly.io и пр.. Сообщество PostgreSQL остается независимым (БД не принадлежит корпорации, в отличие от MySQL, контролируемого Oracle), что тоже привлекает многих, кто ценит открытую модель разработки.
Отдельно стоит поговорить о Supabase – ярком представителе нового поколения сервисов, которые строятся поверх PostgreSQL. Supabase называют «open-source Firebase»: это полноценная бэкенд-платформа, предоставляющая разработчику из коробки базу данных Postgres в облаке, RESTful API для нее, механизм авторазвертывания, встроенную аутентификацию пользователей и даже реактивные подписки на изменения данных (реализовано через PostgreSQL-публикации и WebSocket). По сути, Supabase превращает PostgreSQL в удобный конструктор приложений – и это крайне своевременная идея. Разработчики хотят фокусироваться на логике, а не на настройке БД, и Supabase предлагает им знакомую мощь SQL совместно с удобством облачного сервиса. То, что Supabase обрёл популярность, подтверждается исследованиями: опросы показывают высокий интерес к этому сервису у разработчиков, что неудивительно – PostgreSQL любим многими, а Supabase делает его использование ещё проще. В целом тренд такой: распространение PostgreSQL идёт рука об руку с появлением сервисов, упрощающих работу с ним (как коммерческих, так и с открытым кодом), и эта база данных становится своего рода «сердцем» современных приложений.
Конечно, мир баз данных не ограничивается реляционными СУБД. Параллельно с расцветом PostgreSQL, примерно с конца 2000-х, бурно развивалось движение NoSQL. Под лозунгом «Not Only SQL» появились системы хранения данных, которые отказались от привычной табличной модели в пользу иных подходов: ключ-значение (Redis, Memcached), документо-ориентированные базы (MongoDB, CouchDB), колоночные хранилища (Cassandra, HBase), графовые базы (Neo4j, JanusGraph) и др. Их цель – решить те проблемы, с которыми тяжело справляются традиционные СУБД: горизонтальное масштабирование на кластере из множества узлов, хранение больших объемов слабоструктурированных данных, гибкие схемы, высокое быстродействие при распределенных вычислениях. В эпоху веб-гигантов и «больших данных» NoSQL-решения стали крайне востребованы: например, соцсети использовали NoSQL для хранения социальных графов, интернет-магазины – для каталога товаров и сессий пользователей, аналитические платформы – для логов и событий. Ключевое различие – отсутствие жёсткой схемы и часто отказ от ACID-транзакций в пользу eventual consistency (приемлемой согласованности данных в распределенной среде). Это позволяло масштабировать базы практически без ограничений, добавляя новые узлы под рост нагрузки.
Однако, вопреки прогнозам некоторых энтузиастов, реляционные базы данных никуда не исчезли с появлением NoSQL. Практика показала, что NoSQL дополняет, а не вытесняет SQL во многих архитектурах. По данным опросов, почти половина разработчиков сегодня используют комбинацию традиционных реляционных БД и NoSQL-хранилищ одновременно. Лишь менее 8% работают исключительно с NoSQL, тогда как полностью на одних SQL-базах обходятся гораздо больше команд. Это означает, что в реальных проектах чаще всего применяется связка: реляционная СУБД для критичных транзакционных данных и сложных аналитических запросов, а NoSQL – для специализированных задач (кэширование с высокой скоростью в памяти, хранение сессий, полнотекстовый поиск, графовые связи и т.д.). Например, Redis часто стоит рядом с PostgreSQL в качестве высокоскоростного кэша, MongoDB может использоваться для гибкого хранения документов там, где схема сильно вариативна, ElasticSearch – для поиска по логам и текстам, и т.п. Многие NoSQL-системы сами по себе стали более «сговорчивыми» с миром SQL – появляются стандартизированные API (например, SQL-подобные запросы в Cassandra или Elastic). И наоборот, традиционные СУБД перенимают фишки NoSQL (как уже упомянутые JSONB в Postgres). Грань между двумя мирами несколько размывается, формируясь в новое понимание: полиглотное хранение данных, когда каждая подсистема применяется «по способностям». Эксперты отмечают, что разработчики устают от ограничений «ветеранов» (MySQL, Oracle, MSSQL) и всё чаще обращают внимание на новые решения – как среди NoSQL, так и среди современных SQL-движков. Популярность набирают и распределённые NewSQL-базы, и специальнизированные БД под AI/ML. Тем не менее, PostgreSQL на этом фоне выделяется как универсальный солдат: он остаётся самой любимой реляционной СУБД (минимум респондентов хочет от него отказаться), что объясняет и всплеск интереса к экосистеме вокруг него – в том числе и к Supabase как удобному входу в мир Postgres для новых проектов.
Последняя часть нашего путешествия – эволюция архитектур хранения и анализа данных. Традиционный Data Warehouse (DWH), или хранилище данных, возник еще в прошлом веке как решение для интеграции и агрегирования данных из разных источников с целью бизнес-аналитики. Классический DWH – это централизованная реляционная база (например, Oracle, Teradata, MS SQL Server или современные аналоги вроде Amazon Redshift, Google BigQuery, Snowflake), куда посредством процедур ETL регулярно загружаются данные из операционных систем компании. Хранилище строго структурировано по схеме, обычно заранее спроектированной (schema-on-write): данные приводятся к единому формату, очищаются и организуются в виде таблиц (часто звездообразная или снежинка-модель, разделение на факты и измерения). Преимущества такого подхода – консистентность и качество данных, высокое быстродействие SQL-запросов по заранее заданной схеме, что идеально подходит для отчетности, OLAP и BI-дашбордов. DWH стали основой принятия решений на основе данных в бизнесе, позволяя аналитикам получать единый «источник истины».
Однако, у классических хранилищ есть и недостатки. Они требовательны к ресурсам и дорого обходятся: нужно много пространства под дублирование данных, вычислительные ресурсы для предварительной трансформации, а масштабирование часто осложняется, так как хранение и вычисление тесно связаны (в традиционных архитектурах при росте данных приходится наращивать и CPU/память вместе со storage). Кроме того, DWH изначально рассчитаны на структурированные данные – таблицы, числа, категории. С наплывом нового типа информации (неструктурированные логи, тексты, изображения, данные веб-клика, сенсоров и пр.) хранилища испытывают затруднения. Загружать «сырые» неструктурированные данные в DWH не имеет смысла – сначала их нужно структурировать, а это далеко не всегда возможно или экономически оправдано. К 2010-м годам предприятия осознали, что помимо классического DWH им нужен иной подход для Big Data. Так родилась концепция Data Lake – «озера данных».
Data Lake – это хранилище необработанных данных во всей их разновидности. В противоположность принципу schema-on-write, озеро данных придерживается подхода schema-on-read: данные из различных источников сбрасываются в озеро в их исходном, сыром формате, без приведения к общей схеме. Файлы могут лежать в любом формате – структурированные CSV, JSON, Parquet, а также неструктурированные логи, изображения, бинарные блобы – все, что угодно. Озеро выступает как гигантский низкозатратный буфер: хранить можно годами и петабайтами, не думая о оптимизации под конкретные запросы. Исторически первые data lakes строились на базе Hadoop и распределенной файловой системы HDFS, на кластерах из десятков/сотен серверов. Сейчас все чаще используются облачные объекто-хранилища (Amazon S3, Azure Blob Storage, Google Cloud Storage), которые практически безгранично масштабируются и обходятся дешевле, чем содержание дорогих SQL-серверов. Важное преимущество озера – развязка хранения и вычислений: можно накопить сколько угодно данных, не тратясь сразу на мощности для их обработки, а при необходимости подключать различные движки (Spark, Presto, Flink и т.д.) для анализа поверх данных в озере. Data Lake стал ответом на вызовы эпохи Web 2.0 – лавину разнородной информации, которая хлынула в компании в конце 2000-х и 2010-х. Вместо того чтобы пытаться всунуть все в прокрустово ложе DWH, организации начали складировать все «как есть» в надежде, что потом это пригодится для data science, machine learning, детализации аналитики и т.п.
Безусловно, гибкость data lake – палка о двух концах. Отсутствие схемы и централизованного управления данными легко превращает озеро в болото (data swamp), где тонут ценность и смысл данных. Если в DWH данные качественно преобразуются при загрузке, то в озере ответственность переносится на этап чтения: каждый аналитик или исследователь данных сам интерпретирует сырье из озера. Это чревато несогласованностью, дублированием усилий и проблемами с качеством данных. Кроме того, традиционные BI-инструменты и бизнес-пользователи не могут напрямую работать с озером – нужен либо специалист по Big Data, либо перенос нужных данных из озера обратно в структурированное хранилище. По сути, организации часто были вынуждены поддерживать двойную инфраструктуру: и классический DWH для отчетности, и Data Lake для сырых больших данных, плюс процессы, связывающие одно с другим. Со временем стало понятно, что нужна новая архитектура, сочетающая достоинства обоих подходов – так появилась концепция Data Lakehouse.
Data Lakehouse – относительно новое слово в управлении данными. Lakehouse стремится объединить лучшие черты озера и хранилища в единой архитектуре. От Data Lake ему достается способность хранить любые типы данных дешево и масштабируемо (объектное облачное хранение, разделение вычислений и хранения, гранично-вместительная среда для сырых данных). От Data Warehouse – надежность, производительность и управляемость: lakehouse предполагает наличие метаданных и схем поверх данных, поддержку транзакционности и механизмов обеспечения качества данных, что было слабым местом чистых озер. Проще говоря, Data Lakehouse – это озеро данных с бензином от хранилища: в нем можно выполнять быстрые SQL-запросы, хранить данные в формате, готовом для BI, но при этом не терять гибкости — вся необработанная информация продолжает лежать в том же хранилище и может использоваться для машинного обучения, ад-хок аналитики и т.д.
Сравнение основных характеристик классического Data Warehouse, Data Lake и современного Data Lakehouse. В классическом хранилище данных данные структурированы заранее и оптимизированы для SQL-аналитики, но плохо подходят для неструктурированных данных и требовательны к ресурсам. Озеро данных, наоборот, хранит все подряд без структуры, обеспечивая гибкость и низкую стоимость, но не гарантируя качества и быстрых запросов. Lakehouse объединяет эти подходы: хранение всех типов данных в едином озере, поверх которого реализованы схемы, индексы и транзакционность для ACID-свойств и быстрого доступа к данным аналитическими инструментами. Таким образом, уменьшается дублирование данных и инфраструктуры (нет необходимости вести отдельно озеро и склад – один lakehouse может закрыть оба потребности). Кроме того, lakehouse-платформы обычно поддерживают как batch-обработку, так и стриминг данных, тогда как традиционные DWH рассчитаны в основном на пакетные загрузки, а озера без дополнительных надстроек – на batch или ограниченный стриминг.
Концепция Lakehouse стала реализуемой благодаря ряду технологических достижений последнего десятилетия. Во-первых, появились форматы данных и движки, приближающие озеро к Warehouse: колонночный формат Parquet и подобные ему ввели более строгую организацию и схемы для файлов в озере, значительно повысив эффективность SQL-запросов по файлам. Во-вторых, такие проекты, как Delta Lake, Apache Hudi и Apache Iceberg, добавили уровень управления транзакциями для файлов в озере, фактически сделав возможными надежные вставки, обновления и удаление данных с гарантией ACID. К примеру, формат Delta Lake от Databricks хранит специальные транзакционные логи и метаданные, позволяющие проводить параллельные обновления данных в S3-хранилище без потери согласованности. Это устраняет одно из ключевых отличий озера от хранилища – отсутствие транзакционности – и «подтягивает» озеро данных до уровня надежности, присущего классическим СУБД. В-третьих, движки типа Apache Spark и Presto/Trino научились работать с данными в озере практически в интерактивном режиме, приближаясь по скорости выполнения SQL к специализированным DWH, особенно на современных форматах и с учётом кеширования. В-четвертых, сами облачные DWH двинулись навстречу озерам: например, Snowflake реализовал возможность читать JSON и Parquet из staging area, Redshift представил Spectrum для внешних данных, и т.д.. Происходит конвергенция: склад учится гибкости, озеро – порядку.
Разумеется, Data Lakehouse – ещё молодая концепция, и в её адрес звучит немало вопросов. Эксперты отмечают, что технология пока незрелая: нет такого богатства проверенных инструментов и лучших практик, как для DWH, и возможно потребуется еще несколько лет, прежде чем lakehouse полностью оправдает все обещания. Многие компании пока выстраивают lakehouse постепенно, не отказываясь от существующих озер и хранилищ одномоментно. Тем не менее, тренд очевиден: практически все ведущие игроки рынка данных поддерживают концепцию lakehouse или предлагают собственные реализации (Databricks Lakehouse Platform, Snowflake Универсальное хранилище, решения на базе Apache Iceberg/Delta Lake от AWS, Azure и GCP и т.д.). Data Lakehouse становится популярным путём модернизации инфраструктуры данных, позволяя организациям объединить хранилища и озера без “болезненного” отказа от существующих наработок. В перспективе, по мере взросления технологий, lakehouse может стать новым стандартом для аналитических платформ, способным удовлетворить сразу и традиционные BI-задачи, и запросы data science/ML из единого источника данных.
Прослеживая путь от XML к JSON, от MySQL к PostgreSQL и от Data Warehouse к Data Lakehouse, легко заметить общие мотивы развития технологий данных. Во-первых, движение к упрощению и открытости: более простые и гибкие форматы вытесняют сложные (JSON против XML), открытые и расширяемые системы побеждают монолитные (PostgreSQL против проприетарных СУБД), открытые форматы и движки на базе сообщества формируют основу для новых архитектур (lakehouse на базе открытых форматов данных). Во-вторых, рост требований к масштабируемости и разнообразию данных привёл к тому, что универсальность стала ключевым качеством успешной технологии. JSON смог представить данные практически любой структуры в человекочитаемом виде. PostgreSQL превратился из чисто реляционной базы в многофункциональную платформу, позволяющую работать и с JSON-документами, и с геоданными, и с машинным обучением (через расширения). Архитектура lakehouse объединяет ранее разрозненные подходы к хранению данных, стремясь обслуживать и структурированные, и неструктурированные данные под самые разные варианты нагрузок.
В-третьих, заметен сдвиг к сервисной модели и управляемым решениям. Вместо того чтобы вручную поддерживать XML-схемы или поднимать собственные кластеры баз данных, всё больше команд пользуются готовыми сервисами и облачными платформами. Тот же Supabase – показатель запроса на упрощение работы с базой данных; Snowflake и Databricks – пример стремления получить «аналитику как сервис» без забот о низкоуровневой инфраструктуре. Это вписывается в общую тенденцию: сфокусироваться на данных и их ценности, делегируя рутину по хранению/обработке управляющему ПО или провайдеру.
Наконец, все рассмотренные эволюционные переходы показывают, что экосистема data-технологий не стоит на месте. Там, где появляются новые задачи – будь то потоковая обработка логов, мировые масштабы пользовательских данных или требования гибко комбинировать разнородную информацию – появляются и новые решения. В начале 2020-х мы наблюдаем расцвет гибридных подходов: многомодальные СУБД, сочетающие SQL и NoSQL (например, поддержка графов и JSON в PostgreSQL, мультимодельные базы типа Azure Cosmos DB), интеграция аналитики и машинного обучения прямо в хранилищах (интеграция Python/SQL в СУБД, встроенные ML-функции). В сфере больших данных на горизонте новые вызовы – например, управление данными для генеративного ИИ, рост спроса на специализирированные векторные базы данных для хранения эмбеддингов. Возможно, именно они станут следующим витком истории.
Но как бы ни менялись инструменты, цель остаётся прежней: извлечь из данных максимальную пользу. И новые поколения технологий – от легковесных форматов до умных озер-хранилищ – дают специалистам всё более совершенные средства для достижения этой цели. Стоит ожидать, что тенденция к унификации, гибкости и интеллектуализации хранения данных продолжится. А значит, впереди нас ждет еще немало захватывающих глав в летописи технологий работы с данными.
Источники: Использованы открытые материалы и исследования, включая сравнения JSON и XML от AWS, обзоры по популярности СУБД (Stack Overflow Survey 2023), аналитические отчеты о сочетании SQL/NoSQL в индустрии, а также статьи IBM и других компаний по архитектурам Data Lake и Lakehouse. Эти источники отражают текущие тренды и мнения экспертов, послужившие основой для данного обзора.