Насколько знаю, monotonically_increasing_id работает в рамках dataframe.
Если у меня параллельно обрабатывается несколько dataframe и при айдишники из разных data frame не должны пересекаться и не должны пересекаться с тем, что уже persistent в таблице для измерения, то не очень понятно как это поможет.
Это всё, впрочем, лирика и можно прилепить к идентификатору номер батча или типа того.
Мысль была в том, что здесь не то, что ACID а какие-то тривиальные требования по логике требуют танцев с бубном ибо MPP by design (ни первичных ключей, ни identity columns ни прости хоспаде sequence).
Переход от параллельной заливке к выгребанию из kafka это типичный подход, да.

Спасибо, книгу полистаю, но отзывы не внушают энтузиазма.
Если кратко, большинство отзывов сводится к
https://www.amazon.com/Data-Lake-Architecture-Designing-Avoiding/dp/B01HN4JOPC Too high-level and generic, probably not for data professionals
К российской специфике не имею ни малейшего отношения. Просто вот такое ключевое требование.
Данные могут прийти кривые, запросить "прямые" не представляется возможным. А все косяки должны быть поправлены по итогу каждого дня.
Хотя теоретически любую правку можно рассматривать просто как новую порцию данных (пропустить ее через кафку и скормить загрузчику).
И если мы вспомним, что есть несколько пользователей, которые должны видеть согласованые данные, то становится интереснее.
Вот отсюда растут ноги у большинства проблем. Когда манагеры не в теме ведутся на маркетинговый буллщит а потом девелоперы не в теме начинают строить свои велосипеды.
А ведь на брошюрке и на презенташке всё было тааак хорошо!

Кстати, про девелоперов, по моим наблюдениям если человек с database primary skill перешел на java/scala/c#/etc то он может быть адекватным строителем datalake.
А если человек с primary skill java/scala/c#/etc начинет строить хранилища (не важно в hadoop или где еще) это звиздец.

PS.
Спарк на меня самого произвел приятное впечатление. Если надо ковыряться в semi-structured data или натягивать schema-on-read очень крутая вещь.
Оракл тут вообще не вариант. Но строить хранилища типа звезда с возможностью правок...

Интересно как они допилили PG учитывая что greenplum позволяет выбирать между column oriented storage and row oriented storage.
https://docs.greenplum.org/5280/ref_guide/sql_commands/CREATE_TABLE.html ORIENTATION — Set to column for column-oriented storage, or row (the default) for row-oriented storage. This option is only valid if APPENDONLY=TRUE. Heap-storage tables can only be row-oriented.Но больше меня беспокоит тот же вопрос - насколько большие хранилища типа звезда (чтоб сверху можно было построить OLAP куб) успешно работают в greenplum.

Смотрим в популярность в stackoverflow.com
Есть опасения, что можно остаться со своей проблемой один на один.
Или у greenplum есть vendor support и/или крепкое комьюнити?

Валерий,

Вместо попыток обосновать что pricing policy у Оракла единственно верное без минимального знания альтернатив

Можно просто почитать
https://aws.amazon.com/redshift/pricing/ With Amazon Redshift, you can start small at $0.25 per hour and scale up to petabytes of data and thousands of concurrent users. Choose what is right for your business needs, with the ability to grow storage without over-provisioning compute or storage. With provisioned Amazon Redshift, you can choose On-Demand Instances and pay for your database by the hour with no long-term commitments or upfront fees, or choose Reserved Instances for additional savings. Alternatively, Amazon Redshift Serverless (preview) allows you to pay for usage by automatically starting up, shutting down, and scaling capacity up or down based on your application's needs, so you pay only for capacity consumed while processing the workload.