в дата центах тепло можно наружу вывести а на мкс никак и у научного сообщества нет идей как тепло рассеять. это главное препятствие ядерным реакторам в космосе, начиная с тэм.
к 2030 большая часть сотрудников в частном секторе будут ии агенты,жалкий триллион мягко говоря не та сумма что бы кого-то озаботить на фоне того что уже произошло в ит индустрии
я умею готовить и говорю как профессионал - mysql унылое ..., ни одна другая субд не будет дедлочить в тех ситуациях. даже самые унылые блокировочники ставят эксклюзивные локи ровно на те записи, какие меняют.
На сколько помню у Берштейна то что соответствовало ACID, то может называться транзакцией, т.е. ACID=транзакция.
а девочки рисующую рекламу из DuckDB читали Берштейна, они точно понимают о чем говорят или как у датабрика ? если я открою DeckDB в Dbeaver и параллельно моя программа будет менять в транзакции несколько таблиц ? наверняка же Dbeaver ничего не будет знать о внешних для него транзакциях и вычитает неконсистентную кашу.
мы одну и ту же статью читали ? в той что читал было обещание "должны были принести гарантии полноценных баз данных в S3" и на полном серьезе утверждается "это действительно работает. Delta Lake, Iceberg и Hudi обеспечивают надежные ACID-гарантии"
mysql разочаровал абсурдными локами при фуллскане, невинный апдейт/делит с предикатом по полю без индекса лочит нафиг всю таблицу, вызывая дедлоки и прочую хрень. на этом фоне даже вакум постгреса уже не столь уж угнетает.
ни в лейкак, ни в лейкхаусах нет самого понятия транзакция, соответственно "должны были принести гарантии полноценных баз данных в S3" пока далековато.
Еще одна жертва рекламы, так и не видевшая дата лейков. в лейках нет ACID, мало того там нет самих транзакций. там попросту не к чему ACID пристегнуть. конкретно у Databrisks с его Delta форматом таблица это просто папочка, в папочке json с метой. поменять два json в единый момент времени не возможно, соответственно транзакционно записать изменения в несколько таблиц Delta не может. да и Датабрикс мелким шрифтом везде уточняет, что у них атомарность в рамках одной таблички.
правда в том, что ты пытаешься обмануть читателя осознанно подсовывая расчеты на не свежем тесте, хорошо осознавая, что и тест и рассуждения фуфло. цифры из более свежего теста ведут к противоположному выводу, поэтому ты взял не свежий тест и скрыл от читателя. если бы перфоманс спринг был бы в самом деле на уровне мини фреймворков го, это был бы разгром го. то что делается парой аннотаций в спринге, на го потребует тонны кода и месяцы тестирования. со всеми вытекающими по стоимости.
очень скоро ии болванчики все изменят, нагенерят библиотек, обвязок и выиграет не тот язык где короче запись, а где больше рычажков тонкой настройки, возможности влезть в потроха и прочее.
у вас какое-то неверное представление о dbt. dbt это и есть та абстракция, которая скроет движок под низом. ваш аналитик правит dbt пайплайны в уже настроенном проекте dbt, что там под низом один лишь клик или spark он скорее всего и вникать не будет.
локальный spark врятли что-то к масштабируемости даст, у него просто запас прочности на тему джойнов сильно выше, ну и может побогаче SQL синтаксис. при этом пристегнуть локальный спарк к dbt это просто папочку распаковать и переменные среды выставить.
что касается airflow то я тут сетаю на колхоз. если что-то упало airflow пришлет нотификацию, в человеческом виде отобразит, где упало, покажет ретраи, затраченное время. если там начнет тыкать джун, все будет запротоколировано, все что он там наделал. а вам все это колхозить надо.
ну да, потому что airflow+dbt+spark гораздо проще, чем ваше нагромождение, которое совсем не факт, что завтра под нагрузкой продолжит работать (из-за джойнов в клике). airflow+dbt+spark же можно попросить поднять джуна и рассчитывать, что он часик-два посмотрит видосы и через часик-два поднимет. благо туториалов и видосов миллионы.
еще раз, когда вы произносите "airflow+dbt+spark", то джун сходу понимает всю архитектуру. а вот что там у вас, наверняка джун так просто не осилит. документации наверняка толком нет, кто там должен мониторить рефреши вьюшек, как наколхозжены нотификации, как перезапустить с нужного шага, там же тысячи вопросов будет.
плюсы в том, что схема рабочая и всем в индустрии знакомая и тот самый аналитик, без вас знает, что ему в dbt подправить надо, потому что он это делал на предыдущем месте.
это не логично подсовывать читателю невалидные цифры из раунда 22, прекрасно осознавая, что все расчеты на таких цифрах - вранье (цифры из раунда 23 приводят к ровно противоположным выводам). но вы можете кушать, что дают и много, много думать.
dbt супортит спарк (+click connector) точно также как все остальное, точно так же все на SQL можно строить. airflow это просто оркестратор, логика вся в dbt пайплайнах, джойн спарку в том же dbt аналитик должен описывать
в комитах видно, что поставили коннекшен пул 256, до этого дефолт был 10. вырубили логинг, вырубили ssl. на 10 коннекшенов не удивительно, что спринг в конце болтался, хотя наверняка это не все. тест лажа полная.
да, наверно соглашусь. в Fortunes тесте все в коннекшен пул базы упрется, VT не даст большого прироста. там еще какие-то тесты есть с json и текстовыми файлами. вот там VT может будет полезней.
а зачем ему допускать, мы же все видим что ты подогнал результат, взяв раунд 22, хотя актуальный раунд 23 привел бы ровно к противоположным выводам (не менее бредовым, учитывая абсурдность тестов).
в дата центах тепло можно наружу вывести а на мкс никак и у научного сообщества нет идей как тепло рассеять. это главное препятствие ядерным реакторам в космосе, начиная с тэм.
наркоман не слышал, что приходится воротить в ТЭМ, что бы охладить ядерный реактор.
к 2030 большая часть сотрудников в частном секторе будут ии агенты,жалкий триллион мягко говоря не та сумма что бы кого-то озаботить на фоне того что уже произошло в ит индустрии
перевод ужасен
я умею готовить и говорю как профессионал - mysql унылое ..., ни одна другая субд не будет дедлочить в тех ситуациях. даже самые унылые блокировочники ставят эксклюзивные локи ровно на те записи, какие меняют.
На сколько помню у Берштейна то что соответствовало ACID, то может называться транзакцией, т.е. ACID=транзакция.
а девочки рисующую рекламу из DuckDB читали Берштейна, они точно понимают о чем говорят или как у датабрика ? если я открою DeckDB в Dbeaver и параллельно моя программа будет менять в транзакции несколько таблиц ? наверняка же Dbeaver ничего не будет знать о внешних для него транзакциях и вычитает неконсистентную кашу.
мы одну и ту же статью читали ? в той что читал было обещание "должны были принести гарантии полноценных баз данных в S3" и на полном серьезе утверждается "это действительно работает. Delta Lake, Iceberg и Hudi обеспечивают надежные ACID-гарантии"
mysql разочаровал абсурдными локами при фуллскане, невинный апдейт/делит с предикатом по полю без индекса лочит нафиг всю таблицу, вызывая дедлоки и прочую хрень. на этом фоне даже вакум постгреса уже не столь уж угнетает.
ни в лейкак, ни в лейкхаусах нет самого понятия транзакция, соответственно "должны были принести гарантии полноценных баз данных в S3" пока далековато.
Еще одна жертва рекламы, так и не видевшая дата лейков. в лейках нет ACID, мало того там нет самих транзакций. там попросту не к чему ACID пристегнуть. конкретно у Databrisks с его Delta форматом таблица это просто папочка, в папочке json с метой. поменять два json в единый момент времени не возможно, соответственно транзакционно записать изменения в несколько таблиц Delta не может. да и Датабрикс мелким шрифтом везде уточняет, что у них атомарность в рамках одной таблички.
дальше читать уже не стал.
правда в том, что ты пытаешься обмануть читателя осознанно подсовывая расчеты на не свежем тесте, хорошо осознавая, что и тест и рассуждения фуфло. цифры из более свежего теста ведут к противоположному выводу, поэтому ты взял не свежий тест и скрыл от читателя.
если бы перфоманс спринг был бы в самом деле на уровне мини фреймворков го, это был бы разгром го. то что делается парой аннотаций в спринге, на го потребует тонны кода и месяцы тестирования. со всеми вытекающими по стоимости.
очень скоро ии болванчики все изменят, нагенерят библиотек, обвязок и выиграет не тот язык где короче запись, а где больше рычажков тонкой настройки, возможности влезть в потроха и прочее.
у вас какое-то неверное представление о dbt. dbt это и есть та абстракция, которая скроет движок под низом. ваш аналитик правит dbt пайплайны в уже настроенном проекте dbt, что там под низом один лишь клик или spark он скорее всего и вникать не будет.
локальный spark врятли что-то к масштабируемости даст, у него просто запас прочности на тему джойнов сильно выше, ну и может побогаче SQL синтаксис. при этом пристегнуть локальный спарк к dbt это просто папочку распаковать и переменные среды выставить.
что касается airflow то я тут сетаю на колхоз. если что-то упало airflow пришлет нотификацию, в человеческом виде отобразит, где упало, покажет ретраи, затраченное время. если там начнет тыкать джун, все будет запротоколировано, все что он там наделал.
а вам все это колхозить надо.
ну да, потому что airflow+dbt+spark гораздо проще, чем ваше нагромождение, которое совсем не факт, что завтра под нагрузкой продолжит работать (из-за джойнов в клике). airflow+dbt+spark же можно попросить поднять джуна и рассчитывать, что он часик-два посмотрит видосы и через часик-два поднимет. благо туториалов и видосов миллионы.
еще раз, когда вы произносите "airflow+dbt+spark", то джун сходу понимает всю архитектуру. а вот что там у вас, наверняка джун так просто не осилит. документации наверняка толком нет, кто там должен мониторить рефреши вьюшек, как наколхозжены нотификации, как перезапустить с нужного шага, там же тысячи вопросов будет.
плюсы в том, что схема рабочая и всем в индустрии знакомая и тот самый аналитик, без вас знает, что ему в dbt подправить надо, потому что он это делал на предыдущем месте.
это не логично подсовывать читателю невалидные цифры из раунда 22, прекрасно осознавая, что все расчеты на таких цифрах - вранье (цифры из раунда 23 приводят к ровно противоположным выводам).
но вы можете кушать, что дают и много, много думать.
dbt супортит спарк (+click connector) точно также как все остальное, точно так же все на SQL можно строить.
airflow это просто оркестратор, логика вся в dbt пайплайнах, джойн спарку в том же dbt аналитик должен описывать
цифры чудак выковыривал из 2023 года, потому что в 2024 жаве connection pool настроили и цифры уже ровно противоположные.
мутный подход, завтра понадобится чуть больше джойнов и все посыпется.
размеры крошечные, обычный airflow + спарк в режиме local мне кажется надежней было бы
в комитах видно, что поставили коннекшен пул 256, до этого дефолт был 10. вырубили логинг, вырубили ssl.
на 10 коннекшенов не удивительно, что спринг в конце болтался, хотя наверняка это не все. тест лажа полная.
да, наверно соглашусь. в Fortunes тесте все в коннекшен пул базы упрется, VT не даст большого прироста. там еще какие-то тесты есть с json и текстовыми файлами. вот там VT может будет полезней.
а зачем ему допускать, мы же все видим что ты подогнал результат, взяв раунд 22, хотя актуальный раунд 23 привел бы ровно к противоположным выводам (не менее бредовым, учитывая абсурдность тестов).