На классических метасторах типа хайва только set location не решает проблему консистентного перехода набора таблиц в новое состояние для пользователей импалы. Все равно есть возможность увидеть неконсистентное промежуточное состояние, пусть окно и небольшое.
И где тут противоречие? У нас есть база данных как набор дельта таблиц. У нас есть транзакции которые модифицируют базу данных из одного консистентного состояния в другое. Мы не должны видеть промежуточные состояния транзакций, только состояние до и после. Транзакции в свою очередь это набор действий над определенными data items, которые по определению могут быть ограничены скоупом одной таблицы. Это все в рамках определений описанных тем же Бернштейном.
1) Про какое "ночное окно" может идти речь в крупных международных компаниях? Видимо тут какая-то больше локальная история.
2) Это работает с централизованной дата командой, но сложно представить как это будет работать в децентрализовынных командах, когда данные одной команды могут быть независимо быть использованы в пайплайнах другой в непредсказуемое время.
Уход от ответа и аргументы в стиле "про спарк ты фигню спорол" сложно воспринимать как конструктивный диалог. Я конечно попробую еще раз пояснить, но продолжать диалог в подобном подростковом стиле у меня нет желания.
1) Я задавал прямой вопрос "Какой из пунктов ACID накладывает подобное ограничение и что конкретно по этим пунктам нарушается?". Ответом были собственно пункты ACID, а не нарушения. Вот цитаты из публикации где описываются особенности ANSI SQL-92, тут прямо написано и от того же Бернштейна: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf
"A transaction groups a set of actions that transform the database from one consistent state to another" "Following [EGLT], this definition takes a broad interpretation of “data item”: it could be a table row, a page, an entire table, or a message on a queue." "ANSI SQL Isolation designers sought a definition that would admit many different implementations, not just locking"
Т.е. ACID по описанию Бернштейна не диктует сколько таблиц должна затрагивать транзакция. Она требует, чтобы любой набор операций объявленный как транзакция, обладал свойствами ACID. Если Delta таблицы определяют транзакцию в границах одной таблицы, она полностью выполняет требования ACID Бернштейна для этой транзакции. И ограничение в виде одной таблицы - это не нарушение ACID, а определение области видимости данных (data items) к которым имеет доступ планировщик.
2) "Про спарк ты фигню спорол - у delta lake атомарность достигается модификацией одного, единственного json, сколько там акшенов - пофиг."
Давайте внимательно почитаем что я там написал: "используя "нативный" спарк, мы еще и ограничены не только одной таблицей, но и одной action, ибо явных транзакций у нас нет"
И что вы пишете: "у delta lake атомарность достигается модификацией одного, единственного json, сколько там акшенов - пофиг"
Вы пишете про другое, видимо не разобравшись. На уровне delta table все верно "сколько там акшенов - пофиг" и на уровне delta table можно делать много чего в рамках разных операторов, лишь бы файл транзакционного лога был один. Однако я говорю про имплементацию этого коннектора в наиболее популярном туле обработки данных - Spark, более того, практически нативно интегрированного с delta tables так как вышли они по сути из одного источника и объединяются одной платформой от Databricks.
Именно в рамках Spark мы ограничены одной операцией (action), мы не можем сделать два write в разные таблицы (или даже в одну) в рамках одной интерактивной транзакции (BEGIN...COMMIT), так как в Spark нет такого интерфейса. Каждая запись это отдельный коммит / "json" в delta log. Если нужно сделать операции атомарными, приходится использовать MERGE, что отсылает на мои слова об ограничении текущего инструментария, что в Spark мы жесче ограничены чем просто работа с одной таблицей. И иногда подобная компоновка в рамках одного MERGE приводит к совсем нетривиальной логике.
Данные там хранятся исключительно в delta table (в OneLake), но sql-движок выступает в роли более сложного планировщика, обеспечивая "full multi-table ACID transaction support". Это говорит о том, что лимит одной таблицы - это ограничение реализации конкретного менеджера транзакций (как в Spark), а не ущербность формата или "маркетинговый шит".
"Fabric Data Warehouse is primarily developed with T-SQL, and shares a large surface area based on the SQL Database Engine, with full multi-table ACID transaction support, materialized views, functions, and stored procedures"
"Bulk loading of Fabric Data Warehouse can be accomplished via T-SQL and TDS connections, or via Spark, with data bulk written directly to the Delta tables."
Побуду немного адвокатом дьявола, ибо статья вызывает столько вопросов, что её даже комментировать не вижу смысла.
1) "Delta Lake от Linux Foundation"
Ну не, изначально это поделка бриксов и в 2019 году они его заопенсорсили. Так что мимо. https://www.databricks.com/blog/2019/04/24/open-sourcing-delta-lake.html "With the advent of Delta Lake, we are seeing Databricks customers building reliable data lakes effortlessly at scale. Now we are open sourcing the Delta Lake project for the broader community to benefit as well."
2) "ни одна надстройка над файликами ACID не поддерживает"
А давайте без страшных тайн, почему собственно ACID на уровне таблиц это не ACID, можете раскрыть мысль? Какой из пунктов ACID накладывает подобное ограничение и что конкретно по этим пунктам нарушается?
И вообще, а классическая транзакционная СУБД это не "надстрока над файликами"?
Я еще больше страшную вещь открою, используя "нативный" спарк, мы еще и ограничены не только одной таблицей, но и одной action, ибо явных транзакций у нас нет и ACID гарантии применяются только к действиям выполняемым в рамках одной операции на одной таблице. Но тем не менее, эти гарантии есть, и, разумеется, специфичные для OLAP инструментов.
Что происходит, когда многоработничество раскрывает работодатель? Сотрудника просят бросить другие источники дохода.
Вопрос, а почему раскрывает? Зачастую неэффективный сотрудник, качество работы которого примерно сопоставимо с 2 часами работы в день и не на связи с командой. Его просят не бросить другие источники дохода, а избавляются от него.
В IT можно работать на двух работах и укладываться в 8 часов.
Можно. Иногда. А что ты будешь делать, когда нельзя? Или когда вчера можно было, а этот месяц (или год) нельзя. И сразу на двух проектах. Или переоценил свои силы. Зрелище печальное в обе стороны, я видел это что на многих примерах.
Если твой труд измеряют по результатам, не важно, сколько у тебя работ.
Все так, у меня на проекте есть человек, который еще подрабатывает на одном проекте. Но работает так, что мне абсолютно пофиг где он и сколько еще работает и я даже готов прикрывать в критичный момент. Но он так работает не потому, что уделает работе 2 часа в день, это точно.
Но сейчас компании не умеют оценивать труд в IT, а с AI сотрудники добиваются крейсерской эффективности.
Вот уж точно, что AI позволяет проще создавать иллюзии крейсерской эффективности для компании. Но вот по факту тут речь о том, что надо искать компании которые не умеют правильно оценивать труд. Это да, работает. Иногда без последствий. Я видел целую команду которая адаптировалась работать понемногу для клиента и в команде все были довольны происходяшим. Откуда я знаю? Меня приглашали спасать этот проект для критичного клиента.
Две работы позволяют расти как разработчик в два раза быстрее.
Миф. А пять работ в пять раз быстрее? Если работать полноценно, то ты не успеваешь развиваться, сфокусирован на решение задач, быстро что то клепаешь через AI до конца часто не разбираясь до конца, нет времени рефлексировать и систематизировать. А если работать мало, то про какое развитие речь? Работай не по 2, а по 8 часов и внезапно будешь развиваться в 4 раза быстрее.
Про «Собеседовать стало проще». Тут скорее кандидатам стало собеседоваться проще. Как следствие, они больше работают с большим числом предложений. Отчасти поэтому компаниям приходится идти на сокращение цикла интервью, и стали появлятья one day offer и мемы про то, что «собеседуйте быстрее, к концу собеседования кандидат уже вырастает в цене». Так что теперь, чтобы получить одного сотрудника приходится проводить больше собеседований.
Я к этому отношусь проще. Сохраняю интересные книги по всем релевантным мне темам (аналитика, разработка, тестирование, ML, инфра и т.п.). Их дофига. Но когда надо что-то резко изучить или покопать по конкретной теме, вуаля, у меня есть сравнительно небольшая подборочка по нужной мне теме, которую реально пролистать за пару дней и разобрать наиболее интересные места. Ибо часть книг слегка треш когда на них посмотришь. Выручало не раз и никакой трагедии по поводу того что «о-божечки-я-не-читаю-книги-которые-скачиваю» не испытываю)
На классических метасторах типа хайва только set location не решает проблему консистентного перехода набора таблиц в новое состояние для пользователей импалы. Все равно есть возможность увидеть неконсистентное промежуточное состояние, пусть окно и небольшое.
И где тут противоречие? У нас есть база данных как набор дельта таблиц. У нас есть транзакции которые модифицируют базу данных из одного консистентного состояния в другое. Мы не должны видеть промежуточные состояния транзакций, только состояние до и после. Транзакции в свою очередь это набор действий над определенными data items, которые по определению могут быть ограничены скоупом одной таблицы. Это все в рамках определений описанных тем же Бернштейном.
Меня два момента смущают:
1) Про какое "ночное окно" может идти речь в крупных международных компаниях? Видимо тут какая-то больше локальная история.
2) Это работает с централизованной дата командой, но сложно представить как это будет работать в децентрализовынных командах, когда данные одной команды могут быть независимо быть использованы в пайплайнах другой в непредсказуемое время.
Уход от ответа и аргументы в стиле "про спарк ты фигню спорол" сложно воспринимать как конструктивный диалог. Я конечно попробую еще раз пояснить, но продолжать диалог в подобном подростковом стиле у меня нет желания.
1) Я задавал прямой вопрос "Какой из пунктов ACID накладывает подобное ограничение и что конкретно по этим пунктам нарушается?". Ответом были собственно пункты ACID, а не нарушения. Вот цитаты из публикации где описываются особенности ANSI SQL-92, тут прямо написано и от того же Бернштейна: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf
"A transaction groups a set of actions that transform the database from one consistent state to another"
"Following [EGLT], this definition takes a broad interpretation of “data item”: it could be a table row, a page, an entire table, or a message on a queue."
"ANSI SQL Isolation designers sought a definition that would admit many different implementations, not just locking"
Т.е. ACID по описанию Бернштейна не диктует сколько таблиц должна затрагивать транзакция. Она требует, чтобы любой набор операций объявленный как транзакция, обладал свойствами ACID. Если Delta таблицы определяют транзакцию в границах одной таблицы, она полностью выполняет требования ACID Бернштейна для этой транзакции. И ограничение в виде одной таблицы - это не нарушение ACID, а определение области видимости данных (data items) к которым имеет доступ планировщик.
2) "Про спарк ты фигню спорол - у delta lake атомарность достигается модификацией одного, единственного json, сколько там акшенов - пофиг."
Давайте внимательно почитаем что я там написал: "используя "нативный" спарк, мы еще и ограничены не только одной таблицей, но и одной action, ибо явных транзакций у нас нет"
И что вы пишете: "у delta lake атомарность достигается модификацией одного, единственного json, сколько там акшенов - пофиг"
Вы пишете про другое, видимо не разобравшись. На уровне delta table все верно "сколько там акшенов - пофиг" и на уровне delta table можно делать много чего в рамках разных операторов, лишь бы файл транзакционного лога был один. Однако я говорю про имплементацию этого коннектора в наиболее популярном туле обработки данных - Spark, более того, практически нативно интегрированного с delta tables так как вышли они по сути из одного источника и объединяются одной платформой от Databricks.
Именно в рамках Spark мы ограничены одной операцией (action), мы не можем сделать два write в разные таблицы (или даже в одну) в рамках одной интерактивной транзакции (BEGIN...COMMIT), так как в Spark нет такого интерфейса. Каждая запись это отдельный коммит / "json" в delta log. Если нужно сделать операции атомарными, приходится использовать MERGE, что отсылает на мои слова об ограничении текущего инструментария, что в Spark мы жесче ограничены чем просто работа с одной таблицей. И иногда подобная компоновка в рамках одного MERGE приводит к совсем нетривиальной логике.
3) Ну и посмотрите на имплементацию Microsoft Fabric https://learn.microsoft.com/en-us/fabric/data-warehouse/data-warehousing
Данные там хранятся исключительно в delta table (в OneLake), но sql-движок выступает в роли более сложного планировщика, обеспечивая "full multi-table ACID transaction support". Это говорит о том, что лимит одной таблицы - это ограничение реализации конкретного менеджера транзакций (как в Spark), а не ущербность формата или "маркетинговый шит".
"Fabric Data Warehouse is primarily developed with T-SQL, and shares a large surface area based on the SQL Database Engine, with full multi-table ACID transaction support, materialized views, functions, and stored procedures"
"Bulk loading of Fabric Data Warehouse can be accomplished via T-SQL and TDS connections, or via Spark, with data bulk written directly to the Delta tables."
Побуду немного адвокатом дьявола, ибо статья вызывает столько вопросов, что её даже комментировать не вижу смысла.
1) "Delta Lake от Linux Foundation"
Ну не, изначально это поделка бриксов и в 2019 году они его заопенсорсили. Так что мимо. https://www.databricks.com/blog/2019/04/24/open-sourcing-delta-lake.html "With the advent of Delta Lake, we are seeing Databricks customers building reliable data lakes effortlessly at scale. Now we are open sourcing the Delta Lake project for the broader community to benefit as well."
Плюс посмотрите кто контрибьютит в спецификацию формата, большинство явно сотрудники Databricks
https://github.com/delta-io/delta/commits/master/PROTOCOL.md
2) "ни одна надстройка над файликами ACID не поддерживает"
А давайте без страшных тайн, почему собственно ACID на уровне таблиц это не ACID, можете раскрыть мысль? Какой из пунктов ACID накладывает подобное ограничение и что конкретно по этим пунктам нарушается?
И вообще, а классическая транзакционная СУБД это не "надстрока над файликами"?
Я еще больше страшную вещь открою, используя "нативный" спарк, мы еще и ограничены не только одной таблицей, но и одной action, ибо явных транзакций у нас нет и ACID гарантии применяются только к действиям выполняемым в рамках одной операции на одной таблице. Но тем не менее, эти гарантии есть, и, разумеется, специфичные для OLAP инструментов.
Вопрос, а почему раскрывает? Зачастую неэффективный сотрудник, качество работы которого примерно сопоставимо с 2 часами работы в день и не на связи с командой. Его просят не бросить другие источники дохода, а избавляются от него.
Можно. Иногда. А что ты будешь делать, когда нельзя? Или когда вчера можно было, а этот месяц (или год) нельзя. И сразу на двух проектах. Или переоценил свои силы. Зрелище печальное в обе стороны, я видел это что на многих примерах.
Все так, у меня на проекте есть человек, который еще подрабатывает на одном проекте. Но работает так, что мне абсолютно пофиг где он и сколько еще работает и я даже готов прикрывать в критичный момент. Но он так работает не потому, что уделает работе 2 часа в день, это точно.
Вот уж точно, что AI позволяет проще создавать иллюзии крейсерской эффективности для компании. Но вот по факту тут речь о том, что надо искать компании которые не умеют правильно оценивать труд. Это да, работает. Иногда без последствий. Я видел целую команду которая адаптировалась работать понемногу для клиента и в команде все были довольны происходяшим. Откуда я знаю? Меня приглашали спасать этот проект для критичного клиента.
Миф. А пять работ в пять раз быстрее? Если работать полноценно, то ты не успеваешь развиваться, сфокусирован на решение задач, быстро что то клепаешь через AI до конца часто не разбираясь до конца, нет времени рефлексировать и систематизировать. А если работать мало, то про какое развитие речь? Работай не по 2, а по 8 часов и внезапно будешь развиваться в 4 раза быстрее.
Где в статье хоть слово про борьбу за миллисекунды? Про время тут говорят с погрешностью в несколько секунд. В целом кликбейт.
Напрашивается шаг 12: Сменить пол