Forwarded from Находки в опенсорсе
PEP765: больше никакой грязи в finally
Ссылка на PEP: https://peps.python.org/pep-0765
Одна из самых сломанных частей питона была пофикшена в 3.14
В чем проблема?
Ранее такой код вел себя крайне странно:
Так как из функции может быть только один
Или такой код:
Тут вообще жесть. У нас подавляется исключение без
Аналогично можно делать не только с
Такой код позволял создавать ошибки на ровном месте.
Как исправили?
Теперь такой код генерирует
Скоро – будет
Но, WPS, например, запрещал такое делать уже очень давно.
Как работает?
Сам патч очень маленький и простой:
1. Добавляет список текущего контекста
Храним внутри структуры вида:
2. При обходе дерева, добавляет нужные данные в текущий контекст: находимся ли мы в
3. Если находим
4. Внутри
Готово!
Обсуждение: вы знали про такую проблему? Стреляли так себе в ногу?
P.S. Пока писал пост, нашел багу в питоне и важную опечатку :)
| Поддержать | YouTube | GitHub | Чат |
Ссылка на PEP: https://peps.python.org/pep-0765
Одна из самых сломанных частей питона была пофикшена в 3.14
В чем проблема?
Ранее такой код вел себя крайне странно:
>>> def some():
... try:
... return 1
... finally:
... return 2
>>> some()
2
Так как из функции может быть только один
return, а код в finally всегда выполняется – то получаем, что получаем.Или такой код:
>>> def other():
... try:
... 1 / 0
... finally:
... return 2
>>> other()
2
Тут вообще жесть. У нас подавляется исключение без
except 🫠Аналогично можно делать не только с
return, но и с break / continue в циклах:
>>> def cycle():
... for i in range(2):
... try:
... i / 0
... finally:
... print(i)
... continue
... return 2
>>> cycle()
# prints: 0
# prints: 1
# returns: 2
Такой код позволял создавать ошибки на ровном месте.
Как исправили?
Теперь такой код генерирует
SyntaxWarning в 3.14:
>>> def some():
... try:
... return 1
... finally:
... return 2
<python-input-14>:5: SyntaxWarning: 'return' in a 'finally' block
Скоро – будет
SyntaxError, в будущих версиях.Но, WPS, например, запрещал такое делать уже очень давно.
Как работает?
Сам патч очень маленький и простой:
1. Добавляет список текущего контекста
_Py_c_array_t cf_finally; в ast_opt.cХраним внутри структуры вида:
typedef struct {
bool in_finally; // мы в `finally`?
bool in_funcdef; // мы в `def` или `async def`?
bool in_loop; // мы в `for`, `async for` или `while`?
} ControlFlowInFinallyContext;
2. При обходе дерева, добавляет нужные данные в текущий контекст: находимся ли мы в
finally, функции, цикле3. Если находим
return, break или continue, то выполняем проверку синтаксиса; вот код для return:
static int
before_return(_PyASTOptimizeState *state, stmt_ty node_)
{
if (state->cf_finally_used > 0) {
ControlFlowInFinallyContext *ctx = get_cf_finally_top(state);
// если нашли `return` в `finally`, но не во вложенной функции,
// то показываем warning пользователю:
if (ctx->in_finally && ! ctx->in_funcdef) {
if (!control_flow_in_finally_warning("return", node_, state)) {
return 0;
}
}
}
return 1;
}
4. Внутри
control_flow_in_finally_warning используем специальное АПИ для SyntaxWarning:
static int
control_flow_in_finally_warning(const char *kw, stmt_ty n, _PyASTOptimizeState *state)
{
PyObject *msg = PyUnicode_FromFormat("'%s' in a 'finally' block", kw);
if (msg == NULL) {
return 0;
}
int ret = _PyErr_EmitSyntaxWarning(msg, state->filename, n->lineno,
n->col_offset + 1, n->end_lineno,
n->end_col_offset + 1);
Py_DECREF(msg);
return ret < 0 ? 0 : 1;
}
Готово!
Обсуждение: вы знали про такую проблему? Стреляли так себе в ногу?
P.S. Пока писал пост, нашел багу в питоне и важную опечатку :)
| Поддержать | YouTube | GitHub | Чат |
Forwarded from Valuable AI / Валентин Малых
новая работа про токенизацию - SuperBPE - наводит на меня мысли о том, что история развивается по спирали; своим студентам я на первой лекции рассказываю про словосочетания (Multi-Word Expression), которые можно выделять из текста статистически; а потом использовать, например, для лучшего представления в TF-IDF (придуман в 1970-е)
прошло 50 лет, наши представления о токенизации сильно изменились, особенно в 2015 году, с адаптацией алгоритма сжатия ZIP к токенизации (это, собственно, и есть BPE), и теперь мы вышли на новый круг, чтобы снова учитывать словосочетания в токенизации...
прошло 50 лет, наши представления о токенизации сильно изменились, особенно в 2015 году, с адаптацией алгоритма сжатия ZIP к токенизации (это, собственно, и есть BPE), и теперь мы вышли на новый круг, чтобы снова учитывать словосочетания в токенизации...
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!