Postgres и The Lakehouse становятся одной из систем - вот что будет дальше
13 июня 2025 г.Архитектура современных систем данных претерпевает фундаментальный сдвиг.
Спросите разработчика, как они создают системы данных сегодня, и ответ все чаще выглядит следующим образом: Postgres для приложения, озеро для аналитики и науки о данных.
Postgres, давно предпочитаемый для транзакционных рабочих нагрузок, превратился в оперативную базу данных общего назначения. Он доверяет, гибко и глубоко расширяется, питает все, от транзакций клиентов и приложений CRUD, до мониторинга в реальном времени и функций продукта, поддерживаемых AI. Его экосистема выросла для поддержки аналитики в реальном времени (Временной масштаб), геопространственные данные (постгис), вектор и полнотекстовый поиск (PGVector и PGVectorScale) и многое другое.
В то же время, рост Open Lakehouse Technologies переопределяет то, как организации управляют и анализируют данные в масштабе. Дезагрегированное хранение, форматы открытых таблиц, такие как айсберг, структурированные каталоги данных и композиционные двигатели запросов, позволили анализировать данные масштаба Petabyte с точностью и контролем. Эта архитектура может предлагать управление, избежать блокировки поставщиков и по-прежнему обеспечивать гибкость команд данных при выборе инструментов.
Что поразительно, так это не только успех этих технологий индивидуально, но и то, как часто они сейчас развертываются вместе. Организациям все чаще необходимо поддерживать как рабочие нагрузки (работающие по базам данных), так и не операционные рабочие нагрузки (приводятся в действие озеро), часто используя данные из тех же источников-люди, машины, цифровые системы или агенты. Тем не менее, эти системы все еще рассматриваются в изоляции, часто принадлежащих различным командам, с слишком большим трением, чтобы заставить их работать вместе.
Мы считаем, что трение не должно существовать. На самом деле, мы думаем, что появляется новая, более согласованная архитектура: одна, которая относится к Postgres и Lakehouse не как к отдельным мирам, а как к отдельным слоям одной модульной системы, предназначенной для удовлетворения полного спектра операционных и аналитических потребностей.
Пределы дихотомии OLTP против Olap
Старый способ мышления о базах данных был прост: OLTP для транзакций, OLAP для анализа. Вы использовали Postgres для питания вашего приложения и отправили ночные задания ETL в хранилище данных для внутренних отчетов и панелей. Это традиционное различие хорошо послужило нам, когда заявки были проще, а внутренняя отчетность может жить на гораздо более медленной частоте. Но это уже не так.
Современные приложения являются тяжелыми данными, обращаются к клиентам и в режиме реального времени по дизайну. Они размывают линии между транзакционными и аналитическими.
- Финансовое приложение может запустить торговый механизм, который нуждается в миллисекундном доступе к портфелям клиентов, одновременно питая отчеты о рисках в режиме реального времени и внутренние панели панели.
- Приложение SaaS - это не просто хранение кликов - оно расчета метрик использования, запуска оповещений и обслуживание персонализированных моделей.
- Система промышленного мониторинга может приглашать десятки миллионов показаний датчиков в час, привлекать аномалий и логику предупреждения, а также архивные годы телеметрии для долгосрочной аналитики и обучения модели ИИ.
Эти варианты использования не являются выбросами - они быстро становятся нормой.
Мы все чаще видим более полезный раскол: операционные базы данных, которые продукты питания, и озеро, которые являются энергетическими организациями.
Тем не менее, хотя право собственности на эти типы систем разделяется-команды по производству продуктов, ответственные за операционные системы, питающие свои продукты, и команды данных, ответственные за управление системами Lakehouse в качестве организационных услуг-эти два все еще должны поговорить друг с другом. Им нужно работать над теми же данными и часто делиться основными схемами. Чем лучше они интегрируют и остаются синхронизацией, тем более устойчивой и способной становится система.
Архитектура оперативной медальонов
Один шаблон, который мы видимОперационная медальонная архитектураПолем Вдохновленные моделями Medallion, популяризированными в мире инженерии данных, этот шаблон также включает в себя бронзу, серебро и золотые слои-не только для внутренней аналитики, но и для питания систем, связанных с пользователем в реальном времени.
Вот как это выглядит:
- Бронзовый слой:Необработанные данные живут в файлах паркета или айсберга на AWS S3 или аналогичных недорогих бездонных системах хранения. Эти данные, как правило, неизменны, только для приложения и запрошены чем угодно: запросы, такие как AWS Athena, DuckDB, Trino, Clickhouse или Polars, или даже непосредственно из операционной базы данных, такой как Postgres.
- Оперативный серебряный слой:Очищенные, отфильтрованные, проверенные и дедуплицированные данные записываются в Postgres для Power Analytics, Dashboards или логику приложений продуктов, ориентированных на пользователя.
- Оперативный золотой слой:Предварительно агрегированные данные по данным серебра (например, материализованные представления Postgres или непрерывные агрегаты временного масштаба) служат опыту с низкой задержкой, высококонкурентной продукцией. Они обычно поддерживаются в базе данных, чтобы обеспечить согласованность между слоями серебра и золота.
Важно отметить, что каждый слой запрашивается, и это движение данных является двунаправленным. Вы можете извлечь необработанные или преобразованные данные из S3 непосредственно в Postgres (сродни плотно интегрированному обратному ETL). Вы можете свернуть агрегаты из айсберга в таблицы Postgres (по одному или постоянному вопросам против файлов айсберга из Postgres). Вы можете непрерывно синхронизировать полную схему или одну таблицу из базы данных до озера.
Так же, как бронзовые (или трансформированные) данные могут быть считываются со слоя хранения в Лейкхаусе на S3 в базу данных, серебро и золото в базе данных можно записать в эти форматы хранения в Лейкхаусе. Это позволяет избежать необходимости повторного внедрения идентичных трубопроводов в обеих системах, что придает сложность и риски.
Одна общая картина, которую мы наблюдали в приложениях, требующих свежих данных, - это писать из системы потоковой передачи вверх по течению, такой как Kafka или Kinesisпараллельнокак S3 (для строки, немодифицированные бронзовые данные), так и постгры (полагаясь на схемы базы данных и ограничения для проверки данных). Затем эти серебряные таблицы и последующие агрегаты золота в базе данных снова экспортируются в S3, поэтому команды данных теперь имеют доступ к «данным основной истины», которые были обслуживались клиентам.
Теперь каждая система поддерживает свое разделение проблем. Операционная база данных может запустить заблокированную - как для пользователей, так и для недружественных запросов - в то время как данные по -прежнему доступны как часть открытого Лейкхауса, где бы это ни было в организации.
Почему сейчас? Технические силы, управляющие сменой
Несколько разработок включают этот сдвиг от оперативных баз данных и озера от олицетворения к интегрированию.
Во -первых, айсберг созрел в стабильный и гибкий формат таблицы, который поддерживает эволюцию схемы, кислотные транзакции и эффективное уплотнение. Это позволяет нескольким вычислительным двигателям читать и писать в одних и тех же наборах данных - со слоями каталога, которые отслеживают метаданные и обеспечивают управление по всему стеку. Так же, как базы данных имели каталоги в их ядре, так что теперь делайте озеро.
Во -вторых, Postgres продолжал развиваться как платформа. С расширениями для столбчатого хранения, данных временных рядов, а также векторного и гибридного поиска-то, что мы строили в течение многих лет-Postgres теперь обслуживает множество продуктов, которые включают в себя аналитику в реальном времени и агентские рабочие процессы напрямую. И с появлением поддержки запроса данных S3 и айсберга непосредственно из Postgres, все больше возможно включить данные S3 непосредственно. Таким образом, Postgres больше не для транзакционных данных-с односторонним ETL/CDC в Лейкхаус-нотеперь выступает в качестве сервировочного уровня для продуктов, включающих как транзакционные, так и аналитические данныеПолем Это не просто уровень кэширования данных для предварительно вычисленных данных, но полноценная база данных SQL для дальнейших агрегаций, обогащения или соединения во время запроса.
В -третьих, разработчики ожидают композиции. Некоторые организации могут застрять в своих устаревших монолитных данных данных, но большинство разработчиков и ученых данных хотят гибко составлять свои собственные стеки, интегрируя знакомые инструменты способами, которые отражают потребности их приложения. Сдвиг в сторону открытых форматов и дезагрегированного хранилища соответствует этому мышлению. Так же, как и стремление к контролю, особенно в регулируемых отраслях или в том, в чем имеет значение суверенитет данных.
Используйте: рынок движется в направлении модульных, открытых, удобных для разработчиков архитектур.
Что будет дальше
Мы считаем, что будущее инфраструктуры данных будет формироваться систем, которые более глубоко интегрируют операционные и аналитические слои - системы, которые рассматривают Postgres и Lakehouse как две стороны одной монеты.
Это не произойдет через другой монолит. Он будет поступить из тщательных интерфейсов - постепенной синхронизации, общих каталогов, унифицированных поверхностей запросов - и от архитектурной философии, которая охватывает неоднородность, а не сражается с ней.
Мы работаем над чем -то новым в этом пространстве. Что-то, что основано на сильных сторонах Postgres и Aceberg, тесно интегрируется с существующими системами Lakehouse и облегчает создание систем данных с полным стеком с оперативной и аналитической точностью.
Речь идет не о использовании ETL для перемещения данных из устаревших систем в новые системы-речь идет о создании когерентной современной архитектуры данных, которая служит оперативным и не оперативным вариантам использования, как и.
Следите за обновлениями.
Оригинал