Forwarded from System Design & Highload (Alexey Rybak)
Погружение в Лейкхаус! Офигенная новость, ребят – качаем, наконец, DWH! В следующую среду 13-го августа в 18:30 msk в Zoom состоится встреча с Алексеем Белозерским, руководителем группы BigData Services VK Cloud.
Тема встречи “Погружение в Лейкхаус: почему все о нём говорят”.
Обсудим:
- Ретроспектива развития хранилищ данных. Принципы и компоненты. Озера vs DWH. ETL vs event streaming. Витрины. Базовые классы компонент: базы и подтипы, распределенные хранилища, стриминг и процессинг, in-memory grids. HDFS/Hadoop, Spark, колоночные базы (Clickhouse, Vertica etc), Greenplum/Greengage, Exasol, Snowflake и тд и трансформация в современный стэк, Trino/Iceberg/S3 или in-memory processing, аналитические embedded-базы типа DuckDB
- Тренды, разделение compute/storage, in-memory вычисления. Почему сейчас старые методы не едут. Какие требования от современного бизнеса и почему старые ХД не удовлетворяют им: рост объемов, рост аналитической нагрузки, требования регуляторов в разных странах.
- Как это все расшивается на "новом" стеке из Лейкхауса - и почему об этом все говорят.
Встреча состоится в Zoom, в этот раз она свободна и для сообщества Devhands Club (слушатели наших курсов) и для всех остальных желающих принять участие в живой дискуссии, но обязательно нужно быть авторизованным в Zoom.
Topic: Devhands Open Sessions: Lakehouse deep-dive (A. Belozersky)
Time: Aug 8, 2025 06:30 PM Istanbul/MSK
Zoom: https://us06web.zoom.us/j/85409552470?pwd=mfmnt6aRvmllJB1iLx8Ws4sdiIqVD3.1
Добарить в календарь: https://addcal.io/e/k0dw9sgjk8ai
Приходите, приводите друзей!
Тема встречи “Погружение в Лейкхаус: почему все о нём говорят”.
Обсудим:
- Ретроспектива развития хранилищ данных. Принципы и компоненты. Озера vs DWH. ETL vs event streaming. Витрины. Базовые классы компонент: базы и подтипы, распределенные хранилища, стриминг и процессинг, in-memory grids. HDFS/Hadoop, Spark, колоночные базы (Clickhouse, Vertica etc), Greenplum/Greengage, Exasol, Snowflake и тд и трансформация в современный стэк, Trino/Iceberg/S3 или in-memory processing, аналитические embedded-базы типа DuckDB
- Тренды, разделение compute/storage, in-memory вычисления. Почему сейчас старые методы не едут. Какие требования от современного бизнеса и почему старые ХД не удовлетворяют им: рост объемов, рост аналитической нагрузки, требования регуляторов в разных странах.
- Как это все расшивается на "новом" стеке из Лейкхауса - и почему об этом все говорят.
Встреча состоится в Zoom, в этот раз она свободна и для сообщества Devhands Club (слушатели наших курсов) и для всех остальных желающих принять участие в живой дискуссии, но обязательно нужно быть авторизованным в Zoom.
Topic: Devhands Open Sessions: Lakehouse deep-dive (A. Belozersky)
Time: Aug 8, 2025 06:30 PM Istanbul/MSK
Zoom: https://us06web.zoom.us/j/85409552470?pwd=mfmnt6aRvmllJB1iLx8Ws4sdiIqVD3.1
Добарить в календарь: https://addcal.io/e/k0dw9sgjk8ai
Приходите, приводите друзей!
2🔥9👍4😎3
Forwarded from Greenplum secrets🎩
На заметку
А вы знали, что не каждая транзакция откатывается при ошибке ?
Если pl/pgsql функция абортнулась из-за нехватки места
schema's disk space quota exceeded with name : public
то таблицы, которые были ей созданы не откатываются, а остаются как будто транзакция корректно завершилась.
А вы знали, что не каждая транзакция откатывается при ошибке ?
Если pl/pgsql функция абортнулась из-за нехватки места
schema's disk space quota exceeded with name : public
то таблицы, которые были ей созданы не откатываются, а остаются как будто транзакция корректно завершилась.
😱9😢3🤓2👀1
Друзья, не забудьте сегодня зайти на наш с Алексеем стрим!
Алексей - эксперт в области хайлоада, архитектуры сервисов, кубернетису и другим сложным и полезным вещам!
Будем говорить про аналитический хайлоад и конечно же, Лейкхаусы.
Вопросы напишите в комменты - обязательно постараюсь ответить (со скидкой на то что я в гостях).
Спасибо!
Алексей - эксперт в области хайлоада, архитектуры сервисов, кубернетису и другим сложным и полезным вещам!
Будем говорить про аналитический хайлоад и конечно же, Лейкхаусы.
Вопросы напишите в комменты - обязательно постараюсь ответить (со скидкой на то что я в гостях).
Спасибо!
Telegram
Архитектор Данных
Погружение в Лейкхаус! Офигенная новость, ребят – качаем, наконец, DWH! В следующую среду 13-го августа в 18:30 msk в Zoom состоится встреча с Алексеем Белозерским, руководителем группы BigData Services VK Cloud.
Тема встречи “Погружение в Лейкхаус: почему…
Тема встречи “Погружение в Лейкхаус: почему…
❤4
Плейлист Lakehouse #3
Пополняем плейлист видео!
1️⃣ Разговоры на архитекторском - Вадим Белов (Х5)
Обсудили как крупные российские компании пришли к пониманю плюсов и минусов лейкхауса. Также Вадим проливает свет на процесс миграции данных на Lakehouse с классических аналитических систем.
2️⃣ Стрим про развитие аналитических систем с Алексеем Рыбаком (DevHands)
Обсудили развитие аналитических систем, КХД и Озер Данных. И как мы пришли к жизни такой, что нам нужен Lakehouse
Youtube
VK Видео
Предыдущие плейлисты: #1 #2
Все видео по теме я выкладываю на ВК Видео в плейлист.
Подпишитесь на мой канал и сообщество ВК.
Пополняем плейлист видео!
Обсудили как крупные российские компании пришли к пониманю плюсов и минусов лейкхауса. Также Вадим проливает свет на процесс миграции данных на Lakehouse с классических аналитических систем.
Обсудили развитие аналитических систем, КХД и Озер Данных. И как мы пришли к жизни такой, что нам нужен Lakehouse
Youtube
VK Видео
Предыдущие плейлисты: #1 #2
Все видео по теме я выкладываю на ВК Видео в плейлист.
Подпишитесь на мой канал и сообщество ВК.
Please open Telegram to view this post
VIEW IN TELEGRAM
VK Видео
Разговоры на архитекторском #1 - Вадим Белов о Data Lakehouse
С Вадимом Беловым, Head of Data Management Platform X5, поговорили о развитии хранилищ данных, ростом потребности в данных и требований к скорости обработки и предоставления данных. О развитии Data Lakehouse в X5, о миграции с MPP на систему с разделенным…
2👍10
Мудрые люди говорят, что заработать 3 млн / год проще всего в ИТ, но заработать 15-20 млн - где-то еще.
Ставь двери, лечи зубы, делай мебель на заказ. Заодно не будет конъюктуры, где ставка повысилась, и бюджеты все съехали на 1-2 года вправо. Зубы болят всегда вот прямо сейчас.
Ставь двери, лечи зубы, делай мебель на заказ. Заодно не будет конъюктуры, где ставка повысилась, и бюджеты все съехали на 1-2 года вправо. Зубы болят всегда вот прямо сейчас.
💯12😁5🫡5👍2⚡1✍1🤔1😱1
Forwarded from Соня Рыбак | HR for Engineers
Классная книга, для всех кто строит команды, кому интересно и важно понимать как они развиваются. Для меня эта книга абсолютный маст хев:
🌟 📕 Лидер и племя (Tribal Leadership) Дейв Логан, Джон Кинг
Помогает понять где культура вашей команды сейчас и как с этого уровня двигаться к более здоровому. Много примеров и практических советов что делать чтобы перейти с одного уровня на другой.
Читается легко, буквально за пару вечеров.
Ну и кратко прикольная и простая типизация команд (племен):
1. Жизнь — отстой. «Все против всех»:
Характеризуется отчуждением и негативными взаимоотношениями. Люди на этом уровне чувствуют себя отчужденными
и разделяют мнение "жизнь – отстой”, считают, что в их неуспехе виновата сама жизнь и обстоятельства.
2. Моя жизнь — отстой.
Я — винтик, от меня ничего не зависит. Апатия, выученная беспомощность, работа строго по инструкции. Типично для бюрократичных или выгоревших команд. Каждый сам за себя:
люди на этом уровне больше плывут по течению и винят в своих неуспехах например руководителя, считают, что их везде ограничивают.
3. Я крут, а вы — нет. Все работают на звезду.
Классическая корпоративная гонка. Соревновательность, борьба за признание, подковёрные игры. Все заняты собой, вклад команды обесценивается.
4. Мы крутые
Командный дух, доверие, общее дело. Спорят по существу, делятся ошибками и радуются успехам других. Цель важнее эго. Каждый работает на то, чтобы у каждого все получилось: на этом уровне люди ориентированы на командную работу и поддержку друг друга.
5. Жизнь — прекрасна
Высокий смысл и вдохновение. Такие команды не просто работают, они верят, что делают что-то важное — и действительно меняют мир. Люди счастливы и ощущают удовлетворение от своей работы, создают прорывные идеи и наслаждаются жизнью.
Как думаете где ваша команда сейчас?
1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣
Помогает понять где культура вашей команды сейчас и как с этого уровня двигаться к более здоровому. Много примеров и практических советов что делать чтобы перейти с одного уровня на другой.
Читается легко, буквально за пару вечеров.
Ну и кратко прикольная и простая типизация команд (племен):
1. Жизнь — отстой. «Все против всех»:
Характеризуется отчуждением и негативными взаимоотношениями. Люди на этом уровне чувствуют себя отчужденными
и разделяют мнение "жизнь – отстой”, считают, что в их неуспехе виновата сама жизнь и обстоятельства.
2. Моя жизнь — отстой.
Я — винтик, от меня ничего не зависит. Апатия, выученная беспомощность, работа строго по инструкции. Типично для бюрократичных или выгоревших команд. Каждый сам за себя:
люди на этом уровне больше плывут по течению и винят в своих неуспехах например руководителя, считают, что их везде ограничивают.
3. Я крут, а вы — нет. Все работают на звезду.
Классическая корпоративная гонка. Соревновательность, борьба за признание, подковёрные игры. Все заняты собой, вклад команды обесценивается.
4. Мы крутые
Командный дух, доверие, общее дело. Спорят по существу, делятся ошибками и радуются успехам других. Цель важнее эго. Каждый работает на то, чтобы у каждого все получилось: на этом уровне люди ориентированы на командную работу и поддержку друг друга.
5. Жизнь — прекрасна
Высокий смысл и вдохновение. Такие команды не просто работают, они верят, что делают что-то важное — и действительно меняют мир. Люди счастливы и ощущают удовлетворение от своей работы, создают прорывные идеи и наслаждаются жизнью.
Как думаете где ваша команда сейчас?
Please open Telegram to view this post
VIEW IN TELEGRAM
🏆8❤2😁1
This media is not supported in your browser
VIEW IN TELEGRAM
Технический вебинар по Айсбергу
Вы хотели технического мяса? Мы вам его даем!
🗓 3 сентября - вебинар по особенностям работы Iceberg.
1️⃣ Что именно вдруг поменялось в подходе, и почему про формат данных столько говорят.
2️⃣ Как оно там под капотом.
И конечно же, живая демонстрация технологии в Облаке!
Приходите и приводите друзей!
Вы хотели технического мяса? Мы вам его даем!
И конечно же, живая демонстрация технологии в Облаке!
Приходите и приводите друзей!
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤12👍7
Forwarded from Data Secrets
Media is too big
VIEW IN TELEGRAM
Neo AI выпустили агента NEO – ещё одного ML-инженера из коробки
Они называют его первым полностью автономным агентом, готовым к реальным ML-воркфлоу. По сути это не один агент, а ансамбль из 11 штук, которые делят между собой роли: от EDA до обучения, тюнинга и деплоя.
На бенчмарках результат впечатляющий. На MLE Bench от OpenAI NEO вышел на первое место: медали на 34.2% Kaggle-соревнований, против 22.4% у Microsoft RD Agent.
Под капотом у них оркестратор, который гоняет агентов через multi-step reasoning, передаёт контекст через собственный протокол и сохраняет память шагов.
Агент уже умеет в Snowflake, Databricks, BigQuery и деплой в VPC. То есть сразу нацелен на прод.
Как заявляют в компании, NEO разработан для ускорения работы ML-инженера, так что пока (наверное) ML-щики – не ВСЁ.
Вейтлист: https://heyneo.so/waitlist
Они называют его первым полностью автономным агентом, готовым к реальным ML-воркфлоу. По сути это не один агент, а ансамбль из 11 штук, которые делят между собой роли: от EDA до обучения, тюнинга и деплоя.
На бенчмарках результат впечатляющий. На MLE Bench от OpenAI NEO вышел на первое место: медали на 34.2% Kaggle-соревнований, против 22.4% у Microsoft RD Agent.
Под капотом у них оркестратор, который гоняет агентов через multi-step reasoning, передаёт контекст через собственный протокол и сохраняет память шагов.
Агент уже умеет в Snowflake, Databricks, BigQuery и деплой в VPC. То есть сразу нацелен на прод.
Как заявляют в компании, NEO разработан для ускорения работы ML-инженера, так что пока (наверное) ML-щики – не ВСЁ.
Вейтлист: https://heyneo.so/waitlist
❤4👍4😁2🤡1
Хакатон по лейкхаусу с призом 1 млн!
Недавно запустили хакатон от мэра Москвы - "Лидеры Цифровой Трансформации".
Там 10 задач от города и 10 задач от бизнеса. В каждой (!) свой призовой фонд 2 млн рублей. За первое - 1 млн. Задач много разных, там есть из чего выбрать.
От ВК - задача по оптимизации работы DLH на базе LLM.
Я бы сам пошел пробовать, но мне нельзя. 😁
А вы дерзайте!
Недавно запустили хакатон от мэра Москвы - "Лидеры Цифровой Трансформации".
Там 10 задач от города и 10 задач от бизнеса. В каждой (!) свой призовой фонд 2 млн рублей. За первое - 1 млн. Задач много разных, там есть из чего выбрать.
От ВК - задача по оптимизации работы DLH на базе LLM.
Я бы сам пошел пробовать, но мне нельзя. 😁
А вы дерзайте!
❤5👍4🤩3
LLM over BI - надо ли?
Тут Дима Аношин пишет про замену классического Business Intelligence на бездушного бота в слаке. Взлетит ли, если все хотят работать с живым ламповым аналитиком из мяса и костей?
А принцип простой - Такси и общественный транспорт.
Общественный транспорт решает типовые задачи типовым способом. Ездит по заранее проложенным маршрутам по расписанию. Такси - это по сути кастом с живым водителем за деньги.
Поэтому дизайн BI недалекого будущего это:
1) Массовый бот для быстрого ответа на относительно типовые вопросы по типовым метрикам.
2) Выезды живого аналитика по кастомным задачам.
Также как мы просим бота поддержки уйти и позвать живого оператора, также будем просить нейросеть позвать живого аналитика. Чтобы тот сваял нам ламповый кастомный отчет и настроил отправку на емейл графиков каждое утро.
Тут Дима Аношин пишет про замену классического Business Intelligence на бездушного бота в слаке. Взлетит ли, если все хотят работать с живым ламповым аналитиком из мяса и костей?
А принцип простой - Такси и общественный транспорт.
Общественный транспорт решает типовые задачи типовым способом. Ездит по заранее проложенным маршрутам по расписанию. Такси - это по сути кастом с живым водителем за деньги.
Поэтому дизайн BI недалекого будущего это:
1) Массовый бот для быстрого ответа на относительно типовые вопросы по типовым метрикам.
2) Выезды живого аналитика по кастомным задачам.
Также как мы просим бота поддержки уйти и позвать живого оператора, также будем просить нейросеть позвать живого аналитика. Чтобы тот сваял нам ламповый кастомный отчет и настроил отправку на емейл графиков каждое утро.
Telegram
Инжиниринг Данных
В посте, товарищ рассказал, как они круто выкинули Табло Север и стали использовать Slack бота + GenAI, чтобы отвечать на вопросы пользователей. Само собой разумеется, что они пофиксили семантический слой, определили метрики, позаботились о качестве данных.…
👍8😁4❤2
О каталоге Greenplum (1)
В сообществах Greenplum обсуждают хабростатью.
Я такой себе Greenplum DBA, но позволю себе небольшой коментарий.
На самом деле, статью надо разбивать на 2 части. Первая про проблему мелких файлов в лейкхаусе, а точнее, мелких объектов в S3, которые генерит любой формат с дельтой. Вторая про проблему распухания каталога в Гринпламе.
В чем суть. Колоночный формат в классической MPP СУБД (Greenplum, Clickhouse, Vertica etc) кладет в файловую систему 1 файлик на каждую колонку каждой таблицы. В случае партиционированной таблицы, это умножается еще и на количество партиций. В случае гринплама сюда же прибавим логические шарды-сегменты, и их зеркала, которые еще умножают число файлов на свой фактор параллелизма. Если таблицы широкие и партиций много, то файликов становится неприлично много. Когда-то кластер от такого начинает страдать.
Конкретно в Гринпламе за этим огромным зоопарком следит такая штука, как системный каталог. Это, по сути, набор индексированных постгресовых таблиц на мастер-сегменте. С помощью этих таблиц сама СУБД узнает, где у нее чего и сколько лежит. И эта же структура используется при планировании пользовательских запросов.
Коллеги описывают ситуацию, когда они делали множество 100-колоночных таблиц и много тысяч партиций к ним. Всего в БД оказывались десятки миллионов объектов и миллиарды строк в каталоге, которые их описывают. Объем служебной информации перевалил за 10 ТБ (!). И надо понимать, что при планировании каждого запроса кластер вынужден лопатить эти 10 ТБ просто для того чтобы понять, какие файлы ему читать для ответа на SQL.
Ситуация слегка доведена до абсурда, но весьма поучительная. Если вы эксплуатируете большой Greenplum, то каталог, его объем и его здоровье становятся одной из ваших главных головных болей.
Продолжение
В сообществах Greenplum обсуждают хабростатью.
Я такой себе Greenplum DBA, но позволю себе небольшой коментарий.
На самом деле, статью надо разбивать на 2 части. Первая про проблему мелких файлов в лейкхаусе, а точнее, мелких объектов в S3, которые генерит любой формат с дельтой. Вторая про проблему распухания каталога в Гринпламе.
В чем суть. Колоночный формат в классической MPP СУБД (Greenplum, Clickhouse, Vertica etc) кладет в файловую систему 1 файлик на каждую колонку каждой таблицы. В случае партиционированной таблицы, это умножается еще и на количество партиций. В случае гринплама сюда же прибавим логические шарды-сегменты, и их зеркала, которые еще умножают число файлов на свой фактор параллелизма. Если таблицы широкие и партиций много, то файликов становится неприлично много. Когда-то кластер от такого начинает страдать.
Конкретно в Гринпламе за этим огромным зоопарком следит такая штука, как системный каталог. Это, по сути, набор индексированных постгресовых таблиц на мастер-сегменте. С помощью этих таблиц сама СУБД узнает, где у нее чего и сколько лежит. И эта же структура используется при планировании пользовательских запросов.
Коллеги описывают ситуацию, когда они делали множество 100-колоночных таблиц и много тысяч партиций к ним. Всего в БД оказывались десятки миллионов объектов и миллиарды строк в каталоге, которые их описывают. Объем служебной информации перевалил за 10 ТБ (!). И надо понимать, что при планировании каждого запроса кластер вынужден лопатить эти 10 ТБ просто для того чтобы понять, какие файлы ему читать для ответа на SQL.
Ситуация слегка доведена до абсурда, но весьма поучительная. Если вы эксплуатируете большой Greenplum, то каталог, его объем и его здоровье становятся одной из ваших главных головных болей.
Продолжение
Хабр
Проблема маленьких файлов. Оценка замедления S3 и проблем HDFS и Greenplum при работе c ними
Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам...
👍6✍3💯3
О каталоге Greenplum (2)
Начало
Какая мораль у этой статьи про распухшие каталоги Гринплама.
Следите, следите и еще раз следите за вашим каталогом!
Бытовые рекомендации.
1️⃣ Объем pg_catalog и его динамику - на мониторинг если еще не.
2️⃣ Не жестите с параллелизмом сегментов. 2-3 праймари на большую ВМ или даже железный сегмент-сервер вполне ОК. Эта же рекомендация поможет легко проглатывать пики параллелизма нагрузки и упростит настройку ресурсных групп.
3️⃣ Не жестите с партициями. Схлопнуть где-то партиции с дня до месяца - это нормально и оправдано. Проще где-то поднять лишние данные с дисков сегментов в некоторых запросах, чем нагружать каталог на мастере, который нужен при вообще каждом запросе
4️⃣ Вакуум таблиц каталога - первейшая задача. А также реиндексы и т.д. Это тяжелая операция, которая блокирует кластер, поэтому многие ее не делают - неудобно и пользователи негодуют. Но надо!
5️⃣ ETL, где по любому чиху работают с партициями на удаление/замену, сильно нагружает каталог. pg_attribute все еще постгресовая таблица, подверженная блоату и расдуванию индеков. А вы из нее удаляете-добавляете строки сотнями на каждый чих. Просто сделайте Trucate insert и не мучайте беднягу. То же с созданием и удалением различных временных объектов.
6️⃣ Мелкие таблицы проще сделать строчными, а не колоночными. То же и со временными. Будет одна запись на таблицу, а не на колонку таблицы.
Начало
Какая мораль у этой статьи про распухшие каталоги Гринплама.
Следите, следите и еще раз следите за вашим каталогом!
Бытовые рекомендации.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
О каталоге Greenplum (1)
В сообществах Greenplum обсуждают хабростатью.
Я такой себе Greenplum DBA, но позволю себе небольшой коментарий.
На самом деле, статью надо разбивать на 2 части. Первая про проблему мелких файлов в лейкхаусе, а точнее, мелких…
В сообществах Greenplum обсуждают хабростатью.
Я такой себе Greenplum DBA, но позволю себе небольшой коментарий.
На самом деле, статью надо разбивать на 2 части. Первая про проблему мелких файлов в лейкхаусе, а точнее, мелких…
👍10✍4
О каталоге Greenplum (3)
Насколько реально может распухать количество файлов. Пример относительно небольшого облачного кластера на 8 ТБ полезных сжатых данных и 48 сегментов.
Без малого 100 млн. файлов!
О каталоге данных
Первая часть
Вторая часть
Насколько реально может распухать количество файлов. Пример относительно небольшого облачного кластера на 8 ТБ полезных сжатых данных и 48 сегментов.
Без малого 100 млн. файлов!
О каталоге данных
Первая часть
Вторая часть
👍6🔥4
При написании материалов и статей
Anonymous Poll
68%
Greenplum, Iceberg, Lakehouse
2%
Гринплам, Айсберг, Лейкхаус
30%
Да все равно
❤5😁4🤔2👌1🐳1
Приветствую всех новоприбывших! Спасибо что присоединились!
В предыдущих сериях про Лейкхаус или плейлист полезных видео.
Первое. Вебинар о плюсах подхода лейкхауса + воркшоп как поднять Iceberg + Trino в облаке. Несколько устарел, так как добавилось много новых фич, но суть осталась.
https://vkvideo.ru/video-164978780_456239621
Второе. Беседа о платформах данных с Вадимом Беловым - руководителем дата платформы Х5.
https://vkvideo.ru/video-228742675_456239026
Третье. Беседа с Алексеем Рыбаком, devhands.io.
https://vkvideo.ru/video-228742675_456239027
Четвертое. Доклад на Открытых Системах 2025 - «Лейкхаус: от хайпа до эксплуатации»
https://vkvideo.ru/video-228742675_456239024
Пятое - в среду 3 сентября залезем под капот айсбергу и посмотрим, как он сделан и почему о нем столько говорят.
Подпишитесь на канал - все записи вебинаров будут тут, если не сможете посмотреть в онлайне.
Также (я узнал) до сих пор работает заявочная на бонус для тестов облачного лейкхауса от ВК. Можно получить довольно много кредитов на тесты
https://cloud.vk.com/promopage/vk-data-lakehouse/
В предыдущих сериях про Лейкхаус или плейлист полезных видео.
Первое. Вебинар о плюсах подхода лейкхауса + воркшоп как поднять Iceberg + Trino в облаке. Несколько устарел, так как добавилось много новых фич, но суть осталась.
https://vkvideo.ru/video-164978780_456239621
Второе. Беседа о платформах данных с Вадимом Беловым - руководителем дата платформы Х5.
https://vkvideo.ru/video-228742675_456239026
Третье. Беседа с Алексеем Рыбаком, devhands.io.
https://vkvideo.ru/video-228742675_456239027
Четвертое. Доклад на Открытых Системах 2025 - «Лейкхаус: от хайпа до эксплуатации»
https://vkvideo.ru/video-228742675_456239024
Пятое - в среду 3 сентября залезем под капот айсбергу и посмотрим, как он сделан и почему о нем столько говорят.
Подпишитесь на канал - все записи вебинаров будут тут, если не сможете посмотреть в онлайне.
Также (я узнал) до сих пор работает заявочная на бонус для тестов облачного лейкхауса от ВК. Можно получить довольно много кредитов на тесты
https://cloud.vk.com/promopage/vk-data-lakehouse/
VK Видео
Поднимаем Data Lakehouse на основе Trino в облаке
11 февраля в 17:00 на вебинаре мы разберём, что такое Data Lakehouse и как эта архитектура объединит преимущества Data Lake и Data Warehouse, упрощая управление, хранения и анализ данных из различных источников в одном месте. Покажем, как новый облачный сервис…
🔥13👍5👌2😎2❤1
Комичусь
Никогда в этом канале не появится текста, сгенерированного нейронкой.
Признаюсь, в эпоху нейросетей я отчаянный ретроград. Не подумайте, нейросетями я пользуюсь активно и постоянно, но по большей части по узким техническим вопросам. Или грубо, как замену Google и Stack Overflow.
Но вот написание текстов я точно никогда не делегирую никаким нейро.
Большинство текстов я пишу сначала в блокноте от руки. Давно заметил, что этот метод хоть и долгий, но достигает нескольких положительных эффектов. Например, когда смотришь на текст на бумаге, яснее видишь его структуру. Написанное превращается из одномерного полотна в некую схему или канвас (скатерть). Не знаю, как объяснить точнее, но эффект словно переложишь сухое описание чего-то на Miro, draw.io или что-то подобное. Мы ведь не просто так пользуемся именно двумерными архитектурными схемами - наш мозг устроен так, что лучше воспринимает информацию именно в объемной форме.
Второй эффект - неизбежное переписывание. Так как никому не интересны мои каракули, то в какой-то момент надо сесть и переписать текст в электронную форму. А переписывание это неизбежная переделка и переосмысление. И вдруг ты видишь, что в тексте, который еще вчера считал идеальным, вторая глава не соответствует десятой, в процессе доказательства тезиса ты ушел в какое-то ненужное отступление, а переход от четвертой главы в пятую вообще неочевидный. Сразу помечаешь узкие места.
Ну и третий эффект - больше половины написанного вообще не стоит публикации. Вот просто взять и удалить.
На выходе получается долго, но пусть лучше я напишу меньше слов, но больше смысла.
Никогда в этом канале не появится текста, сгенерированного нейронкой.
Признаюсь, в эпоху нейросетей я отчаянный ретроград. Не подумайте, нейросетями я пользуюсь активно и постоянно, но по большей части по узким техническим вопросам. Или грубо, как замену Google и Stack Overflow.
Но вот написание текстов я точно никогда не делегирую никаким нейро.
Большинство текстов я пишу сначала в блокноте от руки. Давно заметил, что этот метод хоть и долгий, но достигает нескольких положительных эффектов. Например, когда смотришь на текст на бумаге, яснее видишь его структуру. Написанное превращается из одномерного полотна в некую схему или канвас (скатерть). Не знаю, как объяснить точнее, но эффект словно переложишь сухое описание чего-то на Miro, draw.io или что-то подобное. Мы ведь не просто так пользуемся именно двумерными архитектурными схемами - наш мозг устроен так, что лучше воспринимает информацию именно в объемной форме.
Второй эффект - неизбежное переписывание. Так как никому не интересны мои каракули, то в какой-то момент надо сесть и переписать текст в электронную форму. А переписывание это неизбежная переделка и переосмысление. И вдруг ты видишь, что в тексте, который еще вчера считал идеальным, вторая глава не соответствует десятой, в процессе доказательства тезиса ты ушел в какое-то ненужное отступление, а переход от четвертой главы в пятую вообще неочевидный. Сразу помечаешь узкие места.
Ну и третий эффект - больше половины написанного вообще не стоит публикации. Вот просто взять и удалить.
На выходе получается долго, но пусть лучше я напишу меньше слов, но больше смысла.
2👍26💯9❤🔥6⚡4