Нашел интересный проект для сына (13 лет) - использовать computer vision библиотеку, которая считывает эмоции (базовые с лица) по нескольким координатам и выводит результат на lcd дисплей Arduino. Cursor помогал фиксить проблемы и отвечать на вопросы.
Сам проект https://youtu.be/Q5U-b6gRTaY?si=lccSl_HqD7buqSmn
Сам проект https://youtu.be/Q5U-b6gRTaY?si=lccSl_HqD7buqSmn
3⚡72❤🔥27
Surfalytics Discord is on🔥 На картинке это лишь один из примеров.
Что что, а вот радоваться чужим успехам я люблю! Особенно когда я вижу прогресс, hard work, и активность в сообществе.
Недавно я поймал себя на мысли, что ко мне приходит за советом 2 типа людей:
1) 0 дохода и опыта или около того
2) 1 млн рублей в месяц (РФ) или 300к CAD/USD в год Северной Америке.
Как правило нет среднячков, потому среднички считают, что они и так все знают и сами с усами или просто карьера у них не в приоритете.
Что что, а вот радоваться чужим успехам я люблю! Особенно когда я вижу прогресс, hard work, и активность в сообществе.
Недавно я поймал себя на мысли, что ко мне приходит за советом 2 типа людей:
1) 0 дохода и опыта или около того
2) 1 млн рублей в месяц (РФ) или 300к CAD/USD в год Северной Америке.
Как правило нет среднячков, потому среднички считают, что они и так все знают и сами с усами или просто карьера у них не в приоритете.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥33⚡12🦄6🌚3🐳1👨💻1
А может есть народ в Salt Lake City? Буду там 29 сентября по 2 октября.
Из последних встреч, особо никого не получилось собрать:
- Во Франции (Париж и побережье) нет никого, я даже написал в 5-6 сообществ на meetup.com, чтобы выступить и рассказать про проекты, но не получил ответа.
- В Чикаго был один человек, кстати!, не заметил прогресса карьерного 😜
- В Денвере никого не встретил, кроме своего бывшего коллеги, американца итальянского происхождения, который сделал настоящую пиццу на дровах и разрешил пострелять из его пушек.
В Сиэтле несколько ребят пришло, познакомился с E7 Data Scientist (из вежливости не спросил про зарплату, но потом погуглил 🤗, знакомая с парочкой работ в US компаниях и data начальница в Stripe. Как обычно сравнили жизнь в Канаде и США, погрустили над низкими доходами в Канаде.
Из последних встреч, особо никого не получилось собрать:
- Во Франции (Париж и побережье) нет никого, я даже написал в 5-6 сообществ на meetup.com, чтобы выступить и рассказать про проекты, но не получил ответа.
- В Чикаго был один человек, кстати!, не заметил прогресса карьерного 😜
- В Денвере никого не встретил, кроме своего бывшего коллеги, американца итальянского происхождения, который сделал настоящую пиццу на дровах и разрешил пострелять из его пушек.
В Сиэтле несколько ребят пришло, познакомился с E7 Data Scientist (из вежливости не спросил про зарплату, но потом погуглил 🤗, знакомая с парочкой работ в US компаниях и data начальница в Stripe. Как обычно сравнили жизнь в Канаде и США, погрустили над низкими доходами в Канаде.
❤🔥12🐳4🌚2⚡1💯1
Уверен, что абсолютно все команды у кого есть Snowflake сейчас занимаются примерно одним и тем же - улучшают безопасность. И это в принудительном порядке.
Snowflake всех обязал усилить безопасность пользователей, что очень логично и важно абсолютно для любого решения, но как правило такие действиях уходят в backlog и todo.
Что же предлагает Snowflake?
1. Разделить всех пользователей на Person и Service.
2. Для каждого person активировать MFA или passkey.
3. Для каждого service удалить пароль и добавить Key Pair.
4. Для service добавить IP whitelist.
Это такой минимум, который поможет вашему решению стать более безопасным. В идеале такие шаги можно делать в любой платформе.
PS На любом собеседования и system design можно рассказывать про кейс безопасности, использую набор из 4х пунктов выше.
Вообще тема безопасности одна из самых скучных в DE, там же и вопросы про персональные данные и encryption. Но зато, за них всегда четкий reward и recognition.
Snowflake всех обязал усилить безопасность пользователей, что очень логично и важно абсолютно для любого решения, но как правило такие действиях уходят в backlog и todo.
Что же предлагает Snowflake?
1. Разделить всех пользователей на Person и Service.
2. Для каждого person активировать MFA или passkey.
3. Для каждого service удалить пароль и добавить Key Pair.
4. Для service добавить IP whitelist.
Это такой минимум, который поможет вашему решению стать более безопасным. В идеале такие шаги можно делать в любой платформе.
PS На любом собеседования и system design можно рассказывать про кейс безопасности, использую набор из 4х пунктов выше.
Вообще тема безопасности одна из самых скучных в DE, там же и вопросы про персональные данные и encryption. Но зато, за них всегда четкий reward и recognition.
❤🔥36⚡5
Вот так неожиданно - Fivetran покупает sqlMesh. 1-го мая я писал о покупки Census.
Про sqlMesh у нас были и посты и вебинары - это такая современная альтернатива dbt. Лично для меня после такого приобретения sqlMesh становится менее привлекательным, так как они могут пойти по пути убийства open source продукта.
Раньше я думал, что Tobico еще очень молодая и маленькая компания. В истории я вижу только seed (4.5m) и Series A (17.3m). Несмотря на размер, Fivetran увидел для себя ценность исъел купил.
Про dbt недавно узнал, что они внедряют новую pricing model для их dbt fusion cloud - credit based. Я уже писал о таких изменения в Dagster, когда flat fee заменили на credit based и цена выросла в 10-20 раз для маленькой команды. Сейчас такое же делает dbt cloud.
Некоторые команды еще держатся на dbt cloud и платят только за один license seat, а вся разработка на dbt core, но вендор подпирает и скоро лишит всех такой возможности.
Про sqlMesh у нас были и посты и вебинары - это такая современная альтернатива dbt. Лично для меня после такого приобретения sqlMesh становится менее привлекательным, так как они могут пойти по пути убийства open source продукта.
Раньше я думал, что Tobico еще очень молодая и маленькая компания. В истории я вижу только seed (4.5m) и Series A (17.3m). Несмотря на размер, Fivetran увидел для себя ценность и
Про dbt недавно узнал, что они внедряют новую pricing model для их dbt fusion cloud - credit based. Я уже писал о таких изменения в Dagster, когда flat fee заменили на credit based и цена выросла в 10-20 раз для маленькой команды. Сейчас такое же делает dbt cloud.
Некоторые команды еще держатся на dbt cloud и платят только за один license seat, а вся разработка на dbt core, но вендор подпирает и скоро лишит всех такой возможности.
Yahoo Finance
Fivetran Acquires Tobiko Data to Power the Next Generation of Advanced, AI-Ready Data Transformation
OAKLAND, Calif., September 03, 2025--Fivetran, the global leader in automated data movement, today announced it has acquired Tobiko Data, the open source transformation company behind SQLMesh and SQLGlot. With the acquisition, Fivetran strengthens its position…
🙈16😭5🤷1
Dimensional Modelling и Slowly Change Dimension на западе это не шутка! Уверен в ГосУслугах таких трудностей у архитекторов и инженеров нет😊
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Нейро-МВА
AI+Python гайд парсинг цен.pdf
3.2 MB
Как сделать парсер цен конкурентов (и еще много чего), если ты менеджер, а не Python-разработчик ?
Затык в том, что для этого нужен технарь, а ему нужно четкое ТЗ, да еще и деньги. А вам потом выяснять, где он перепутал, переделывать, тратить время и нервы.
В такие моменты думаешь - быстрее было бы разобраться и сделать самому 😡
А теперь, в эпоху AI, это и правда возможно! За 5 минут сгенерить код с ChatGPT и запустить скрипт на Python.
Не верите?
Пройдите по 5 шагам этого гайда и сделайте свой парсер цен на Python, даже если никогда в жизни не программировали.
Кто попробовал - ставьте🔥 и делитесь гайдом с коллегами!
Идея не нова - написать бота, который будет ходить по нужным сайтам, автоматически собирать оттуда информацию и присылать вам, разложенную по полочкам.
Затык в том, что для этого нужен технарь, а ему нужно четкое ТЗ, да еще и деньги. А вам потом выяснять, где он перепутал, переделывать, тратить время и нервы.
В такие моменты думаешь - быстрее было бы разобраться и сделать самому 😡
А теперь, в эпоху AI, это и правда возможно! За 5 минут сгенерить код с ChatGPT и запустить скрипт на Python.
Не верите?
Пройдите по 5 шагам этого гайда и сделайте свой парсер цен на Python, даже если никогда в жизни не программировали.
Кто попробовал - ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
😭20
Good point, как говорится. Автор сообщает, что компании консолидируются в unified платформы, и наш любимый modern data stack уже скоро не будет состоять из маленьких разрозненных кусочков и нам придется работать с большими платформами, в которых будет все необходимое для аналитики и инжиниринга данных.
Зато проекты по миграции выйдут на новый уровень по трудозатратам и стоимости, а vendor lock заиграет новыми красками💰
Зато проекты по миграции выйдут на новый уровень по трудозатратам и стоимости, а vendor lock заиграет новыми красками💰
💯14🫡8
Microsoft опубликовал большой курс по Generative AI.
https://github.com/microsoft/generative-ai-for-beginners/tree/main
Снизу по ссылке будут дополнительные ссылки на другие курсы.
Самые горячие кейсы по GenAI, с которыми сталкиваюсь:
- Text to Insights (уже несколько проектов по Snowflake + Cortex Analyst и один по BigQuery + TextQL). Такие проекты для больших компаний (enterprise), больше похоже на продажу AI на уровне директора/VP аналитики другим директорам/VP бизнес подразделений, ну типа мы AI driven
- Developer Performance с использование Cursor или Claude Code. GitHub CoPilot пока не дотягивает. Компания покупают лицензии и дают своим инженерам. В репозиториях обязательно файлы с правилами для GenAI.
- PR reviews, часто с Claude Code и Cursor. Опять же можно добавить правила (best practices) для PR review, чтобы фиксить согласно заданным требованиям (правилам)
- RAG - компании строят чат боты по внутренней и внешней документации и базе знаний, чтобы клиенту было проще найти ответ на свой вопрос.
- MCP интеграции, например DataHub (дата каталог) может ходить в Snowflake (хранилище данных), Cursor может писать запросы и на базе них создавать dbt модели.
Это прям, что мои команды используют. Все сходятся на позиции, что prompt (context) engineering очень важен, и нужно знать основы и следовать рекомендациям вендоров.
PS и конечно это все идет в мою любимую рубрику - увлекательные истории для вашего будущего собеседования:)
https://github.com/microsoft/generative-ai-for-beginners/tree/main
Снизу по ссылке будут дополнительные ссылки на другие курсы.
Самые горячие кейсы по GenAI, с которыми сталкиваюсь:
- Text to Insights (уже несколько проектов по Snowflake + Cortex Analyst и один по BigQuery + TextQL). Такие проекты для больших компаний (enterprise), больше похоже на продажу AI на уровне директора/VP аналитики другим директорам/VP бизнес подразделений, ну типа мы AI driven
- Developer Performance с использование Cursor или Claude Code. GitHub CoPilot пока не дотягивает. Компания покупают лицензии и дают своим инженерам. В репозиториях обязательно файлы с правилами для GenAI.
- PR reviews, часто с Claude Code и Cursor. Опять же можно добавить правила (best practices) для PR review, чтобы фиксить согласно заданным требованиям (правилам)
- RAG - компании строят чат боты по внутренней и внешней документации и базе знаний, чтобы клиенту было проще найти ответ на свой вопрос.
- MCP интеграции, например DataHub (дата каталог) может ходить в Snowflake (хранилище данных), Cursor может писать запросы и на базе них создавать dbt модели.
Это прям, что мои команды используют. Все сходятся на позиции, что prompt (context) engineering очень важен, и нужно знать основы и следовать рекомендациям вендоров.
PS и конечно это все идет в мою любимую рубрику - увлекательные истории для вашего будущего собеседования:)
❤🔥25🐳1
Snowflake опубликовал paper - Workload Insights From The Snowflake Data Cloud: What Do Production Analytic Queries Really Look Like?
Что сделали
✅ Проанализировали ~667 млн продакшен-запросов из популярных BI-инструментов к Snowflake (в одном облачном регионе за неделю в октябре 2024).
✅ Смотрели тексты SQL и планы выполнения: фильтры, джоины, агрегации, ORDER BY/LIMIT, UNION ALL, глубину выражений.
✅ Сопоставили с TPC-DS и указали, где бенчмарк не эффективен.
Результаты:
1. Общая картина нагрузки
Read-heavy нагрузка: SELECT (47%) + SHOW (31%) = 78% всех запросов.
DDL-операций (4%) в 2 раза больше, чем DML (2%).
Соотношение чтение/запись ≈ 25:1.
2. Характеристики SQL
ORDER BY (54%) и GROUP BY (55%) — более чем в половине запросов.
JOIN встречается в 46% запросов.
CTE в 25%, оконные функции — в 11%.
LIMIT в 25% случаев, но в реальности часто ограничение идёт на миллионы строк (из-за дефолтов BI-клиентов).
3. Операторы и ресурсы
По частоте операторов: Projection (44%), Filter (16%), Aggregate (14%), Table Scan (10%), Join (10%).
По CPU: Table Scan + Filter ≈ 48%, Join ≈16%, Aggregate ≈15%, Projection ≈10%.
Основная нагрузка на чтение и джойны.
4. Джойны
20% JOIN-запросов содержат 10+ джойнов, отдельные доходят до 1000+.
Типы: Inner 59%, Outer 37%, Semi/Anti ~4%.
Ключи: ~46% текстовые, ~41% числовые, ~11% даты/время.
Поведение: 70% preserving, 16% exploding (результат больше входа), 13% filtering.
5. Агрегации
Лидер — any_value (58%), затем sum (15%), count (12%), max (11%), min (5%).
Много агрегаций по текстовым колонкам (34%), а не только по числам (49%).
В TPC-DS почти нет текстовых агрегатов (98% numeric).
6. Фильтры
Фильтрация в основном по тексту (58%), числовые только 25%.
Популярные предикаты: = (22%), IS NOT NULL (17%), логические связки (15%), CONTAINS (3%).
15% фильтров имеют вложенность >5 уровней.
Селективность сильно варьируется: 13% обнуляют выборку, 19% не фильтруют ничего, 46% — высокоселективные.
7. LIMIT и UNION ALL
LIMIT часто используется BI-системами для выгрузки миллионов строк (71% без ORDER BY возвращают 1M–10M строк).
UNION ALL в большинстве случаев ≤10, но есть хвост с сотнями инпутов.
8. Отличия от TPC-DS
В реальных BI-нагрузках есть:
Метаданные-запросы (SHOW, SESSION) — в бенчмарках отсутствуют.
Текстовые ключи и фильтры.
Outer joins.
Глубокие выражения и длинные графы джойнов.
Большие LIMIT-ы и нестандартные агрегации (any_value).
В целом такой обзор показывает, что традиционные benchmarks на базе TPC-DS далек от того, что происходит в реальности. BI инструментам вообще все-равно на качество запроса и плана, что приводит к излишним расходам. Возможно такой анализ был бы полезен вендорам, которые хотят улучшить эффективность работы BI и Snowflake.
Что сделали
✅ Проанализировали ~667 млн продакшен-запросов из популярных BI-инструментов к Snowflake (в одном облачном регионе за неделю в октябре 2024).
✅ Смотрели тексты SQL и планы выполнения: фильтры, джоины, агрегации, ORDER BY/LIMIT, UNION ALL, глубину выражений.
✅ Сопоставили с TPC-DS и указали, где бенчмарк не эффективен.
Результаты:
1. Общая картина нагрузки
Read-heavy нагрузка: SELECT (47%) + SHOW (31%) = 78% всех запросов.
DDL-операций (4%) в 2 раза больше, чем DML (2%).
Соотношение чтение/запись ≈ 25:1.
2. Характеристики SQL
ORDER BY (54%) и GROUP BY (55%) — более чем в половине запросов.
JOIN встречается в 46% запросов.
CTE в 25%, оконные функции — в 11%.
LIMIT в 25% случаев, но в реальности часто ограничение идёт на миллионы строк (из-за дефолтов BI-клиентов).
3. Операторы и ресурсы
По частоте операторов: Projection (44%), Filter (16%), Aggregate (14%), Table Scan (10%), Join (10%).
По CPU: Table Scan + Filter ≈ 48%, Join ≈16%, Aggregate ≈15%, Projection ≈10%.
Основная нагрузка на чтение и джойны.
4. Джойны
20% JOIN-запросов содержат 10+ джойнов, отдельные доходят до 1000+.
Типы: Inner 59%, Outer 37%, Semi/Anti ~4%.
Ключи: ~46% текстовые, ~41% числовые, ~11% даты/время.
Поведение: 70% preserving, 16% exploding (результат больше входа), 13% filtering.
5. Агрегации
Лидер — any_value (58%), затем sum (15%), count (12%), max (11%), min (5%).
Много агрегаций по текстовым колонкам (34%), а не только по числам (49%).
В TPC-DS почти нет текстовых агрегатов (98% numeric).
6. Фильтры
Фильтрация в основном по тексту (58%), числовые только 25%.
Популярные предикаты: = (22%), IS NOT NULL (17%), логические связки (15%), CONTAINS (3%).
15% фильтров имеют вложенность >5 уровней.
Селективность сильно варьируется: 13% обнуляют выборку, 19% не фильтруют ничего, 46% — высокоселективные.
7. LIMIT и UNION ALL
LIMIT часто используется BI-системами для выгрузки миллионов строк (71% без ORDER BY возвращают 1M–10M строк).
UNION ALL в большинстве случаев ≤10, но есть хвост с сотнями инпутов.
8. Отличия от TPC-DS
В реальных BI-нагрузках есть:
Метаданные-запросы (SHOW, SESSION) — в бенчмарках отсутствуют.
Текстовые ключи и фильтры.
Outer joins.
Глубокие выражения и длинные графы джойнов.
Большие LIMIT-ы и нестандартные агрегации (any_value).
В целом такой обзор показывает, что традиционные benchmarks на базе TPC-DS далек от того, что происходит в реальности. BI инструментам вообще все-равно на качество запроса и плана, что приводит к излишним расходам. Возможно такой анализ был бы полезен вендорам, которые хотят улучшить эффективность работы BI и Snowflake.
2⚡15❤🔥6🍌2🦄1
Я писал выше про свой опыт продажи недвижимости. Так сложилось, что в Канаде я был очень bias towards покупки недвижимости, был воодушевлен низкой ставкой и ростом 10% в год. После 8 месяцев на рынке, платя 3 ипотеки и не имея дохода от сдачи жилья (решил больше не быть landlord) мне удалось продать 2/3 всего. Сумарно я потерял тысяч 300-400+ на этих 2х недвижимостях, и это не считая сил, нервов и времени. Можно считать, что это цена свободы от банковской кабалы.
Поэтому пост от Andre мне очен заходит, ведь если math doesn’t math, тогда не стоит в это дело ввязываться, а лучше арендовать, там где нравится и удобно, чем платить ипотеку банку, где 85% всех ваших денег, это лишь проценты по ипотеке.
Хотя если вы мечтаете иметь свой дом в Северной Америке, сейчас лучшее время покупать, но ужасное время продавать.
PS я уже писал про курс - Ace the Business Expenses. Теперь еще можно курсов добавить про Ace the 1st time Real Estate purchase, Ace the running Airbnb and long-term renting.
Поэтому пост от Andre мне очен заходит, ведь если math doesn’t math, тогда не стоит в это дело ввязываться, а лучше арендовать, там где нравится и удобно, чем платить ипотеку банку, где 85% всех ваших денег, это лишь проценты по ипотеке.
Хотя если вы мечтаете иметь свой дом в Северной Америке, сейчас лучшее время покупать, но ужасное время продавать.
PS я уже писал про курс - Ace the Business Expenses. Теперь еще можно курсов добавить про Ace the 1st time Real Estate purchase, Ace the running Airbnb and long-term renting.
❤🔥23🫡7⚡1🐳1
This media is not supported in your browser
VIEW IN TELEGRAM
big tech night — это «ночь музеев» в мире IT, где Яндекс, Сбер, X5, Т-Банк и Lamoda впервые приглашают за кулисы.
Формат, придуманный в Яндексе, для тех, кто уже в IT или только стремится туда попасть. Здесь можно увидеть, как создаются технологии, меняющие окружающую среду, познакомиться с коллегами, обменяться опытом, задать неудобные вопросы и почувствовать себя частью комьюнити.
Вас ждут доклады, иммерсивные экскурсии и атмосфера IT-андеграунда. А если вы не в Москве, подключайтесь к онлайн-студии с двумя потоками — от серьезных дискуссий для гиков до лампового ночного шоу с историями из жизни.
Когда: 12 сентября.
Где: Москва или онлайн.
Регистрация - здесь.
Формат, придуманный в Яндексе, для тех, кто уже в IT или только стремится туда попасть. Здесь можно увидеть, как создаются технологии, меняющие окружающую среду, познакомиться с коллегами, обменяться опытом, задать неудобные вопросы и почувствовать себя частью комьюнити.
Вас ждут доклады, иммерсивные экскурсии и атмосфера IT-андеграунда. А если вы не в Москве, подключайтесь к онлайн-студии с двумя потоками — от серьезных дискуссий для гиков до лампового ночного шоу с историями из жизни.
Когда: 12 сентября.
Где: Москва или онлайн.
Регистрация - здесь.
❤🔥8
Concurrency (конкурентность )- одна из самых важные характеристик в базе данных. Что будет, если несколько процессов будут писать в одну таблицу? Традиционные базы данных уже научились это делать, а вот с озером данных или гибридным озером данных (lake house), не так все просто.
Когда несколько процессов одновременно пытаются записать данные в одну и ту же таблицу, это может привести к серьезным проблемам:
- Потерянные обновления (Lost Updates): Один процесс записывает данные, а второй тут же их перезаписывает, не зная о предыдущей операции.
- Несогласованные данные (Inconsistent Data): Данные могут оказаться в некорректном или неполном состоянии.
- Гонки данных (Race Conditions): Результат операции зависит от того, какой из процессов завершится первым, что делает результат непредсказуемым.
Традиционные реляционные базы данных, такие как PostgreSQL, MySQL и SQL Server, давно решили эту проблему. У них есть встроенные механизмы, которые гарантируют надежность транзакций по принципу ACID (Atomicity, Consistency, Isolation, Durability).
Они используют:
- Блокировки (Locking): Процессы временно блокируют доступ к данным, пока не завершат свою операцию.
- Управление параллельным доступом с помощью версий (MVCC): Вместо блокировки база данных создает разные версии данных. Это позволяет читателям видеть старую версию, пока новый процесс записывает новую.
Архитектура Data Lake и Lakehouse принципиально отличается. Они построены на распределенных файловых системах (HDFS, Amazon S3, Azure Blob Storage), которые изначально созданы для хранения огромных объемов данных, а не для поддержки транзакций.
Основные проблемы:
- Нет встроенной поддержки ACID: Файловые системы не поддерживают атомарные транзакции. Если запись прервется на полпути, файл может остаться поврежденным.
- Работа с файлами, а не со строками: Изменение одной строки данных может потребовать перезаписи всего большого файла, что крайне неэффективно и опасно.
Чтобы решить эти проблемы, появились транзакционные фреймворки, которые добавляют уровень управления транзакциями поверх озер данных. Самые известные из них:
- Delta Lake
- Apache Hudi
- Apache Iceberg
Эти фреймворки создают слой метаданных, который ведет журнал всех изменений, обеспечивая атомарность операций и изоляцию снапшотов. Это позволяет им работать с данными в озерах так же надежно, как и традиционные базы данных.
В статье Can 10 Spark Writers Perform Concurrent Appends to an Iceberg Table Simultaneously? автор проверил, могут ли 10 одновременных процессов Spark успешно записывать (добавлять) данные в одну и ту же таблицу Apache Iceberg.
Тест 10 параллельных Spark‑записей (`MERGE INTO`) в разные партиции Iceberg‑таблицы на S3.
Проверяется, как система справляется с одновременными обновлениями: выполняется 10 Spark‑джобов, каждый таргетит отдельную партицию, и анализируются успехи и неудачи операций.
Основные настройки Iceberg для надёжной параллельной записи:
- `commit.retry.num-retries = 20` — попыток на случай конфликтов,
- `commit.retry.min-wait-ms = 30000` — минимальная задержка между попытками,
- `write.merge.isolation-level = snapshot` — слой изоляции, гарантирующий консистентность снимков.
Результат: несмотря на возникающие ошибки во время выполнения, автоматические ретраи и snapshot‑изоляция позволяют успешно завершить все `MERGE INTO` операции, сохранив целостность данных.
Когда несколько процессов одновременно пытаются записать данные в одну и ту же таблицу, это может привести к серьезным проблемам:
- Потерянные обновления (Lost Updates): Один процесс записывает данные, а второй тут же их перезаписывает, не зная о предыдущей операции.
- Несогласованные данные (Inconsistent Data): Данные могут оказаться в некорректном или неполном состоянии.
- Гонки данных (Race Conditions): Результат операции зависит от того, какой из процессов завершится первым, что делает результат непредсказуемым.
Традиционные реляционные базы данных, такие как PostgreSQL, MySQL и SQL Server, давно решили эту проблему. У них есть встроенные механизмы, которые гарантируют надежность транзакций по принципу ACID (Atomicity, Consistency, Isolation, Durability).
Они используют:
- Блокировки (Locking): Процессы временно блокируют доступ к данным, пока не завершат свою операцию.
- Управление параллельным доступом с помощью версий (MVCC): Вместо блокировки база данных создает разные версии данных. Это позволяет читателям видеть старую версию, пока новый процесс записывает новую.
Архитектура Data Lake и Lakehouse принципиально отличается. Они построены на распределенных файловых системах (HDFS, Amazon S3, Azure Blob Storage), которые изначально созданы для хранения огромных объемов данных, а не для поддержки транзакций.
Основные проблемы:
- Нет встроенной поддержки ACID: Файловые системы не поддерживают атомарные транзакции. Если запись прервется на полпути, файл может остаться поврежденным.
- Работа с файлами, а не со строками: Изменение одной строки данных может потребовать перезаписи всего большого файла, что крайне неэффективно и опасно.
Чтобы решить эти проблемы, появились транзакционные фреймворки, которые добавляют уровень управления транзакциями поверх озер данных. Самые известные из них:
- Delta Lake
- Apache Hudi
- Apache Iceberg
Эти фреймворки создают слой метаданных, который ведет журнал всех изменений, обеспечивая атомарность операций и изоляцию снапшотов. Это позволяет им работать с данными в озерах так же надежно, как и традиционные базы данных.
В статье Can 10 Spark Writers Perform Concurrent Appends to an Iceberg Table Simultaneously? автор проверил, могут ли 10 одновременных процессов Spark успешно записывать (добавлять) данные в одну и ту же таблицу Apache Iceberg.
Тест 10 параллельных Spark‑записей (`MERGE INTO`) в разные партиции Iceberg‑таблицы на S3.
Проверяется, как система справляется с одновременными обновлениями: выполняется 10 Spark‑джобов, каждый таргетит отдельную партицию, и анализируются успехи и неудачи операций.
Основные настройки Iceberg для надёжной параллельной записи:
- `commit.retry.num-retries = 20` — попыток на случай конфликтов,
- `commit.retry.min-wait-ms = 30000` — минимальная задержка между попытками,
- `write.merge.isolation-level = snapshot` — слой изоляции, гарантирующий консистентность снимков.
Результат: несмотря на возникающие ошибки во время выполнения, автоматические ретраи и snapshot‑изоляция позволяют успешно завершить все `MERGE INTO` операции, сохранив целостность данных.
❤🔥22⚡13🌚4
Норм идея - малышам не давать AI ассистента, а то совсем разучатся соображать.
Или не норм, мы же живем в мире AI, все движется со скоростью света, кто не успел, тот опоздал.
Или не норм, мы же живем в мире AI, все движется со скоростью света, кто не успел, тот опоздал.
1💯39❤🔥6⚡3🫡3🍌1
Заметил новый pattern, все аналитики (Excel, BI, SQL), которые не знали куда им деваться, и что делать - учить дата инжиниринг или data science, наконец определились и стали AI инженерами.
Возможно хороший pivot🤑
Возможно хороший pivot
Please open Telegram to view this post
VIEW IN TELEGRAM
Великий день для Oracle DBA, конечно если владеете акциями Oracle.
Вот коллеги из Oracle в США точно могут открывать шампанское🥇
Вот коллеги из Oracle в США точно могут открывать шампанское
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡20🐳4
Вчера все поздравляли Larry… Когда я слышу Larry то почему-то вспоминаю игру Leisure Suit Larry: Love for Sail!, но тут другое….
А сегодня народ стал обсуждать интересные моменты:
- У OpenAI нет 300 миллиардов долларов.
- У них даже близко нет 300 миллиардов долларов.
- Согласно их собственным (и, вероятно, оптимистичным) прогнозам, они не выйдут на прибыль до 2030 года.
- И всё это от компании, которая считала (или заявляла), что GPT-5 будет равнозначен ИИ уровня AGI (спойлер: нет, не стал).
- К слову, у Oracle нет чипов, которые нужны для выполнения контрактов, и даже денег, чтобы их купить.
Сама статья - Peak bubble, автор Gary Marcus сравнивает AI пузырь с тюльпаноманией.
Гэри когнитивный психолог и нейроучёный, профессор в NYU. Известен как критик “чистой” масштабируемой модели ИИ, часто подчёркивающий её ограничения, и сторонник гибридных (нейро-символических) подходов.
Реально Ларри там кому-то нормально откатил, что бы так залететь на пик😌
А сегодня народ стал обсуждать интересные моменты:
- У OpenAI нет 300 миллиардов долларов.
- У них даже близко нет 300 миллиардов долларов.
- Согласно их собственным (и, вероятно, оптимистичным) прогнозам, они не выйдут на прибыль до 2030 года.
- И всё это от компании, которая считала (или заявляла), что GPT-5 будет равнозначен ИИ уровня AGI (спойлер: нет, не стал).
- К слову, у Oracle нет чипов, которые нужны для выполнения контрактов, и даже денег, чтобы их купить.
Сама статья - Peak bubble, автор Gary Marcus сравнивает AI пузырь с тюльпаноманией.
Гэри когнитивный психолог и нейроучёный, профессор в NYU. Известен как критик “чистой” масштабируемой модели ИИ, часто подчёркивающий её ограничения, и сторонник гибридных (нейро-символических) подходов.
Реально Ларри там кому-то нормально откатил, что бы так залететь на пик
Please open Telegram to view this post
VIEW IN TELEGRAM
💯16🫡13⚡1😈1