Forwarded from DLStories
С 2022 по 2023 годы я вела в МГУ курс по основам AI. У курса был формат, где на каждом занятии был один jupyter notebook с теорией и практикой, и мы по нему шли. Курс я уже не веду, но ноутбуки у меня остались, и мне нравится, как я их сделала. И у меня была мысль перевести их на английский, немного дополнить, причесать и выложить на GitHub как открытый курс "DL Intro". И я даже потихоньку начала это делать, вот репозиторий, там уже есть первые два урока (Intro to NN, PyTorch, Backprop).
Но вот недавно я думала о том, какой рисерч делать дальше после недавней статьи (статья кстати вот, чуть позже о ней тоже напишу), и мне стало интересно исследовать многообразия, которые составляют векторы-выходы разных слоев диффузионной модели. Я начала читать статьи и думать над тем, как вообще такое делают, и в итоге залезла куда-то в дифференциальную геометрию. И тут ко мне пришла очень гениальная мысль: а что если спросить у GPT объяснить мне то, что я не понимаю? Или спросить что-то типа "вот я хочу вот это понять про многообразие, могу ли я это сделать и как?"
Тут если вам кажется, что эта мысль ничерта не гениальна и все делают так каждый день, то я до этого момента GPT не использовала вообще. Ну, 3-4 раза за все время, может, и по каким-то совсем отвлеченным поводам. Чувстсвую себя бабкой, честное слово))
Так вот, на мои эти вопросы GPT выдала очень классные саммари и предложения, и для некоторых вещей даже код написала (и даже почти совсем правильный). И если веруться к разговору про курс: теперь я думаю о том, что, возможно, с помощью GPT можно довольно быстро собрать неплохой такой курс по чему угодно. Так-то объяснения по диффгеому GPT выдавала понятные и достаточно развернутые, а если чего-то не хватает, то можно попросить пояснить. И теперь думаю о том, насколько усилия по составлению курсов людьми из головы становятся оправданы)
Думаю, что этот курс я все-таки доделаю и выложу (снова, вот ссылка, буду рада звездочкам🙃 ), все же ноутбуки у меня в основном готовы, нужно их только причесать. Но в то же время пойду понимать, на что способна GPT, у меня теперь есть подписка на GPT и Claude, буду их мучить. Все-таки преподавание — это значительная часть моей работы, которую я люблю и хочу развивать, и хочется понимать, как делать эту работу лучше и быстрее. И не делать того, что можно не делать. Правда, в создании курсов я перфекционист, мне редко нравятся чужие объяснения, и я очень долго продумываю свои. Но посмотрим, может, GPT справится и удивит меня еще больше) Пока думаю, что, как минимум, в качестве помощника в составлении общей структуры курса и поиска дополнительных материалов GPT точно должна быть полезна.
Но вот недавно я думала о том, какой рисерч делать дальше после недавней статьи (статья кстати вот, чуть позже о ней тоже напишу), и мне стало интересно исследовать многообразия, которые составляют векторы-выходы разных слоев диффузионной модели. Я начала читать статьи и думать над тем, как вообще такое делают, и в итоге залезла куда-то в дифференциальную геометрию. И тут ко мне пришла очень гениальная мысль: а что если спросить у GPT объяснить мне то, что я не понимаю? Или спросить что-то типа "вот я хочу вот это понять про многообразие, могу ли я это сделать и как?"
Тут если вам кажется, что эта мысль ничерта не гениальна и все делают так каждый день, то я до этого момента GPT не использовала вообще. Ну, 3-4 раза за все время, может, и по каким-то совсем отвлеченным поводам. Чувстсвую себя бабкой, честное слово))
Так вот, на мои эти вопросы GPT выдала очень классные саммари и предложения, и для некоторых вещей даже код написала (и даже почти совсем правильный). И если веруться к разговору про курс: теперь я думаю о том, что, возможно, с помощью GPT можно довольно быстро собрать неплохой такой курс по чему угодно. Так-то объяснения по диффгеому GPT выдавала понятные и достаточно развернутые, а если чего-то не хватает, то можно попросить пояснить. И теперь думаю о том, насколько усилия по составлению курсов людьми из головы становятся оправданы)
Думаю, что этот курс я все-таки доделаю и выложу (снова, вот ссылка, буду рада звездочкам
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from gonzo-обзоры ML статей
Intuitive physics understanding emerges from self-supervised pretraining on natural videos
Quentin Garrido, Nicolas Ballas, Mahmoud Assran, Adrien Bardes, Laurent Najman, Michael Rabbat, Emmanuel Dupoux, Yann LeCun
Статья: https://arxiv.org/abs/2502.11831
Код: https://github.com/facebookresearch/jepa-intuitive-physics
Развитие темы про JEPA, world models и выучивание интуитивной физики из видео.
Интуитивная физика — довольно важный аспект нашей жизни и мышления. Мы ожидаем определённого поведения от объектов — что они не исчезают внезапно, не проходят через препятствия и не меняют произвольно цвета и формы. Подобные способности задокументированы не только у детёнышей человека, но и у приматов, морских млеков, врановых и так далее. Многие AI системы, превосходящие человеческий уровень в языковых или математических задачах, беспомощны в задачах, с которыми справится кошка, иллюстрируя парадокс Моравека.
Люди делали разные подходы к снаряду. Есть структурированные модели с вручную закодированными правилами про репрезентации разных объектов и их отношений. Есть пиксельные генеративные модели, занимающиеся реконструкцией будущих сенсорных входов по прошлым. Текущая работа исследует третий класс моделей, являющихся срединным путём между первыми двумя — собственно Лекуновскую JEPA, Joint Embedding Predictive Architectures (https://openreview.net/pdf?id=BZ5a1r-kVsf).
JEPA мы так и не разобрали, но в двух словах её идея в том, что предсказание надо делать не в пиксельном или ещё каком финальном пространстве, а в выученных внутренних абстрактных репрезентациях. В этом она близка к структурированным моделям. Но в отличие от них, ничего не кодируется, всё выучивается. В JEPA входные данные x (например, пиксели изображения) кодируются энкодером во внутреннюю репрезентацию Enc(x), далее предиктор делает предсказание репрезентации будущего входа y, возможно учитывая какую-то латентную переменную z, влияющую на предсказание (например, выбранное действие какого-то объекта в случае видео), и этот результат сравнивается с реальной репрезентацией следующего входа, Enc(y). Это, кстати, довольно сильно перекликается с другими моделями, например BYOL (https://t.me/gonzo_ML/562), там наличие отдельного предиктора тоже было очень важным для предотвращения коллапса. Энкодеры для x и y могут быть и разными. Преимущество в том, что не надо предсказывать каждую деталь выходного объекта y (с точностью до пикселя), ибо на этом уровне может быть очень много вариантов, разница между которыми не так важна.
JEPA не генеративная модель, она не может легко предсказывать y из x. У JEPA есть несколько развитий: Hierarchical JEPA (H-JEPA, тоже из оригинальной статьи), Image-based JEPA (I-JEPA, https://arxiv.org/abs/2301.08243), Video-JEPA (V-JEPA, https://arxiv.org/abs/2404.08471) и её свежий вариант Video JEPA with Variance-Covariance Regularization (VJ-VCR, https://arxiv.org/abs/2412.10925) — помните VICReg (https://t.me/gonzo_ML/590)?
В текущей работа исследуется V-JEPA, расширение модели на работу с видео и предсказание замаскированных частей кадров. В такой модели можно проверять выучивание интуитивной физики через фреймворк violation-of-expectation, получая меру несоответствия между предсказанием и реальным видео через измерение полученного “сюрприза”. Так же оценивают это и у живых существ (например, они дольше задерживают взгляд на неожиданных исходах).
V-JEPA точно так же как и обычная JEPA включает в себя энкодер и предиктор, оба нейросетевые. Энкодер строит репрезентацию видео, предиктор предсказывает репрезентацию искусственно замаскированной части видео.
Quentin Garrido, Nicolas Ballas, Mahmoud Assran, Adrien Bardes, Laurent Najman, Michael Rabbat, Emmanuel Dupoux, Yann LeCun
Статья: https://arxiv.org/abs/2502.11831
Код: https://github.com/facebookresearch/jepa-intuitive-physics
Развитие темы про JEPA, world models и выучивание интуитивной физики из видео.
Интуитивная физика — довольно важный аспект нашей жизни и мышления. Мы ожидаем определённого поведения от объектов — что они не исчезают внезапно, не проходят через препятствия и не меняют произвольно цвета и формы. Подобные способности задокументированы не только у детёнышей человека, но и у приматов, морских млеков, врановых и так далее. Многие AI системы, превосходящие человеческий уровень в языковых или математических задачах, беспомощны в задачах, с которыми справится кошка, иллюстрируя парадокс Моравека.
Люди делали разные подходы к снаряду. Есть структурированные модели с вручную закодированными правилами про репрезентации разных объектов и их отношений. Есть пиксельные генеративные модели, занимающиеся реконструкцией будущих сенсорных входов по прошлым. Текущая работа исследует третий класс моделей, являющихся срединным путём между первыми двумя — собственно Лекуновскую JEPA, Joint Embedding Predictive Architectures (https://openreview.net/pdf?id=BZ5a1r-kVsf).
JEPA мы так и не разобрали, но в двух словах её идея в том, что предсказание надо делать не в пиксельном или ещё каком финальном пространстве, а в выученных внутренних абстрактных репрезентациях. В этом она близка к структурированным моделям. Но в отличие от них, ничего не кодируется, всё выучивается. В JEPA входные данные x (например, пиксели изображения) кодируются энкодером во внутреннюю репрезентацию Enc(x), далее предиктор делает предсказание репрезентации будущего входа y, возможно учитывая какую-то латентную переменную z, влияющую на предсказание (например, выбранное действие какого-то объекта в случае видео), и этот результат сравнивается с реальной репрезентацией следующего входа, Enc(y). Это, кстати, довольно сильно перекликается с другими моделями, например BYOL (https://t.me/gonzo_ML/562), там наличие отдельного предиктора тоже было очень важным для предотвращения коллапса. Энкодеры для x и y могут быть и разными. Преимущество в том, что не надо предсказывать каждую деталь выходного объекта y (с точностью до пикселя), ибо на этом уровне может быть очень много вариантов, разница между которыми не так важна.
JEPA не генеративная модель, она не может легко предсказывать y из x. У JEPA есть несколько развитий: Hierarchical JEPA (H-JEPA, тоже из оригинальной статьи), Image-based JEPA (I-JEPA, https://arxiv.org/abs/2301.08243), Video-JEPA (V-JEPA, https://arxiv.org/abs/2404.08471) и её свежий вариант Video JEPA with Variance-Covariance Regularization (VJ-VCR, https://arxiv.org/abs/2412.10925) — помните VICReg (https://t.me/gonzo_ML/590)?
В текущей работа исследуется V-JEPA, расширение модели на работу с видео и предсказание замаскированных частей кадров. В такой модели можно проверять выучивание интуитивной физики через фреймворк violation-of-expectation, получая меру несоответствия между предсказанием и реальным видео через измерение полученного “сюрприза”. Так же оценивают это и у живых существ (например, они дольше задерживают взгляд на неожиданных исходах).
V-JEPA точно так же как и обычная JEPA включает в себя энкодер и предиктор, оба нейросетевые. Энкодер строит репрезентацию видео, предиктор предсказывает репрезентацию искусственно замаскированной части видео.
Forwarded from This is Data
Прежде чем искать подвох в данных, стоит понимать работу собственного процессора. Когнитивные искажения — это систематические ошибки в восприятии и мышлении во время обработки информации. Они ведут к ложным суждениям, основывающимся на личных предпочтениях и эмоциях, а не на объективных данных.
Одним из искажений мозга называют предвзятость подтверждения (Confirmation bias). Это склонность замечать доказательства собственной точки зрения и игнорировать данные, которые ей противоречат.
Допустим, дата-аналитик берется за задачу определить, какой канал привлечения клиентов наиболее эффективен. Он считает, что это соцсети. Убеждение искажает изначальную гипотезу в голове аналитика. Неосознанно он ставит задачу доказать, что соцсети эффективнее других каналов.
Дальнейшие действия заведомо необъективны. Он выбирает ключевые метрики, которые могли бы выявить преимущества соцсетей, и собирает исторические данные только за период, когда соцсети были особенно успешны. В итоге компания направляет больше средств в соцсети, не зная реальной рентабельности каждого канала.
Реальность многогранна. Мозг не в состоянии обработать всю информацию о мире. Чтобы не сойти с ума, он научился на основе кусочков данных формировать обобщающие убеждения. Они работают как фильтры, через которые информация попадает (или не попадает) в мозг на обработку. Предвзятость — не бага, а фича, экономящая время и энергию. Но то, что помогает выживать, мешает анализировать данные.
Чтобы быть менее предвзятым, попробуй:
1️⃣ Четко сформулировать вопрос бизнеса, гипотезу и цель сбора данных. Выработай привычки всегда допускать, что твои убеждения повлияли на результат.
2️⃣ Растождествить себя с точкой зрения. Задай себе вопросы: почему я так считаю? Основываюсь ли я на фактах?
3️⃣ Сыграть в игру: если бы я был не прав, какие факты могли указать на это? Ищи доказательства, опровергающие твое убеждение. Можно позвать коллегу-оппонента и выслушать его доводы.
#искажения
Одним из искажений мозга называют предвзятость подтверждения (Confirmation bias). Это склонность замечать доказательства собственной точки зрения и игнорировать данные, которые ей противоречат.
Допустим, дата-аналитик берется за задачу определить, какой канал привлечения клиентов наиболее эффективен. Он считает, что это соцсети. Убеждение искажает изначальную гипотезу в голове аналитика. Неосознанно он ставит задачу доказать, что соцсети эффективнее других каналов.
Дальнейшие действия заведомо необъективны. Он выбирает ключевые метрики, которые могли бы выявить преимущества соцсетей, и собирает исторические данные только за период, когда соцсети были особенно успешны. В итоге компания направляет больше средств в соцсети, не зная реальной рентабельности каждого канала.
Реальность многогранна. Мозг не в состоянии обработать всю информацию о мире. Чтобы не сойти с ума, он научился на основе кусочков данных формировать обобщающие убеждения. Они работают как фильтры, через которые информация попадает (или не попадает) в мозг на обработку. Предвзятость — не бага, а фича, экономящая время и энергию. Но то, что помогает выживать, мешает анализировать данные.
Чтобы быть менее предвзятым, попробуй:
1️⃣ Четко сформулировать вопрос бизнеса, гипотезу и цель сбора данных. Выработай привычки всегда допускать, что твои убеждения повлияли на результат.
2️⃣ Растождествить себя с точкой зрения. Задай себе вопросы: почему я так считаю? Основываюсь ли я на фактах?
3️⃣ Сыграть в игру: если бы я был не прав, какие факты могли указать на это? Ищи доказательства, опровергающие твое убеждение. Можно позвать коллегу-оппонента и выслушать его доводы.
#искажения
Forwarded from topdatalab (Roman Zykov)
Про AI автоматизацию в кодинге!
Моя задача проста — писать код меньше, а делать больше.
Что использую я:
1. Github Copilot Pro — очень удобно быстро что-то поправить.
Доступны разные модели, в том числе Sonnet 3.7.
2. CLINE + DeepSeek API — дешево, у меня даже получалось что-то сделать в полностью автоматическом режиме.
Потом DeepSeek стал очень популярным, и его API временно перестало работать.
Сейчас всё вернулось, но API работает медленно.
3. Мой бот дата инженера:
https://chatgpt.com/g/g-67dbef1047b48191951a514758f9ffc5-data-engineer-topdatalab
Думал про популярный Cursor, пока не прочитал сравнение:
👉 Сравнение Cursor vs CLine на Reddit
Кратко:
— Окно контекста больше у CLINE
— Нет API ограничений
— Но стоит дороже
⸻
Сейчас изучаю:
📘 Прокачка промптов в CLine
Хочу добиться ещё большей автоматизации в больших проектах! 🚀
Моя задача проста — писать код меньше, а делать больше.
Что использую я:
1. Github Copilot Pro — очень удобно быстро что-то поправить.
Доступны разные модели, в том числе Sonnet 3.7.
2. CLINE + DeepSeek API — дешево, у меня даже получалось что-то сделать в полностью автоматическом режиме.
Потом DeepSeek стал очень популярным, и его API временно перестало работать.
Сейчас всё вернулось, но API работает медленно.
3. Мой бот дата инженера:
https://chatgpt.com/g/g-67dbef1047b48191951a514758f9ffc5-data-engineer-topdatalab
Думал про популярный Cursor, пока не прочитал сравнение:
👉 Сравнение Cursor vs CLine на Reddit
Кратко:
— Окно контекста больше у CLINE
— Нет API ограничений
— Но стоит дороже
⸻
Сейчас изучаю:
📘 Прокачка промптов в CLine
Хочу добиться ещё большей автоматизации в больших проектах! 🚀
Forwarded from it пингвин | data engineer
Недавний пост про джоины набрал много просмотров и репостов. Значит такая информация интересна.
Продолжим наваливать базу 🤝
Популярные вопросы с собесов (lvl junior):
1) В какой последовательности БД на самом деле выполняет команды запроса:
Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода
Более удобный вид:
2) UNION ALL vs UNION - в чем разница?
UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные
UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи
Также могут дать простую задачку:
Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15
3) Отличие UPDATE TABLE от ALTER TABLE.
Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят😄
UPDATE TABLE:
• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.
ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу
Подскажите плз вам интересна эта тема? Предлагайте свои варианты почему можно навалить базы?
#Вопросы_с_собесов #база #sql #jun
Продолжим наваливать базу 🤝
Популярные вопросы с собесов (lvl junior):
1) В какой последовательности БД на самом деле выполняет команды запроса:
select distinct
from
join
where
group by
having
order by
limit
Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода
Более удобный вид:
FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT
2) UNION ALL vs UNION - в чем разница?
UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные
UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи
Также могут дать простую задачку:
Даны таблицы T1(col1, col2), T2(col1, col3).
Наполнение таблиц:
T1
(13, 15)
(13, 15)
(13, 15)
T2
(13, 15)
(13, 14)
Будет ли работать запрос? Если будет работать, то сколько строк вернет?
SELECT * FROM T1
UNION
SELECT * FROM T2
Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15
3) Отличие UPDATE TABLE от ALTER TABLE.
Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят
UPDATE TABLE:
• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.
ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу
Подскажите плз вам интересна эта тема? Предлагайте свои варианты почему можно навалить базы?
#Вопросы_с_собесов #база #sql #jun
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
Тренировки по алгоритмам от Яндекса
https://yandex.ru/yaintern/training/algorithm-training
После регистрации приходит письмо с подготовительными лекциями на YT https://youtube.com/playlist?list=PL6Wui14DvQPz_vzmNVOYBRqML6l51lP0G&si=FdTT_WhXPNZnOx46
https://yandex.ru/yaintern/training/algorithm-training
После регистрации приходит письмо с подготовительными лекциями на YT https://youtube.com/playlist?list=PL6Wui14DvQPz_vzmNVOYBRqML6l51lP0G&si=FdTT_WhXPNZnOx46
Тренировки по алгоритмам от Яндекса
Новый сезон — новые задачи и форматы
Forwarded from что-то на инженерном
Основные алгоритмы джойнов
Next level для тех, кто освоил типы джойнов, и теперь готов к оптимизации своих запросов 😎
Ниже приведены ключевые алгоритмы джойнов, используемые в реляционных СУБД и распределенных системах (Spark, Hadoop). Каждый из них решает определенные задачи в зависимости от объема данных, их структуры и инфраструктуры.
▫️Nested Loop Join - для каждой строки левой таблицы сканируется вся правая таблица (вложенные циклы).
— подходит для очень маленьких таблиц (до 1 тыс. строк)
— используется в SQLite, PostgreSQL для простых запросов
— простая реализация
— не требует сортировки или индексов
— сложность O(N*M) → неприменим для больших данных.
▫️Hash Join - состоит из двух фаз:
Build Phase: создается хеш-таблица для меньшей таблицы.
Probe Phase: большая таблица итерируется, и ключи ищутся в хеш-таблице.
— используется, если одна таблица помещается в память (справочники, малые датасеты), например в PostgreSQL для джойна пользователей и заказов.
— быстрый поиск за счет хешей → O(N + M).
— не требует сортировки.
— требует много памяти.
— неэффективен для skewed-ключей.
▫️Sort-Merge Join - сначала обе таблицы сортируются по ключу джойна. Далее происходит слияние отсортированных данных (как в алгоритме двух указателей).
— подходит для больших таблиц, которые нельзя броадкастить, и если данные уже отсортированы (например, партиционированы по дате).
— стабильная работа на больших данных.
— минимизирует использование памяти.
— дорогая сортировка → O(N log N + M log M)
— не подходит для skewed data.
▫️Broadcast Join (Map-Side Join) - маленькая таблица рассылается на все ноды кластера. Джойн выполняется локально на каждой ноде без Shuffle.
— используется, если маленькая таблица ≤ 10% памяти ноды (справочники, конфигурации), например для джойна логов и справочника стран на spark.
— нет Shuffle → экономия сети.
— максимальная скорость для маленьких таблиц.
— риск OOM, если таблица слишком большая.
▫️Shuffle Hash Join - обе таблицы перемешиваются (Shuffle) по ключу. На каждой ноде строится хеш-таблица для одной из таблиц.
— подходит для больших таблиц, когда одна из них после фильтрации помещается в память.
— быстрее Sort-Merge для средних данных.
— риск spill на диск при нехватке памяти.
▫️Bucket Join - данные предварительно разбиваются на бакеты по ключу, затем джоин выполняется между соответствующими бакетами. Подходит для частых джойнов по одному ключу (ETL-пайплайны).
▫️Skew Join - добавление случайного префикса (соли) к «тяжелым» ключам для распределения нагрузки. Далее происходит динамическое разбиение: дробление партиций с skewed-ключами. Подходит для данных с сильным перекосом (например, 80% записей по одному ключу).
▫️Grace Hash Join - комбинация Hash Join и внешней сортировки. Если хеш-таблица не влезает в память, данные разбиваются на партиции и обрабатываются по частям. Подходит для очень больших таблиц, которые не помещаются в память.
❔Как выбрать алгоритм?
1 — смотрим на размер данных:
Небольшая таблица → Broadcast Join
Большие таблицы → Sort-Merge или Shuffle Hash
2 — смотрим на структуру данных:
Отсортированы → Sort-Merge
Skewed-ключи → Skew Join
3 — инфраструктура:
Spark → используйте хинты (BROADCAST, MERGE).
Реляционная СУБД → опирайтесь на планировщик и индексы.
❕Запомнить:
— Nested Loop и Hash Join - база для СУБД.
— Broadcast и Sort-Merge - основа для распределенных систем.
— Всегда анализируйте план выполнения (explain в SQL, df.explain() в Spark) + метрики (память, сеть).
Next level для тех, кто освоил типы джойнов, и теперь готов к оптимизации своих запросов 😎
Ниже приведены ключевые алгоритмы джойнов, используемые в реляционных СУБД и распределенных системах (Spark, Hadoop). Каждый из них решает определенные задачи в зависимости от объема данных, их структуры и инфраструктуры.
▫️Nested Loop Join - для каждой строки левой таблицы сканируется вся правая таблица (вложенные циклы).
— подходит для очень маленьких таблиц (до 1 тыс. строк)
— используется в SQLite, PostgreSQL для простых запросов
— простая реализация
— не требует сортировки или индексов
— сложность O(N*M) → неприменим для больших данных.
▫️Hash Join - состоит из двух фаз:
Build Phase: создается хеш-таблица для меньшей таблицы.
Probe Phase: большая таблица итерируется, и ключи ищутся в хеш-таблице.
— используется, если одна таблица помещается в память (справочники, малые датасеты), например в PostgreSQL для джойна пользователей и заказов.
— быстрый поиск за счет хешей → O(N + M).
— не требует сортировки.
— требует много памяти.
— неэффективен для skewed-ключей.
▫️Sort-Merge Join - сначала обе таблицы сортируются по ключу джойна. Далее происходит слияние отсортированных данных (как в алгоритме двух указателей).
— подходит для больших таблиц, которые нельзя броадкастить, и если данные уже отсортированы (например, партиционированы по дате).
— стабильная работа на больших данных.
— минимизирует использование памяти.
— дорогая сортировка → O(N log N + M log M)
— не подходит для skewed data.
▫️Broadcast Join (Map-Side Join) - маленькая таблица рассылается на все ноды кластера. Джойн выполняется локально на каждой ноде без Shuffle.
— используется, если маленькая таблица ≤ 10% памяти ноды (справочники, конфигурации), например для джойна логов и справочника стран на spark.
— нет Shuffle → экономия сети.
— максимальная скорость для маленьких таблиц.
— риск OOM, если таблица слишком большая.
▫️Shuffle Hash Join - обе таблицы перемешиваются (Shuffle) по ключу. На каждой ноде строится хеш-таблица для одной из таблиц.
— подходит для больших таблиц, когда одна из них после фильтрации помещается в память.
— быстрее Sort-Merge для средних данных.
— риск spill на диск при нехватке памяти.
▫️Bucket Join - данные предварительно разбиваются на бакеты по ключу, затем джоин выполняется между соответствующими бакетами. Подходит для частых джойнов по одному ключу (ETL-пайплайны).
▫️Skew Join - добавление случайного префикса (соли) к «тяжелым» ключам для распределения нагрузки. Далее происходит динамическое разбиение: дробление партиций с skewed-ключами. Подходит для данных с сильным перекосом (например, 80% записей по одному ключу).
▫️Grace Hash Join - комбинация Hash Join и внешней сортировки. Если хеш-таблица не влезает в память, данные разбиваются на партиции и обрабатываются по частям. Подходит для очень больших таблиц, которые не помещаются в память.
❔Как выбрать алгоритм?
1 — смотрим на размер данных:
Небольшая таблица → Broadcast Join
Большие таблицы → Sort-Merge или Shuffle Hash
2 — смотрим на структуру данных:
Отсортированы → Sort-Merge
Skewed-ключи → Skew Join
3 — инфраструктура:
Spark → используйте хинты (BROADCAST, MERGE).
Реляционная СУБД → опирайтесь на планировщик и индексы.
❕Запомнить:
— Nested Loop и Hash Join - база для СУБД.
— Broadcast и Sort-Merge - основа для распределенных систем.
— Всегда анализируйте план выполнения (explain в SQL, df.explain() в Spark) + метрики (память, сеть).
Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
3 ресурса для освоения GIT с интерактивными заданиями
https://learngitbranching.js.org/?locale=ru_RU - Learn Git Branching
Интерактивный тренажер, позволяющий визуализировать и отрабатывать команды Git в режиме реального времени. Подходит как для новичков, так и для опытных пользователей.
https://git-school.github.io/visualizing-git/ - Visualizing Git
Веб-приложение, которое наглядно демонстрирует, как различные команды Git влияют на структуру коммитов, помогая лучше понять внутренние процессы системы контроля версий.
https://ohmygit.org/ - Открытая игра, обучающая Git с помощью визуализации внутренних структур репозиториев в реальном времени. Имеет интерфейс в виде игровых карт для запоминания команд и интегрированный терминал для выполнения произвольных команд Git.
https://learngitbranching.js.org/?locale=ru_RU - Learn Git Branching
Интерактивный тренажер, позволяющий визуализировать и отрабатывать команды Git в режиме реального времени. Подходит как для новичков, так и для опытных пользователей.
https://git-school.github.io/visualizing-git/ - Visualizing Git
Веб-приложение, которое наглядно демонстрирует, как различные команды Git влияют на структуру коммитов, помогая лучше понять внутренние процессы системы контроля версий.
https://ohmygit.org/ - Открытая игра, обучающая Git с помощью визуализации внутренних структур репозиториев в реальном времени. Имеет интерфейс в виде игровых карт для запоминания команд и интегрированный терминал для выполнения произвольных команд Git.
learngitbranching.js.org
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
Forwarded from что-то на инженерном
Как продакт выбирает инженера, часть 2
На прошлой неделе был пост-интервью с Product Owner о том, как он выбирает инженеров в свою команду. Он собрал много реакций и репостов, поэтому мы решили сделать еще один совместный пост🔥
Как устроен процесс отбора резюме инженеров?
1. Сейчас, когда направление разрослось, появилась возможность переложить большую часть процесса отбора на техлида. PO подключается только на последнем этапе собеседования. Раньше приходилось заниматься самому. В любом случае вначале назначенный на вакансию рекрутер делает первичный отбор резюме в соответствии с требованиями, в основном с HH. Сама компания выкладывать вакансию в открытый доступ не любит: слишком много шлака летит в ответ. Пару раз мне приходилось участвовать в отборе резюме на HH cовместно с рекрутером чтобы откалибровать требования - адская работа.
2. Инициатор вакансии (техлид) по каждому резюме дает обратную связь ректрутеру. С успешными рекрутер должен договориться о собеседовании, по неуспешным - принять к сведению комментарии (хочется в это верить)
3. Если случился матч, техлид проводит интервью с кандидатом на предмет соответствия требованиям и хард скиллов. Рекрутер присутствует и оценивает психологический портрет кандидата (вполуха, есть подозрение)
4. Если и тут возникла обоюдная любовь, состоится второе собеседование, со мной. Моя задача оценить насколько кандидат впишется в процесс и в команду, насколько готов работать над нашими задачами. Ну и с другой стороны рассказать кандидату, с чем придется столкнуться, ответить на вопросы. До этого этапа по моему опыту доходит 4-8 человек, до первого собеседования - в разы больше. Резюме просмотрено еще на порядок больше. Т.е. Найм - это в любом случае десятки часов руководителей, затягивать его или повторять слишком часто никому не хочется, проще поступиться частью требований.
5. Остался последний шаг перед оффером - проверка HR и СБ. Тут могут всплыть несоответствия в резюме, или уход со скандалом с прошлой работы, о котором кандидат умолчал, но на моей памяти с успешными кандидатами такого не было.
Что для тебя ред флаг/и в резюме?
Ред флагов у меня немного: 3-4 последних места работы продолжительностью год-два - вот, пожалуй, и все. С остальным можно жить.
Сейчас популярно накрутчивать опыт. Как ты к этому относишься и как распознаешь накрутчиков?
Если учебный опыт включен в резюме, это хорошо видно, тут либо тебе нужен джун, либо нет. В целом без опыта пройти все этапы собеседования на мидла без посторонней помощи нереально. Перед выставлением оффера документы проверяет Служба безопасности. Ну и испытательные срок никто не отменял. Не вижу в накручивании никакого смысла, только репутацию испортите.
Как ты реагируешь, когда твой оффер перебивают? (Ты предложил 300тыс, а соискатель говорит, что согласится только на 350)
Нередкий случай в целом. Если кандидат примерно одновременно дошел до афера в двух компаниях, хочет работать у нас, но в другой компании предлагают больше, можно и попросить уровнять. Процесс найма у нас построен так, что практически ни у кого нет личного интереса экономить на кандидате. Если деньги в бюджете на вакансии есть - в целом не жалко. А если запрос в бюджет не вписывается - не судьба. Но если в шорт-листе были еще кандидаты, параллельно запустится общение с ним, на всякий случай.
P.S. Пожалуй, этот разговор позволил мне взглянуть на работу менеджеров с другого ракурса. Поскольку со стороны инженеров я часто замечаю нападки в адрес некомпетентности PM/PO: что они неправильно проводят собесы, не разбираются досконально во всех технологиях, задают глупые вопросы. Да, менеджеры не всегда погружаются в технические нюансы так глубоко, как хотелось бы. Но их фокус - не в деталях технологий, а в сборке пазла, где каждая деталь - это запросы бизнеса, динамика команды и долгосрочные цели продукта.
А вам приходилось сталкиваться с неочевидными нюансами найма? 👀
На прошлой неделе был пост-интервью с Product Owner о том, как он выбирает инженеров в свою команду. Он собрал много реакций и репостов, поэтому мы решили сделать еще один совместный пост🔥
Как устроен процесс отбора резюме инженеров?
1. Сейчас, когда направление разрослось, появилась возможность переложить большую часть процесса отбора на техлида. PO подключается только на последнем этапе собеседования. Раньше приходилось заниматься самому. В любом случае вначале назначенный на вакансию рекрутер делает первичный отбор резюме в соответствии с требованиями, в основном с HH. Сама компания выкладывать вакансию в открытый доступ не любит: слишком много шлака летит в ответ. Пару раз мне приходилось участвовать в отборе резюме на HH cовместно с рекрутером чтобы откалибровать требования - адская работа.
2. Инициатор вакансии (техлид) по каждому резюме дает обратную связь ректрутеру. С успешными рекрутер должен договориться о собеседовании, по неуспешным - принять к сведению комментарии (хочется в это верить)
3. Если случился матч, техлид проводит интервью с кандидатом на предмет соответствия требованиям и хард скиллов. Рекрутер присутствует и оценивает психологический портрет кандидата (вполуха, есть подозрение)
4. Если и тут возникла обоюдная любовь, состоится второе собеседование, со мной. Моя задача оценить насколько кандидат впишется в процесс и в команду, насколько готов работать над нашими задачами. Ну и с другой стороны рассказать кандидату, с чем придется столкнуться, ответить на вопросы. До этого этапа по моему опыту доходит 4-8 человек, до первого собеседования - в разы больше. Резюме просмотрено еще на порядок больше. Т.е. Найм - это в любом случае десятки часов руководителей, затягивать его или повторять слишком часто никому не хочется, проще поступиться частью требований.
5. Остался последний шаг перед оффером - проверка HR и СБ. Тут могут всплыть несоответствия в резюме, или уход со скандалом с прошлой работы, о котором кандидат умолчал, но на моей памяти с успешными кандидатами такого не было.
Что для тебя ред флаг/и в резюме?
Ред флагов у меня немного: 3-4 последних места работы продолжительностью год-два - вот, пожалуй, и все. С остальным можно жить.
Сейчас популярно накрутчивать опыт. Как ты к этому относишься и как распознаешь накрутчиков?
Если учебный опыт включен в резюме, это хорошо видно, тут либо тебе нужен джун, либо нет. В целом без опыта пройти все этапы собеседования на мидла без посторонней помощи нереально. Перед выставлением оффера документы проверяет Служба безопасности. Ну и испытательные срок никто не отменял. Не вижу в накручивании никакого смысла, только репутацию испортите.
Как ты реагируешь, когда твой оффер перебивают? (Ты предложил 300тыс, а соискатель говорит, что согласится только на 350)
Нередкий случай в целом. Если кандидат примерно одновременно дошел до афера в двух компаниях, хочет работать у нас, но в другой компании предлагают больше, можно и попросить уровнять. Процесс найма у нас построен так, что практически ни у кого нет личного интереса экономить на кандидате. Если деньги в бюджете на вакансии есть - в целом не жалко. А если запрос в бюджет не вписывается - не судьба. Но если в шорт-листе были еще кандидаты, параллельно запустится общение с ним, на всякий случай.
P.S. Пожалуй, этот разговор позволил мне взглянуть на работу менеджеров с другого ракурса. Поскольку со стороны инженеров я часто замечаю нападки в адрес некомпетентности PM/PO: что они неправильно проводят собесы, не разбираются досконально во всех технологиях, задают глупые вопросы. Да, менеджеры не всегда погружаются в технические нюансы так глубоко, как хотелось бы. Но их фокус - не в деталях технологий, а в сборке пазла, где каждая деталь - это запросы бизнеса, динамика команды и долгосрочные цели продукта.
А вам приходилось сталкиваться с неочевидными нюансами найма? 👀
Forwarded from DevFM
Как я провожу синки с тимлидами
Недавно с коллегами заходил разговор за формат синков с тимлидами. Расскажу, как я провожу подобные встречи.
Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.
Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.
2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.
3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.
Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.
Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение
О применении ТГ для асинхронной работы была отдельная статья.
#teamwork #devfm
Недавно с коллегами заходил разговор за формат синков с тимлидами. Расскажу, как я провожу подобные встречи.
Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.
Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.
2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.
3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.
Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.
Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение
О применении ТГ для асинхронной работы была отдельная статья.
#teamwork #devfm
Telegram
DevFM
Ведение дел – мой опыт
Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.
Что уж…
Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.
Что уж…