Forwarded from Архитектор Данных
Инсайды из «Разговоров на архитекторском» с Вадимом Беловым, Head of DMP X5.
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин куда-то в отдельную продовую систему.
2️⃣ Много разнородных потребителей - это реальность современного развитого ХД, с высокой ожидаемой ценностью для бизнеса. Проблема роста - в росте количества и разнообразия потребителей в большей степени, чем в объеме данных.
3️⃣ Стриминг и суб-минутные / секундные прогрузки данных: 10 лет назад мечта, сегодня - реальность и необходимость.
4️⃣ Транзакционность в аналитической системе - упрощает код, упрощает и ускоряет работу дата инженеров, понижает требуемую квалификацию дата инженера. Очень приятно работать со сложной системой так, будто это классическая СУБД с транзакциями.
Про лейкхаус
1️⃣ Ключевая технология, отличающая Lake и LakeHouse - формат данных и транзакционность.
2️⃣ Лейкхаус помогает убрать ненужные перегрузки данных из системы в систему. Причем надо понимать, что каждая продовая переливка из А в Б это а) стейджинговые и промежуточные слои, многократное дублирование данных, б) код, в) команда, которая поддерживает код и пайплайны, г) доп нагрузка на чтение в А и запись в Б. Если можно этого не делать, то получаем огромную экономию в лонг-ране.
3️⃣ «Старый» стек (Greenplum + Hadoop, + Clickhouse + …) - зоопарк. Лейкхаус - тоже зоопарк. Нельзя уйти от зоопарка технологий, но можно выбрать зоопарк себе по вкусу, в котором приятнее жить.
4️⃣ Развитие технологий спиральное. Сейчас виток разделения вычислений и хранения, рано или поздно сольемся обратно. Но текущий тренд - разделение.
5️⃣ Точно будем пилить свой мета-каталог. Опен-сорсные не устраивают по своей зрелости.
6️⃣ Тренд - умные метакаталоги. Нужен развитый RBAC на уровне каталога. Нужны умные метаданные, развитые кеши данных и мета-данных. Нужны элементы дата-гавернанс на уровне мета-каталога. Дата контракты на уровне метастора - в Gravitino уже есть.
Про экономику данных и миграцию
💯 Первые 100 ТБ мигрировали с Data Vault в Greenplum на Data Vault в Lakehouse за 1-2 месяца.
2️⃣ Лейкхаус дает больший оверхед на старте по железу, большие требования к сети. Но это окупается за счет того что одна команда работает со всеми юз-кейсами данных. Выгоднее купить больше железа, но обойтись одной командой разработки, одним релизным процессом, одной проверкой качества и т.д.
3️⃣ Также получаем более дешевое и быстрое развитие по росту объема и сложности данных. И технологическую модульность.
4️⃣ Эффективен путь RnD и пилотов. Пробуйте в облаках, где много готовых сервисов от многих вендоров. Пробуйте у себя на железе - для грамотного ДевОпса развернуть лейкхаус из доступных компонентов - тривиальная задача
5️⃣ Тестируйтесь на своих данных и своих задачах перед внедрением. Любые попугаи публичных тестов нерелевантны.
-----------------------------
Запись "Разговоров"
-----------------------------
Архитектор данных
-----------------------------
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин куда-то в отдельную продовую систему.
2️⃣ Много разнородных потребителей - это реальность современного развитого ХД, с высокой ожидаемой ценностью для бизнеса. Проблема роста - в росте количества и разнообразия потребителей в большей степени, чем в объеме данных.
3️⃣ Стриминг и суб-минутные / секундные прогрузки данных: 10 лет назад мечта, сегодня - реальность и необходимость.
4️⃣ Транзакционность в аналитической системе - упрощает код, упрощает и ускоряет работу дата инженеров, понижает требуемую квалификацию дата инженера. Очень приятно работать со сложной системой так, будто это классическая СУБД с транзакциями.
Про лейкхаус
1️⃣ Ключевая технология, отличающая Lake и LakeHouse - формат данных и транзакционность.
2️⃣ Лейкхаус помогает убрать ненужные перегрузки данных из системы в систему. Причем надо понимать, что каждая продовая переливка из А в Б это а) стейджинговые и промежуточные слои, многократное дублирование данных, б) код, в) команда, которая поддерживает код и пайплайны, г) доп нагрузка на чтение в А и запись в Б. Если можно этого не делать, то получаем огромную экономию в лонг-ране.
3️⃣ «Старый» стек (Greenplum + Hadoop, + Clickhouse + …) - зоопарк. Лейкхаус - тоже зоопарк. Нельзя уйти от зоопарка технологий, но можно выбрать зоопарк себе по вкусу, в котором приятнее жить.
4️⃣ Развитие технологий спиральное. Сейчас виток разделения вычислений и хранения, рано или поздно сольемся обратно. Но текущий тренд - разделение.
5️⃣ Точно будем пилить свой мета-каталог. Опен-сорсные не устраивают по своей зрелости.
6️⃣ Тренд - умные метакаталоги. Нужен развитый RBAC на уровне каталога. Нужны умные метаданные, развитые кеши данных и мета-данных. Нужны элементы дата-гавернанс на уровне мета-каталога. Дата контракты на уровне метастора - в Gravitino уже есть.
Про экономику данных и миграцию
2️⃣ Лейкхаус дает больший оверхед на старте по железу, большие требования к сети. Но это окупается за счет того что одна команда работает со всеми юз-кейсами данных. Выгоднее купить больше железа, но обойтись одной командой разработки, одним релизным процессом, одной проверкой качества и т.д.
3️⃣ Также получаем более дешевое и быстрое развитие по росту объема и сложности данных. И технологическую модульность.
4️⃣ Эффективен путь RnD и пилотов. Пробуйте в облаках, где много готовых сервисов от многих вендоров. Пробуйте у себя на железе - для грамотного ДевОпса развернуть лейкхаус из доступных компонентов - тривиальная задача
5️⃣ Тестируйтесь на своих данных и своих задачах перед внедрением. Любые попугаи публичных тестов нерелевантны.
-----------------------------
Запись "Разговоров"
-----------------------------
Архитектор данных
-----------------------------
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Запись стрима "Разговоры на Архитекторском" с Вадимом Беловым, X5.
-----------------------------
Архитектор данных
-----------------------------
-----------------------------
Архитектор данных
-----------------------------
Forwarded from DeepSchool
Ускоряем LLM на раз, два, три
Иметь личного ассистента на ноуте и запускать мощную модель локально — хорошо. Тратить огромные ресурсы на это — уже не очень.
В новой статье разбираем ключевые методы ускорения и обсуждаем, что действительно работает:
— фреймворки для инференса — какой выбрать, чтобы выжать максимум
— спекулятивное декодирование — почему это must-have для скорости
— квантование — как правильно применять и почему оно превратилось в «народный» метод ускорения
А ещё в статье мы вспоминаем базу — Flash-Attention, технологию, которая помогла развить популяризацию LLM в целом 🚀
Читайте по ссылке!
Иметь личного ассистента на ноуте и запускать мощную модель локально — хорошо. Тратить огромные ресурсы на это — уже не очень.
В новой статье разбираем ключевые методы ускорения и обсуждаем, что действительно работает:
— фреймворки для инференса — какой выбрать, чтобы выжать максимум
— спекулятивное декодирование — почему это must-have для скорости
— квантование — как правильно применять и почему оно превратилось в «народный» метод ускорения
А ещё в статье мы вспоминаем базу — Flash-Attention, технологию, которая помогла развить популяризацию LLM в целом 🚀
Читайте по ссылке!
DeepSchool
3 фишки для ускорения LLM - DeepSchool
Ускорение инференса LLM: фреймворки, квантование, оптимизация.
Forwarded from Dealer.AI
Рефлексия о работе в OpenAI или как из хаоса и атомарных действий рождается великое.
Ex сотрудник Codex рассказывает о своем опыте работы в OpenAI.
Советую почитать самостоятельно, если уж английский не ваше - перевод тут.
Выделю то, что именно интересно мне, в основном, это процессы, за остальным вэлкам, опять же, в полную версию.
1. Наличие моно-репо разработки, отсутствие коммуникаций в почте. Да, ребята общаются через мессенджер - Slack. Имеется многоуровневая система доступов, особенно, к чатам с фин. информацией. В почте почти нет коммуникации, автор буквально получал около 10 писем за все время. На сладкое разработка в одном огромном монорепозитории.
2. Процессы под лозунгом "bias to action". Формирование групп и команд идет по интересам и сразу в бой. Зачастую, годные идеи и их реализации просто интегрируют в более масштабный флоу к основной ветке. Отсюда возможность создания параллельно нескольких групп, делающих одну фичу по-своему, далее побеждает "сильнейший". Также это дает возможность расти тем, кто делает интересное/полезное хорошо и быстро, даже без возможности нормальной презентации. Вокруг таких успешных групп быстро далее формируется core команда для доведения до ума решения. Обычно все крутые фичи рождаются в рамках "мелких" исследований, это в т.ч. порождает порой огромные распределенные кусочки, которые важно соединить воедино. Отсюда и важны руководители.
3. Руководители исследовательских групп – «мини CEO». В рамках работы, при создании трека важная максимальная самостоятельность и принятие рисков. Поэтому лиды групп становятся мини-CEO, которые видят весь ландшафт работ, в т.ч. в соседних командах. Отмечается важность иметь хороших research engineering manager и PMов. Причём люди, занимающие данные позиции обладают открытым и широким взглядом, создавая впечатление что уже видели все. Но эта черта не мешает поддерживать команды, мотивировать на успех и минимально вмешиваться в реализацию. Такие руководители поощряют креатив и т. п., а не микроменеджерят, помогая и нанять лучших людей под задачу или ротировать их, а также дать выч. ресурсы.
Как следствие из п. 1-3, компания довольно гибкая и быстро может менять направление исследований и разработок. Все что не интересно, решенное и устарело, скорее всего, делаться не будет. Также это не дает возможности быть инертными и четко двигаться по плану/стратегии в отличии от конкурентов в Google и др. Руководители вовлечены в работу и не ждут квартального планирования и планового перераспределения в штат, подтягивая опять же быстро нужных людей. Какой к чёрту план, когда вы на острие технологий и все меняется молниеносно.
4. Важность оптимизации GPU. Работа с оптимизацией латенси вплоть до времени отклика на генерацию первого токена. Отмечается, что ресурсы GPU для создания одной нишевой функции Codex были сопоставимы по затратам со всем пайпом сбора и чистки данных логов клиентов.
5. Не забываем о социальной ответственности. Большое внимание уделяется практическим угрозам (например, разжиганию вражды, злоупотреблению технологиями, манипуляциям общественным мнением, созданию биологического оружия, проблемам самолечения и атакам методом инъекций запросов), нежели абстрактным рискам вроде интеллектуального скачка или стремлениях машин к власти. Однако это вовсе не означает, что вопросами гипотетических рисков никто не занимается — такие специалисты действительно существуют.
Интересно? Читайте полную версию и черпайте интересные моменты для себя. Жду от вас комментарии, что отметили именно вы.
Upd. Мне напомнило это все, кстати, рассказ разработчиков ChatGPT, как они сделали это. Когда Сэм пришел и попросил перед очередным собранием инвесторов удивить его, команда достала из широких штанин, что они делали с GPT3.5 (или 3). И это было оно. Сама сказал, накинуть на это GUI и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.
Ex сотрудник Codex рассказывает о своем опыте работы в OpenAI.
Советую почитать самостоятельно, если уж английский не ваше - перевод тут.
Выделю то, что именно интересно мне, в основном, это процессы, за остальным вэлкам, опять же, в полную версию.
1. Наличие моно-репо разработки, отсутствие коммуникаций в почте. Да, ребята общаются через мессенджер - Slack. Имеется многоуровневая система доступов, особенно, к чатам с фин. информацией. В почте почти нет коммуникации, автор буквально получал около 10 писем за все время. На сладкое разработка в одном огромном монорепозитории.
2. Процессы под лозунгом "bias to action". Формирование групп и команд идет по интересам и сразу в бой. Зачастую, годные идеи и их реализации просто интегрируют в более масштабный флоу к основной ветке. Отсюда возможность создания параллельно нескольких групп, делающих одну фичу по-своему, далее побеждает "сильнейший". Также это дает возможность расти тем, кто делает интересное/полезное хорошо и быстро, даже без возможности нормальной презентации. Вокруг таких успешных групп быстро далее формируется core команда для доведения до ума решения. Обычно все крутые фичи рождаются в рамках "мелких" исследований, это в т.ч. порождает порой огромные распределенные кусочки, которые важно соединить воедино. Отсюда и важны руководители.
3. Руководители исследовательских групп – «мини CEO». В рамках работы, при создании трека важная максимальная самостоятельность и принятие рисков. Поэтому лиды групп становятся мини-CEO, которые видят весь ландшафт работ, в т.ч. в соседних командах. Отмечается важность иметь хороших research engineering manager и PMов. Причём люди, занимающие данные позиции обладают открытым и широким взглядом, создавая впечатление что уже видели все. Но эта черта не мешает поддерживать команды, мотивировать на успех и минимально вмешиваться в реализацию. Такие руководители поощряют креатив и т. п., а не микроменеджерят, помогая и нанять лучших людей под задачу или ротировать их, а также дать выч. ресурсы.
Как следствие из п. 1-3, компания довольно гибкая и быстро может менять направление исследований и разработок. Все что не интересно, решенное и устарело, скорее всего, делаться не будет. Также это не дает возможности быть инертными и четко двигаться по плану/стратегии в отличии от конкурентов в Google и др. Руководители вовлечены в работу и не ждут квартального планирования и планового перераспределения в штат, подтягивая опять же быстро нужных людей. Какой к чёрту план, когда вы на острие технологий и все меняется молниеносно.
4. Важность оптимизации GPU. Работа с оптимизацией латенси вплоть до времени отклика на генерацию первого токена. Отмечается, что ресурсы GPU для создания одной нишевой функции Codex были сопоставимы по затратам со всем пайпом сбора и чистки данных логов клиентов.
5. Не забываем о социальной ответственности. Большое внимание уделяется практическим угрозам (например, разжиганию вражды, злоупотреблению технологиями, манипуляциям общественным мнением, созданию биологического оружия, проблемам самолечения и атакам методом инъекций запросов), нежели абстрактным рискам вроде интеллектуального скачка или стремлениях машин к власти. Однако это вовсе не означает, что вопросами гипотетических рисков никто не занимается — такие специалисты действительно существуют.
Интересно? Читайте полную версию и черпайте интересные моменты для себя. Жду от вас комментарии, что отметили именно вы.
Upd. Мне напомнило это все, кстати, рассказ разработчиков ChatGPT, как они сделали это. Когда Сэм пришел и попросил перед очередным собранием инвесторов удивить его, команда достала из широких штанин, что они делали с GPT3.5 (или 3). И это было оно. Сама сказал, накинуть на это GUI и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.
Forwarded from Tensor Banana
Wan2.2 A14B 3-шаговый воркфлоу для t2v, t2i, img2img и апскейла видео
- 3 шага подходят для малого числа кадров: от 1 до 65 при 720р. При 81+ кадре этого уже не хватает, будет цветной шум, надо больше шагов. Чем больше разрешение и число кадров - тем больше шагов. Для 480р трёх шагов хватит на 81 кадр.
- если виден цветной шум: увеличить силу лоры FusionX у обоих моделей, либо увеличить число шагов.
- фото лучше делать в разрешении 1920х1080 и 1080х1536. Детализация офигенная. Пример в хайрез: https://raw.githubusercontent.com/Mozer/comfy_stuff/refs/heads/main/output/ComfyUI_06056_.png
- Вертикальные фото/видео с высотой больше 1500 лучше не делать, будут искажения геометрии.
- в исходном воркфлоу от comfy anonymous стоят верные настройки для передачи шума между сэмплерами. В популярных на реддите воркфлоу на 4 шага - стоят неканонические зачения. В них страдает детализация и текстура кожи.
- малая модель на 5B мне не понравилась, похожа на 1.3b по качеству.
- странный факт: 5B работает в 24fps и A14B в 16fps
- промпты для видео брал с сайтов Вана: https://wan.video/explore и flow tv (Veo): https://labs.google/flow/tv/channels
- cсылки на Лоры (fusionx, lightxt2, smartphone) внутри воркфлоу.
- озвучку делал в mmaudio: https://huggingface.co/spaces/hkchengrex/MMAudio
- если не считать отсутствие звука и речи, то визуально ван 2.2 очень похож на veo3.
- с img2img прикольно переделывать аниме в реализм и обновлять графику старым играм (можно попроботь через video2video для старых игр). Регулировать силу исходной картинки приходится с помощью числа шагов и их соотношения на первом сэмплере.
- апскейл видео слегка меняет лицо. чем больше шагов тем чётче картинка, но дальше от оригинала. 1+2 и 1+3 шага - оптимальны.
- weight_dtype fp8e5m не работает на 3090 (шумит), используйте fp8_e4m3fn_fast
- старые лоры - работают.
Скорость на 3090:
- видео 1280x720 49 кадров, 1+2 шага: 6 минут с интерполяцией
- фото 1920х1088 2+2 шага: 1 минута
- video2video 480p 97 кадров 1+3 шага: 6 минут с интерполяцией
- на 16 гигах врам пойдет, но не надо ставить разрешение 720р и 121 кадр - иначе время генерации будет 14 часов.
- ещё ждём teaCache для скорости.
Примеры промптов:
- Икеа:
- Бабка и яма:
- куклы за столом:
мои воркфлоу для A14B: https://github.com/Mozer/comfy_stuff/tree/main/workflows/wan2.2
попробовать wan2.2 (i2v - бесплатно, долго; t2v - 10 кредитов): https://wan.video/generate
- 3 шага подходят для малого числа кадров: от 1 до 65 при 720р. При 81+ кадре этого уже не хватает, будет цветной шум, надо больше шагов. Чем больше разрешение и число кадров - тем больше шагов. Для 480р трёх шагов хватит на 81 кадр.
- если виден цветной шум: увеличить силу лоры FusionX у обоих моделей, либо увеличить число шагов.
- фото лучше делать в разрешении 1920х1080 и 1080х1536. Детализация офигенная. Пример в хайрез: https://raw.githubusercontent.com/Mozer/comfy_stuff/refs/heads/main/output/ComfyUI_06056_.png
- Вертикальные фото/видео с высотой больше 1500 лучше не делать, будут искажения геометрии.
- в исходном воркфлоу от comfy anonymous стоят верные настройки для передачи шума между сэмплерами. В популярных на реддите воркфлоу на 4 шага - стоят неканонические зачения. В них страдает детализация и текстура кожи.
- малая модель на 5B мне не понравилась, похожа на 1.3b по качеству.
- странный факт: 5B работает в 24fps и A14B в 16fps
- промпты для видео брал с сайтов Вана: https://wan.video/explore и flow tv (Veo): https://labs.google/flow/tv/channels
- cсылки на Лоры (fusionx, lightxt2, smartphone) внутри воркфлоу.
- озвучку делал в mmaudio: https://huggingface.co/spaces/hkchengrex/MMAudio
- если не считать отсутствие звука и речи, то визуально ван 2.2 очень похож на veo3.
- с img2img прикольно переделывать аниме в реализм и обновлять графику старым играм (можно попроботь через video2video для старых игр). Регулировать силу исходной картинки приходится с помощью числа шагов и их соотношения на первом сэмплере.
- апскейл видео слегка меняет лицо. чем больше шагов тем чётче картинка, но дальше от оригинала. 1+2 и 1+3 шага - оптимальны.
- weight_dtype fp8e5m не работает на 3090 (шумит), используйте fp8_e4m3fn_fast
- старые лоры - работают.
Скорость на 3090:
- видео 1280x720 49 кадров, 1+2 шага: 6 минут с интерполяцией
- фото 1920х1088 2+2 шага: 1 минута
- video2video 480p 97 кадров 1+3 шага: 6 минут с интерполяцией
- на 16 гигах врам пойдет, но не надо ставить разрешение 720р и 121 кадр - иначе время генерации будет 14 часов.
- ещё ждём teaCache для скорости.
Примеры промптов:
- Икеа:
Cinematic shot of a sunlit empty Scandinavian bedroom. A sealed IKEA box trembles, opens, and flat pack furniture assembles rapidly into a stylish IKEA bedroom with bed, table, chair and other furniture. fixed wide angle, lighting: natural warm with cool accents, room: Scandinavian bedroom, elements: IKEA box (logo visible), Start: empty room at the beginning, then box opens, furniture assembles precisely and rapidly, ending: calm, modern bedroom with yellow IKEA accent. Furniture at the end: bed with yellow throw, bedside tables, lamps, wardrobe, shelves, mirror, art, rug, curtains, reading chair, plants- Бабка и яма:
A TV news report from the streets of the Russian hinterland. The news anchor woman speaks into a microphone in Russian: "A huge pit has appeared in our city for three years now." At this time, in the background, a Russian grandmother with two heavy bags walks down the street and falls into a huge pit filled with water. The atmosphere is comical, with a deliberately serious tone of reporting. Photorealistic 4k 60fps video- куклы за столом:
In a dimly lit Victorian-style living room, lace curtains flutter gently. muppets toys (kermit and others) sit around a round table, their figures illuminated by flickering candlelight. A whisper makes the porcelain teacups tremble, and the eyes in the paintings shift uneasily. Each slow, deliberate stop-motion frame heightens the tension. The camera pans slowly to the right, capturing every subtle movement of the puppets, enhancing the eerie atmosphere. The furniture and decorations in the background are clearly detailed.мои воркфлоу для A14B: https://github.com/Mozer/comfy_stuff/tree/main/workflows/wan2.2
попробовать wan2.2 (i2v - бесплатно, долго; t2v - 10 кредитов): https://wan.video/generate
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
Отбор в Сбер на дата инженера (2025)
Сейчас идут последние часы скидки на наши новые карьерные курсы, которые стартуют уже завтра, и еще можно записаться.
Ниже рассказ выпускника нашего курса дата инженер. Далее текст слегка отредактирован.
Собесился в команду построения витрин данных для выявления подозрительных операций. По работе все стандартно — написание Spark приложений, раскладывать данные по 3 нормальной форме, делать так, чтобы все работало как часы и быстро.
Тестовое задание
Контеста не было, дали тест — SQL + немного Python.
SQL: задачи классические — подзапросы, оконки, группировки.
Пример: найти дату первой покупки клиента в сегменте "Премиум" и посчитать, сколько дней после этого он продолжал что-то там покупать.
Поспрашивали также про результаты джоины, ну т.е. на простых табличках прикинуть, сколько строк будет в каждом случае.
Python: попросили прочитать csv файл spark-ом и обработать — отсеять записи (файлы был уже в scd 2) и сделать итоговую группировку. Все это нужно было написать не через Spark SQL, а через DataFrame (спасибо, что не на скале)
Техническое интервью
Сначала — бэкграунд: чем занимался, с какими технологиями работал, какими задачами (интеграциями и витринами)
Потом пошли практические вопросы:
— Архитектура Airflow, что такое DAG, какие есть операторы и т.д.
— Как обеспечить идемпотентность в даге.
— Как лучше организовать пайплайн, чтобы рассчет витрин начинался сразу по прибытии данных, какие недостатки есть у каждого из способов.
Поболтали про Spark:
— Wide vs narrow трансформации, что такое rdd.
— Что может вызвать out-of-memory у executor.
— Как отладить тормозящую джобу: Spark UI, skew, spill в диск, настройка количества партиций.
Ну и под конец была небольшая задачка про то, как лучше построить обработку витрины, расчет которой нужно проводить от сегодняшней даты на глубину один год.
На нее быстро ответил, что лучше держать предагрегат, а потом считать реальное изменение за последние несколько дней. Кстати все входит в программу нашего курса дата инженер.
Результат
Через пару дней — оффер, все оказалось даже проще, чем ожидал, спасибо, что алгоритмы особо не спрашивали.
Еще один отзыв ниже.
@postypashki_old
Сейчас идут последние часы скидки на наши новые карьерные курсы, которые стартуют уже завтра, и еще можно записаться.
Ниже рассказ выпускника нашего курса дата инженер. Далее текст слегка отредактирован.
Собесился в команду построения витрин данных для выявления подозрительных операций. По работе все стандартно — написание Spark приложений, раскладывать данные по 3 нормальной форме, делать так, чтобы все работало как часы и быстро.
Тестовое задание
Контеста не было, дали тест — SQL + немного Python.
SQL: задачи классические — подзапросы, оконки, группировки.
Пример: найти дату первой покупки клиента в сегменте "Премиум" и посчитать, сколько дней после этого он продолжал что-то там покупать.
Поспрашивали также про результаты джоины, ну т.е. на простых табличках прикинуть, сколько строк будет в каждом случае.
Python: попросили прочитать csv файл spark-ом и обработать — отсеять записи (файлы был уже в scd 2) и сделать итоговую группировку. Все это нужно было написать не через Spark SQL, а через DataFrame (спасибо, что не на скале)
Техническое интервью
Сначала — бэкграунд: чем занимался, с какими технологиями работал, какими задачами (интеграциями и витринами)
Потом пошли практические вопросы:
— Архитектура Airflow, что такое DAG, какие есть операторы и т.д.
— Как обеспечить идемпотентность в даге.
— Как лучше организовать пайплайн, чтобы рассчет витрин начинался сразу по прибытии данных, какие недостатки есть у каждого из способов.
Поболтали про Spark:
— Wide vs narrow трансформации, что такое rdd.
— Что может вызвать out-of-memory у executor.
— Как отладить тормозящую джобу: Spark UI, skew, spill в диск, настройка количества партиций.
Ну и под конец была небольшая задачка про то, как лучше построить обработку витрины, расчет которой нужно проводить от сегодняшней даты на глубину один год.
На нее быстро ответил, что лучше держать предагрегат, а потом считать реальное изменение за последние несколько дней. Кстати все входит в программу нашего курса дата инженер.
Результат
Через пару дней — оффер, все оказалось даже проще, чем ожидал, спасибо, что алгоритмы особо не спрашивали.
Еще один отзыв ниже.
@postypashki_old
Forwarded from Тагир Анализирует
Совсем недавно я закончил Вышку. На втором курсе, когда генеративные модели стали набирать популярность, я начал использовать ChatGPT и другие ИИ-инструменты в учебе
Моя базовая позиция: в образовании, как и в других сферах, ИИ ускоряет работу и делает ее более эффективной, если грамотно его применять. Тут есть развилка:
Сценарий 1. Забрасываешь задачу, копируешь готовый ответ, не вникая в решение → материал не усваивается, ошибки не вылавливаются
Сценарий 2. Пошагово разбираешь решение, проверяешь логику, просишь примеры или объяснение «как 10-летнему ребенку» → тему понимаешь лучше, чем с дорогим репетитором
Некоторые курсы я не посещал, а только лишь сдавал домашки и экзамены. Презентации обычно были плохими и не воспринимались без лекций. Нужно было уметь быстро разобраться в сложном предмете с нуля за очень короткий срок
К некоторым экзаменам я готовился с нуля за 2-3 ночи, совмещая с фуллтайм работой. Я брал экзаменационные билеты и загружал их вместе с презентациями в ChatGPT – он составлял для меня короткую программу для подготовки к конкретному экзамену
Я просил использовать простые слова, приводить много примеров и подстраиваться под человека с нулевым бэкграундом. Так и сдавались многие предметы – в итоге часто получал оценки выше, чем одногруппники, ходившие на все занятия. Подобную историю видел и на Reddit
Метапромпт: «Собери краткий конспект по этим билетам: выдели ключевые определения и приведи по два примера к каждому вопросу»
Работа над курсовыми и дипломом тоже шла бодрее. Я просил ChatGPT набросать каркас исследования и структуру работы по пунктам, которые затем заполнял текстом и развивал сам. Вместо недели на выстраивание черновой схемы я за несколько часов получал выверенный план и уже вручную его шлифовал
Метапромпт: «Составь каркас дипломной работы по теме “_____”: введение, главы, выводы; для каждого раздела укажи цели, методы и примерный объем текста»
Когда доходило до экспериментов, валидировал свою логику у ChatGPT: где-то он советовал выбрать иной метод, где-то – увеличить выборку, а иногда – вообще отказаться от сомнительного теста
Метапромпт: «Проанализируй мой план эксперимента (ниже) и предложи улучшения»
Писал текст частями, и каждый фрагмент отправлял ИИ на проверку. ChatGPT ловил логические разрывы, терминологические огрехи и помогал упорядочить изложение. В этой статье рассказывают, почему такой подход к написанию работ эффективен
Метапромпт: «Проверь текст ниже на логические несостыковки, сложные обороты и повторения; дай правки списком»
Механическая работа вроде формирования списка литературы или поиск литературы для обзора тоже уходила к ИИ. Конечно, нужно было проверять, нет ли там выдуманных статей
Метапромпт: «Подбери 10 актуальных статей (2020+) по теме “_____”, дай корректные ссылки и краткое описание»
Но самый главный принцип, к которому я пришел с ChatGPT – задавать глупые вопросы. ИИ не осудит, не пристыдит и не скажет "мы это уже проходили". В образовательных целях подход очень эффективный. Постепенно приучился задавать такие вопросы и людям
Я не использовал ChatGPT в формате скопировал –> вставил, а пропускал каждый кусок работы через себя. Поэтому я хорошо владел всем материалом, а работы защищал на "отлично". В общем, пошел по второму сценарию из развилки в начале поста. С недавним релизом Study Mode это стало еще проще – писал об этом здесь
Конечно, всегда есть соблазн взять готовое решение, немного его отшлифовать и отдать – но нужно быть готовым, что оно окажется НАСТОЛЬКО неправильным, что потом возникнут вопросы. Ну и ни о каком усвоении материала здесь и речи нет, хотя некоторые задания хочется сдать и забыть
А как вы используете ИИ в обучении? Делитесь своими юзкейсами!
@tagir_analyzes
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artem Ryblov’s Data Science Weekly
How to avoid machine learning pitfalls by Michael A. Lones
Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.
This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.
Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.
It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results
Link: arXiv
Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign
@data_science_weekly
Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.
This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.
Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.
It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results
Link: arXiv
Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign
@data_science_weekly
Forwarded from Лечим эйай
Топ смертных грехов - или нет?
Уже несколько лет я руковожу людьми и постепенно их становится все больше. Системного обучения "как быть руководителем" в моей жизни не было. Я иногда почитываю какие-то материалы, иногда советуюсь с родителями, но на самом деле во многих вещах я поступаю просто интуитивно и эмпирически нахожу ответы на вопросы.
В целом, если присмотреться, то становится понятно, что в обществе существует некий "gold standart" руководителя, который должен следовать 15-20 правилам и тогда его все будут любить.
Если ты человек с адекватным эмоциональным интеллектом, то запрыгнуть на эту "gold standart" ступеньку не составляет труда.
Примеры таких правил:
Тут все понятно, и да, далеко не все способны следовать и этому набору.
Но вот о чем я задумался. Данный список правил далеко не все говорит о твоей эффективности. Ключевые метрики на которые мы тут работаем - уменьшение текучки и развитие сотрудников. Но фактически есть еще та часть, в которой мы эффективно решаем задачи и зарабатываем деньги для компании. И возможно, чтобы работать оптимально, используя 100% возможностей - необходимо уменьшить количество "табу", тем самым увеличив свой инструментарий.
Вот некоторые пункты, о которых я пока размышляю:
Переработки
Об этом я частично писал. Причин, почему вам надо добавить динамики, множество. Если твой конкурент работает 5 дней в неделю, а ты 6, то высока вероятность, что ты будешь двигаться быстрее. И, возможно, навык руководителя не в том, чтобы отказаться от этого объективно рабочего инструмента, а грамотно им управлять, чтобы сотрудники не перегорели.
Нанимать не по вайбу
При найме я много раз отказывал людям, которые не подходили мне по софтам, хотя харды были очень хорошие. Я всегда считал, что микроклимат в отделе - ключ к успеху. Но, задумался я, почему бы не нанять токсичного гения, не "запереть его в комнате" и пусть перемалывает там самые сложные задачки. И тогда твой навык - оградить остальных от него, но задачи, возможно, он будет щелкать лучше прочих "вайбовых" коллег.
Повышать голос
Я много лет занимался спортом и оттуда вынес простую мысль на всю жизнь о том, что люди делятся на два типа: те, кого мотивирует поддержка и те, кого мотивирует давление. "Gold standart" сфокусирован на поддержке, но всех ли это реально стимулирует, вторая половина же никуда не пропала. Вспомните таких людей, которые очень редко повышают голос и в этих случаях вы понимаете, что реально что-то случилось. Может иногда это единственный способ привести в чувство и разгрести инцидент?
Обман
О сколько разговоров проведено и книг написано о лжи во благо, внесу свою лепту. Я стараюсь быть открытым и доводить большую часть информации до своих сотрудников, но есть вещи, которые могут вызвать скорее волнение, нежели принесут ценность от осведомленности. Сегментировать информацию, к сожалению, тоже полезный навык, вероятно, как и иногда лукавить.
Идея поста заключается в том, что искусство руководителя, кажется, заключается в умении применять широкий спектр инструментов, а не только удобные, при которых его все "любят", но эти гипотезы надо проверять на практике.
Пост слегка провокационный, будет интересно послушать ваше мнение об этом в комментариях!
@lechim_ai
Уже несколько лет я руковожу людьми и постепенно их становится все больше. Системного обучения "как быть руководителем" в моей жизни не было. Я иногда почитываю какие-то материалы, иногда советуюсь с родителями, но на самом деле во многих вещах я поступаю просто интуитивно и эмпирически нахожу ответы на вопросы.
В целом, если присмотреться, то становится понятно, что в обществе существует некий "gold standart" руководителя, который должен следовать 15-20 правилам и тогда его все будут любить.
Кстати, на тему "все будут любить" отличный пост написала Аня, автор канала Руковожоп (@peachyleader). Это не реклама, а моя личная рекомендация, хороший канал для начинающих руководителей.
Если ты человек с адекватным эмоциональным интеллектом, то запрыгнуть на эту "gold standart" ступеньку не составляет труда.
Примеры таких правил:
1. Не унижай личность сотрудника
2. Проводи встречи по развитию и давай людям расти
3. Будь защитником своей команды
4. Не перегружай сотрудников
5. Не микроменеджери
6. Не обманывай
и подобное.
Тут все понятно, и да, далеко не все способны следовать и этому набору.
Но вот о чем я задумался. Данный список правил далеко не все говорит о твоей эффективности. Ключевые метрики на которые мы тут работаем - уменьшение текучки и развитие сотрудников. Но фактически есть еще та часть, в которой мы эффективно решаем задачи и зарабатываем деньги для компании. И возможно, чтобы работать оптимально, используя 100% возможностей - необходимо уменьшить количество "табу", тем самым увеличив свой инструментарий.
Вот некоторые пункты, о которых я пока размышляю:
Переработки
Об этом я частично писал. Причин, почему вам надо добавить динамики, множество. Если твой конкурент работает 5 дней в неделю, а ты 6, то высока вероятность, что ты будешь двигаться быстрее. И, возможно, навык руководителя не в том, чтобы отказаться от этого объективно рабочего инструмента, а грамотно им управлять, чтобы сотрудники не перегорели.
Нанимать не по вайбу
При найме я много раз отказывал людям, которые не подходили мне по софтам, хотя харды были очень хорошие. Я всегда считал, что микроклимат в отделе - ключ к успеху. Но, задумался я, почему бы не нанять токсичного гения, не "запереть его в комнате" и пусть перемалывает там самые сложные задачки. И тогда твой навык - оградить остальных от него, но задачи, возможно, он будет щелкать лучше прочих "вайбовых" коллег.
Повышать голос
Я много лет занимался спортом и оттуда вынес простую мысль на всю жизнь о том, что люди делятся на два типа: те, кого мотивирует поддержка и те, кого мотивирует давление. "Gold standart" сфокусирован на поддержке, но всех ли это реально стимулирует, вторая половина же никуда не пропала. Вспомните таких людей, которые очень редко повышают голос и в этих случаях вы понимаете, что реально что-то случилось. Может иногда это единственный способ привести в чувство и разгрести инцидент?
Обман
О сколько разговоров проведено и книг написано о лжи во благо, внесу свою лепту. Я стараюсь быть открытым и доводить большую часть информации до своих сотрудников, но есть вещи, которые могут вызвать скорее волнение, нежели принесут ценность от осведомленности. Сегментировать информацию, к сожалению, тоже полезный навык, вероятно, как и иногда лукавить.
Идея поста заключается в том, что искусство руководителя, кажется, заключается в умении применять широкий спектр инструментов, а не только удобные, при которых его все "любят", но эти гипотезы надо проверять на практике.
Пост слегка провокационный, будет интересно послушать ваше мнение об этом в комментариях!
@lechim_ai