Грокс
Anthropic привлёк $65 млрд рамках финансирования серии H при оценке после получения инвестиций в $965 млрд. В феврале было объявлено о привлечении $30 млрд в G-раунде и post-money оценке в $380 млрд. То есть свыше половины триллиона баксов стоимости создано…
Тем временем Антропик и СпейсЭкс уверенно продает свои лимонные плантации в народ
Компанию Маска говорят, даже по-братски уже включили в индексы. Это загоняет триллионы индексных фондов от нефтяных шейхов и американских пенсионеров в компанию по безумной оценке.
Это как если бы я продал канал Архитектора Данных за 2 миллиарда рублей и обязал всех купить его часть.
Компанию Маска говорят, даже по-братски уже включили в индексы. Это загоняет триллионы индексных фондов от нефтяных шейхов и американских пенсионеров в компанию по безумной оценке.
Это как если бы я продал канал Архитектора Данных за 2 миллиарда рублей и обязал всех купить его часть.
Telegram
Архитектор Данных
Меняю профессию!
Теперь я вайб-садовод.
Вы со своими старыми подходами не понимаете, мир изменился, ИИ трансформация сжирает целые старые отрасли!
Мой продукт - нейро лимон 🍋 - инновационное производство с глубоким внедрением Искусственных Интеллектов…
Теперь я вайб-садовод.
Вы со своими старыми подходами не понимаете, мир изменился, ИИ трансформация сжирает целые старые отрасли!
Мой продукт - нейро лимон 🍋 - инновационное производство с глубоким внедрением Искусственных Интеллектов…
😁8❤3
Порой замечаю у людей адский хейт к airflow
Для меня это удобный инструмент, правда мне обычно нужно от него десятка три dbt run / dbt test да пара-тройка кастомных интеграций.
А какое у вас отношение?
И если не старичок, то кто?
Для меня это удобный инструмент, правда мне обычно нужно от него десятка три dbt run / dbt test да пара-тройка кастомных интеграций.
А какое у вас отношение?
И если не старичок, то кто?
❤4
Архитектор Данных
Порой замечаю у людей адский хейт к airflow Для меня это удобный инструмент, правда мне обычно нужно от него десятка три dbt run / dbt test да пара-тройка кастомных интеграций. А какое у вас отношение? И если не старичок, то кто?
Вдогонку.
Мой главный вопрос к старичку Airflow это то, что он стал слишком сложный.
С каждым мажорным релизом он становится еще сложнее. Вот в единичке и двойке были всем известные проблемы с шедулером - зависает, собака. Так давайте его в тройке распилим на несколько подсервисов. И еще даг процессор унесем отдельно чтоб один тяжело написанный даг файл не унес с собой в могилу весь сервис.
В моменте это даже нормальные решения. Но то что в итоге получилось это то ли 7, то ли 9 сервисов, которые надо размещать, управлять, за которыми надо следить.
Потом во все это залетают Vault для кредов, keycloak для аутентификаций, эластика или s3 для логов, сложные github/gitlab CI-CD для управления дагами. Потом все это надо повторить на нескольких QA-Test средах. Отдельное приключение - управление сложными питонячьими окружениями во всем этом.
Некоторые “умельцы» добавляют в это месиво еще своей сложности - например для синхронизации нескольких команд, которые на разных стадиях обслуживают один пайп данных. Для чего делают свои оркестраторы поверх этого оркестратора.
Дата инженерам не то чтобы комфортно, у ДевОпсов вскипает мозг от того, сколько всего надо сделать, чтобы весь этот жуткий зоопарк завелся.
И тут ты понимаешь, что все это нужно чтобы фактически запустить умный крон с граф интерфейсом. Траблшутнуть что-то по логам, поправить и перезапустить упавшее под-деревце из твоего куста. И твой проект не такой уж сложный, чтобы это все оправдать. Да и за мис по SLA или DQ не то чтобы отвезут в лес в пакете. Тогда зачем этот мудреный комбайн?
Решено, делаю свой оркестратор!
Мой главный вопрос к старичку Airflow это то, что он стал слишком сложный.
С каждым мажорным релизом он становится еще сложнее. Вот в единичке и двойке были всем известные проблемы с шедулером - зависает, собака. Так давайте его в тройке распилим на несколько подсервисов. И еще даг процессор унесем отдельно чтоб один тяжело написанный даг файл не унес с собой в могилу весь сервис.
В моменте это даже нормальные решения. Но то что в итоге получилось это то ли 7, то ли 9 сервисов, которые надо размещать, управлять, за которыми надо следить.
Потом во все это залетают Vault для кредов, keycloak для аутентификаций, эластика или s3 для логов, сложные github/gitlab CI-CD для управления дагами. Потом все это надо повторить на нескольких QA-Test средах. Отдельное приключение - управление сложными питонячьими окружениями во всем этом.
Некоторые “умельцы» добавляют в это месиво еще своей сложности - например для синхронизации нескольких команд, которые на разных стадиях обслуживают один пайп данных. Для чего делают свои оркестраторы поверх этого оркестратора.
Дата инженерам не то чтобы комфортно, у ДевОпсов вскипает мозг от того, сколько всего надо сделать, чтобы весь этот жуткий зоопарк завелся.
И тут ты понимаешь, что все это нужно чтобы фактически запустить умный крон с граф интерфейсом. Траблшутнуть что-то по логам, поправить и перезапустить упавшее под-деревце из твоего куста. И твой проект не такой уж сложный, чтобы это все оправдать. Да и за мис по SLA или DQ не то чтобы отвезут в лес в пакете. Тогда зачем этот мудреный комбайн?
Решено, делаю свой оркестратор!
😁12👍6
Forwarded from Соня Рыбак | HR for Tech
TechCrunch: AI команду Meты сравнили с Гулаг
Сложно представить такие статьи на наших ресурсах. Что где-то бунт, где-то что-то криво, или какой-то косяк в процессах вроде Амазона и выпущенного письма раньше времени.
У нас инфляция 2 процента и безработицы нет. Ладно. Не хочу флеймить. Просто моментное размышление.
Теперь к Meta. В чем весь цимес. Сотрудников без права отказаться перевели в новый отдел Apllied AI. 6 500 инженеров и продактов.
Людей, которые делали продукты, перевели на поддержку ИИ. Теперь они генерят пазлы и задачи по программированию для обучения ИИ.
Ты был инженером продукта, а теперь делаешь задачки для модели.
Сами сотрудники называют себя призывниками, пишут что такая работа убивает душу, и это буквально гулаг.
На этой неделе кто-то сорвал презентацию для сотрудников. Ворвался с матерной тирадой и попросил передать руководителю Meta AI, что тот a piece of sh*t.
Такие дела.
Народ обсуждает, что ИИ заменит инженеров. Но пока инженеров ставят на лейбелинг и гловоломки. Хотя, возможно, это нужный промежуточный шаг. Просто организовать его, возможно, стоит не как микроскопом по гвоздям.
🔥 — невыносимая тяжесть бытия в Meta
👍 — а как вы хотели, без обучения AI невозможен
💜 — а может будет как с Metaverse
Сложно представить такие статьи на наших ресурсах. Что где-то бунт, где-то что-то криво, или какой-то косяк в процессах вроде Амазона и выпущенного письма раньше времени.
У нас инфляция 2 процента и безработицы нет. Ладно. Не хочу флеймить. Просто моментное размышление.
Теперь к Meta. В чем весь цимес. Сотрудников без права отказаться перевели в новый отдел Apllied AI. 6 500 инженеров и продактов.
Людей, которые делали продукты, перевели на поддержку ИИ. Теперь они генерят пазлы и задачи по программированию для обучения ИИ.
Ты был инженером продукта, а теперь делаешь задачки для модели.
Сами сотрудники называют себя призывниками, пишут что такая работа убивает душу, и это буквально гулаг.
На этой неделе кто-то сорвал презентацию для сотрудников. Ворвался с матерной тирадой и попросил передать руководителю Meta AI, что тот a piece of sh*t.
Такие дела.
Народ обсуждает, что ИИ заменит инженеров. Но пока инженеров ставят на лейбелинг и гловоломки. Хотя, возможно, это нужный промежуточный шаг. Просто организовать его, возможно, стоит не как микроскопом по гвоздям.
🔥 — невыносимая тяжесть бытия в Meta
👍 — а как вы хотели, без обучения AI невозможен
💜 — а может будет как с Metaverse
😁9❤2👏2
Соня Рыбак | HR for Tech
TechCrunch: AI команду Meты сравнили с Гулаг Сложно представить такие статьи на наших ресурсах. Что где-то бунт, где-то что-то криво, или какой-то косяк в процессах вроде Амазона и выпущенного письма раньше времени. У нас инфляция 2 процента и безработицы…
Пойду скажу своим аналитикам, что если будут косячить, переведу их в ИИ-Гулаг
(А у любой Великой Стройки есть свой ГУЛаг)
(А у любой Великой Стройки есть свой ГУЛаг)
😁16
Кто чем занят, а я подловил Клода на задаче расположения 4 городов на поверхности Земли, так чтобы они были максимально удаленными.
Сначала сказал, что будут вершины тетраэдра, но это неверно!
Сначала сказал, что будут вершины тетраэдра, но это неверно!
😁5👾3
Лучшее вложение
Инвестиции работают по принципу - страдай сейчас, расслабляйся потом.
Пока лучшая инвестиция которую я видел в кругу своих знакомых - это сертификат 100 баллов по профилю ЕГЭ. Особенно если это ЕГЭ 2007-2010 годов.
Всегда можно подзаработать.
Инвестиции работают по принципу - страдай сейчас, расслабляйся потом.
Пока лучшая инвестиция которую я видел в кругу своих знакомых - это сертификат 100 баллов по профилю ЕГЭ. Особенно если это ЕГЭ 2007-2010 годов.
Всегда можно подзаработать.
💯5🫡2
Forwarded from tl;dr data
Databricks объявил конец эпохи пайплайнов.
На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами.
Последние двадцать лет типичная архитектура выглядела примерно так:
PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI
Каждый новый слой добавлял задержки, повышал стоимость владения и создавал новые точки отказа. Особенно болезненно это стало с появлением AI-агентов, которым нужны актуальные данные в реальном времени, а не копия пятиминутной давности.
Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных.
Конечно, заявления о «смерти пайплайнов» стоит воспринимать осторожно. Интеграции между компаниями, обмен данными с внешними системами, специализированные стриминговые сценарии и гибридные архитектуры никуда не денутся.
Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе:
Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных?
Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering.
@tldr_data
На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами.
Последние двадцать лет типичная архитектура выглядела примерно так:
PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI
Каждый новый слой добавлял задержки, повышал стоимость владения и создавал новые точки отказа. Особенно болезненно это стало с появлением AI-агентов, которым нужны актуальные данные в реальном времени, а не копия пятиминутной давности.
Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных.
Конечно, заявления о «смерти пайплайнов» стоит воспринимать осторожно. Интеграции между компаниями, обмен данными с внешними системами, специализированные стриминговые сценарии и гибридные архитектуры никуда не денутся.
Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе:
Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных?
Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering.
@tldr_data
💯8❤6
Тренд на отказ от ETL провозглашенный датабриксом реален.
Реальностью его сделали 2 вещи
1) Появление лейка с упрощенной транзакционной моделью, квази-acid. В первую очередь это Iceberg и похожие на него технологии.
2) Распространение агентов.
И внезапно выяснилось, что под 98% микросервисов вполне можно подложить стораж с ограниченной транзакционной машиной. И нагрузки там большой не будет - ну 5, ну 50 tps - это уже вполне в зоне, где тот же s3 стораж справится. С некоторым кешем, разумеется.
С другой стороны - возможность подключить агента напрямую к данным (именно к данным, а не к самому сервису) это ценно. Потому что агент может сам обходить данные нескольких сервисов, взаимно обогащать их по своему усмотрению без того, чтобы разработчики сервисов делали ему отдельные ручки и оборачивали их в MCP.
Уходит важнейшее узкое место любых агентных историй.
Поэтому да, в транзакциях мало ценности, а в лайв-подключении агентов - много.
Нас ждет LTAP.
Реальностью его сделали 2 вещи
1) Появление лейка с упрощенной транзакционной моделью, квази-acid. В первую очередь это Iceberg и похожие на него технологии.
2) Распространение агентов.
И внезапно выяснилось, что под 98% микросервисов вполне можно подложить стораж с ограниченной транзакционной машиной. И нагрузки там большой не будет - ну 5, ну 50 tps - это уже вполне в зоне, где тот же s3 стораж справится. С некоторым кешем, разумеется.
С другой стороны - возможность подключить агента напрямую к данным (именно к данным, а не к самому сервису) это ценно. Потому что агент может сам обходить данные нескольких сервисов, взаимно обогащать их по своему усмотрению без того, чтобы разработчики сервисов делали ему отдельные ручки и оборачивали их в MCP.
Уходит важнейшее узкое место любых агентных историй.
Поэтому да, в транзакциях мало ценности, а в лайв-подключении агентов - много.
Нас ждет LTAP.
Telegram
Архитектор Данных
Databricks объявил конец эпохи пайплайнов.
На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных.…
На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных.…
❤8🔥7