Короче я все понял, как надо хайповать в Linkedin.

Вот вам мой Playbook.

Сценарий 1 - я пишу, что AI заменит всех вендоров и что код писать больше не надо. Ко мне сразу бежит народ доказывать, что я ничего не понимаю (мягко сказано) и начинают говорить как нужно. (У меня мысль всегда одна, если ты такой умный, то чего такой бедный🤑)

Сценарий 2 - тегаем Зака 🤴, говорим, что он красавчик, дописываем пару своих мыслей, НО не добавляем ссылку на его пост. Все начинают переживать, как же так, я цитирую самого Зака но ссылку не добавил…Потом приходит Зак и говорит, что надо бы ссылку добавить… Я ссылку добавляю и отвечаю на 40 комментариев. Мир LinkedIn спасен!


Охваты, лайки, шеры и тп. Вот это я понимаю шоу бизнес. А писать умные вещи про архитектуры, дизайны это все сложно и лениво.

Я это еще понял, когда на яхте (не в ту дверь вошел) кружок записал, надо больше 💅 наваливать, тогда все будет! 🔥

😬 Запись вебинара XLTable - OLAP сервер для больших данных
https://youtu.be/gVvIf2ycxgM
#datalearn #Вебинар

Что делать если у вас нет реального опыта, а хочется работать дата инженером или кем-то еще?

Ответ простой, находите вакансии с нижней планкой зарплаты и туда идете работать. Опытные люди (даже если опыт 1год туда не пойдут), поэтому вы будете конкурировать с такими же вкатунами кандидатами:)

Как я понял 200к для дата инженера это как раз такая планка, где можно экспериментировать🎮

Реально так и есть 🔥

Вы говорит AI бесполезный! Посмотрите какой bash скрипт мне он сделал! Магия!

С 8 марта девушки!💐

В прошлом году Databricks купил Neon.

Основатели Neon:
• Никита Шамгунов - CEO и идейный вдохновитель Россиянин, PhD по Computer Science из Санкт-Петербурга
• Хейкки Линнакангас - Co-founder, Postgres-хакер
Финн, один из самых известных core committer'ов PostgreSQL с 20+ летним стажем.
• Стас Кельвич - Co-founder, инженер. Изучал физику, затем пришёл в разработку — работал в Яндексе в команде баз данных.

Команда собралась вокруг одной идеи: "что если сделать для Postgres то же, что Amazon Aurora сделала для MySQL/Postgres, но open-source и по-настоящему serverless?"

Amazon Aurora это serverless Postgres, но это как бы vendor lock.

У Neon было три основных этапа/фичи:

1️⃣Разделение слоев давало serverless-поведение: scale-to-zero, оплата только за реальное использование, "бездонное" хранилище.

2️⃣Разделение compute и storage открыло неожиданную суперспособность - branching базы данных через copy-on-write. Создать полную копию базы с данными и схемой стало бесплатным по времени и почти бесплатным по стоимости.

Кстати Snowflake zero-copy cloning имеет похожую идею copy-on-write - клон/ветка не копирует данные физически, а создаёт метаданные-указатели на те же блоки хранилища. Новые данные записываются только при изменениях. Оба мгновенные и почти бесплатные по хранилищу. Только у Neon каждая ветка это свой изолированный Postgres. Благодаря этому у каждой ветки свой compute и не влияет на продакшн базу данных.

3️⃣Neon обнаружил, что 80% баз на их платформе создаются кодом, а не людьми. AI-агенты и платформы вроде Replit Agent стали создавать тысячи эфемерных баз на лету - под каждого пользователя, под каждый эксперимент. Один инженер в Retool управлял через Neon API 300,000 Postgres-инстансов.

Для Databricks это решение понравилось, ведь они уже работаю с AI агентами, каждый агент получает свою изолированную базу данных, и сама идея Zero ETL не нова, и Neon позволяет использовать OLTP workloads и хранить данные сразу в Databricks, ведь Neon хранит данные в облачном object storage (S3/ADLS/GCS), то есть буквально в том же хранилище, что и lakehouse.

И вот Databricks закончил интеграцию и назвал продукт/фичу - Lakebase. Это Postgres версии 16/17. Так же Databricks приобрел Mooncake для лучшей интеграции Postgres с Lakehouse.

Mooncake Labs - это маленький стартап (основан в 2024 году), который сделал одну очень конкретную вещь: ⁠pg_mooncake — Postgres-расширение, которое добавляет колоночное хранилище прямо внутрь Postgres, сохраняя данные в формате Apache Iceberg/Delta Lake в object storage.

Под капотом происходит следующее:
• Данные хранятся не в Postgres heap (row-формат), а в Parquet-файлах в S3 в формате Iceberg
• Аналитические запросы выполняются через DuckDB (встроен в расширение) - векторизованный движок, заточенный под колоночное чтение

Neon дал serverless Postgres compute, но данные в нём хранились в Postgres-формате — отдельно от lakehouse.

Чтобы аналитические движки (Spark, Databricks SQL) могли их читать, нужно было либо копировать данные через ETL, либо держать два источника правды.

Mooncake закрыл этот gap: вместо того чтобы копировать данные из Postgres в lakehouse, он делает Iceberg основным хранилищем. Postgres пишет сразу в Iceberg/Parquet в S3 - и тот же файл без какого-либо ETL читают и приложения через Postgres, и аналитика через Spark.

Есть еще Synced Tables - это отдельный, более старый механизм для обратного направления: когда нужно "опустить" уже готовые аналитические данные из Unity Catalog в Lakebase, чтобы приложение могло читать их с низкой латентностью (< 10 мс) (Reverse ETL). Здесь дублирование данных неизбежно — потому что аналитический Parquet нужно переложить в row-формат Postgres для быстрых point-lookup запросов.


PS Работаю часто с Databricks, пока реальных кейсов на Lakebase Postgres не видел =/

Узнал сегодня про Dracula Effect в контексте AI - это термин для описания вампирского эффекта истощения, который испытывают люди при интенсивной работе с AI-агентами.

AI автоматизирует рутинные задачи, но оставляет человеку всю сложную когнитивную работу - принятие решений, анализ результатов, постановку задач, проверку кода. По сути, ты постоянно занимаешься только стратегическими и сложными вещами, без передышки на простые задачи.

Реально ловлю себя на том, что день проходит плотничком и энергии уходит много. Но нам не привыкать📈