Forwarded from Дмитрий Кузьмин | Инженерия данных
Что делать, если нужно переиспользовать один и тот же тяжёлый spark.sql(...)? Расчёт медленный, ресурсы горят, DAG перегружен.
Цель: посчитать один раз и потом переиспользовать.
В Spark это называется кэширование или материализация.
Покажу несколько подходов.
✅ Вариант 1: Кэш в памяти (cache() / persist())
Если результат нужен в рамках одной сессии Spark и в нескольких последующих действиях:
df = spark.sql("SELECT ... FROM big_table ...")
df.cache() # или df.persist(StorageLevel.MEMORY_AND_DISK)
df.count() # обязательно триггерим кэш
Это только временное решение в рамках сессии!
✅ Вариант 2: Запись в Parquet (материализация)
Если тебе нужно:
в других пайпах
Пиши в Parquet:
df = spark.sql("SELECT ... FROM big_table ...")
df.write.mode("overwrite").parquet("/mnt/data/intermediate/my_cached_result")
А потом читаешь:
df_cached = spark.read.parquet("/mnt/data/intermediate/my_cached_result")
✅ Вариант 3: External table в Hive / Metastore
Если нужно, чтобы результат был доступен:
Тогда — создай внешнюю таблицу на основе сохранённого parquet-файла:
CREATE EXTERNAL TABLE my_cached_table
USING PARQUET
LOCATION '/mnt/data/intermediate/my_cached_result'
Теперь SELECT * FROM my_cached_table доступен везде.
Какой способ выбрать?
Что еще важно:
Какой способ предпочитаешь:
🔥 — только cache()
👍 — привычный и надежный parquet
🤔 — hive наше всё
#база_знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dataism
Чек-лист A_B экспериментов.pdf
147.9 KB
Yet another чек-лист
Представь себе, что ты вышел на новую работу и тебя сразу окунули в …эксперимент
И тебе нужно для начала проверить уже все заготовки перед запуском и дать свой экспертный ок на всю эту красоту, потом запустить и сопроводить тест, а в конце подвести итоги.
Что в идеале нужно проверить?
Я бы выделила 3 основных направления:
1) проверка бизнес аспектов эксперимента
2) дизайн самого эксперимента
3) правильный старт эксперимента
в пост не впихивается, поэтому держите файлик с ПРОДВИНУТЫМ вариантом чек-листа эксперимента🐾
Представь себе, что ты вышел на новую работу и тебя сразу окунули в …
И тебе нужно для начала проверить уже все заготовки перед запуском и дать свой экспертный ок на всю эту красоту, потом запустить и сопроводить тест, а в конце подвести итоги.
Что в идеале нужно проверить?
Я бы выделила 3 основных направления:
1) проверка бизнес аспектов эксперимента
2) дизайн самого эксперимента
3) правильный старт эксперимента
в пост не впихивается, поэтому держите файлик с ПРОДВИНУТЫМ вариантом чек-листа эксперимента
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
Первые 3 главы Designing Data-Intensive Applications, 2nd Edition
Глава 1. Компромиссы в архитектуре систем данных
Глава 2. Определение нефункциональных требований
Глава 3. Модели данных и языки запросов
Глава 1. Компромиссы в архитектуре систем данных
Глава 2. Определение нефункциональных требований
Глава 3. Модели данных и языки запросов
DataTalks.RU. Data Engineering / DWH / Data Pipeline
Глава 1. Компромиссы в архитектуре систем данных
Forwarded from Дмитрий Кузьмин | Инженерия данных
Собрал подборку своих постов по Spark, которые помогут разобраться с основами, архитектурой и практическими фишками (чтобы не листать ленту).
🔴 Введение в Spark
Коротко про Spark
Чек-лист для старта в Spark
Зачем нужен Spark?
🔴 Архитектура и окружение
Связка Hive + Spark + HDFS
Экспресс-архитектура Spark
Как выбрать ресурсы для SparkSession?
🔴 Оптимизация и продвинутые темы
Кэширование и материализация в Spark
Не знаю, как пойдет, но планирую пополнять базу знаний и кейсов и файлов.
🤫 Половину из этого часто спрашивают на собесах, чтобы проверить глубину погружения в инструмент, а часть просто хорошо бы знать - это сэкономит вам время и нервы
🤲 Сохрани себе, чтобы не потерять.
✨ Если нужны такие пополняемые подборки по задачам с собесов и их разборами, кидай реакцию.
#материалы
#база_знаний
Коротко про Spark
Чек-лист для старта в Spark
Зачем нужен Spark?
Связка Hive + Spark + HDFS
Экспресс-архитектура Spark
Как выбрать ресурсы для SparkSession?
Кэширование и материализация в Spark
Не знаю, как пойдет, но планирую пополнять базу знаний и кейсов и файлов.
#материалы
#база_знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Bar | О data-проектах (Alexander Varlamov)
MCP для начинающих
Недавно Microsoft выложил на YouTube бесплатный курс 'MCP for beginners'.
Если вы не фанат видео (как я), весь материал дублируется на GitHub.
Что такое MCP (Model Context Protocol)?
Это протокол общения нейросетей с внешним миром. По нему к LLM можно подключать любые источники данных или системы управления, и всё это по одному универсальному стандарту. MCP часто сравнивают с USB: устройство одно, протокол один, а число сценариев - бесконечно.
Протоколу ещё нет и года, но уже проводятся конференции, выпускаются курсы и появляются MCP-сервисы. Поддержка со стороны крупных IT-игроков говорит о том, что MCP быстро становится де-факто стандартом интеграции ИИ в реальные системы.
Дима Аношин в Канале 'Инжиниринг Данных' делился материалами с конференции 'MCP Dev Days'.
Я недавно писал про подключение Claude по MCP к PostgreSQL, когда нейросеть ходит в базу данных и собирает инсайты и отчёты. Всё работает на домашнем ПК. Развернуть несложно.
Короче, пока в русскоязычном LinkedIn спорят о кризисе в IT, мир строит новый слой взаимодействия информационных систем. MCP только набирает обороты - самое время вкатываться.🔥
Недавно Microsoft выложил на YouTube бесплатный курс 'MCP for beginners'.
Если вы не фанат видео (как я), весь материал дублируется на GitHub.
Что такое MCP (Model Context Protocol)?
Это протокол общения нейросетей с внешним миром. По нему к LLM можно подключать любые источники данных или системы управления, и всё это по одному универсальному стандарту. MCP часто сравнивают с USB: устройство одно, протокол один, а число сценариев - бесконечно.
Протоколу ещё нет и года, но уже проводятся конференции, выпускаются курсы и появляются MCP-сервисы. Поддержка со стороны крупных IT-игроков говорит о том, что MCP быстро становится де-факто стандартом интеграции ИИ в реальные системы.
Дима Аношин в Канале 'Инжиниринг Данных' делился материалами с конференции 'MCP Dev Days'.
Я недавно писал про подключение Claude по MCP к PostgreSQL, когда нейросеть ходит в базу данных и собирает инсайты и отчёты. Всё работает на домашнем ПК. Развернуть несложно.
Короче, пока в русскоязычном LinkedIn спорят о кризисе в IT, мир строит новый слой взаимодействия информационных систем. MCP только набирает обороты - самое время вкатываться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 85GB нейронок
Отличный вопрос!
Всё зависит от задач, тех.навыков и желания ковыряться.
1. Если нужно проапскейлить обычную фотку или генерацию в художественном стиле условного ренессанса, подойдёт и простенький Upscayl (это название).
2. Для апскейла генераций фотографических можно юзать Comfy UI (или Forge) и сборки на базе Flux. Но это, конечно, не для всех.
3. Знаю, что многие юзают Topaz, тем более, что там есть щас функционал Магнифика, но у меня он перестал работать, прост ошибку выдаёт, поэтому
4. Magnific. Для генераций. Особенно хорошо после апскейлов Флакса, т.к. придаёт текстуры и шероховатости. Дорого.
5. Enhancer от Krea. Делает много шума и грязи, видны тайлы при сплошных заливках, но с творческими, абстрактными генками справляется хорошо. Главное, подобрать настройки, в первую очередь — ставить на минимум креативность модели, и на максимум — совпадение с оригинальной пикчей.
Всё зависит от задач, тех.навыков и желания ковыряться.
1. Если нужно проапскейлить обычную фотку или генерацию в художественном стиле условного ренессанса, подойдёт и простенький Upscayl (это название).
2. Для апскейла генераций фотографических можно юзать Comfy UI (или Forge) и сборки на базе Flux. Но это, конечно, не для всех.
3. Знаю, что многие юзают Topaz, тем более, что там есть щас функционал Магнифика, но у меня он перестал работать, прост ошибку выдаёт, поэтому
4. Magnific. Для генераций. Особенно хорошо после апскейлов Флакса, т.к. придаёт текстуры и шероховатости. Дорого.
5. Enhancer от Krea. Делает много шума и грязи, видны тайлы при сплошных заливках, но с творческими, абстрактными генками справляется хорошо. Главное, подобрать настройки, в первую очередь — ставить на минимум креативность модели, и на максимум — совпадение с оригинальной пикчей.
Forwarded from Заметки LLM-энтузиаста
🆕 Новые бесплатные AI-модели с контекстом 2 млн токенов
На openrouter.ai стали доступны две новые модели: Sonoma Dusk Alpha и Sonoma Sky Alpha.
Обе работают бесплатно и поддерживают контекстное окно в 2 миллиона токенов.
Где протестировать:
1️⃣ Через любой бесплатный AI-кодер (Roo/Cline/Kilo/...), где можно указать openrouter в качестве провайдера (на requesty.ai пока нет)
Внутри Kilo есть свой провайдер Kilo Code (но модели все равно в названии имеют openrouter:
2️⃣ Напрямую через OpenRouter API
Что известно:
• Некоторые эксперты предполагают, что за моделями стоит xAI
• Другие считают их новыми версиями Gemini 3
• Модели собирают данные промптов для улучшения работы ⚠️
Особенности:
• Бесплатное использование 💰
• Большой контекст (2M токенов) 📊
• Возможны ограничения по скорости запросов ⏱️
Рекомендую самостоятельно протестировать модели и сравнить их качество и производительность с другими моделями, например, такой трендовой как Grok Code Fast 1.
Я тестировал, используя Kilo Code на примере игры в сапера. Результаты можно посмотреть в комментариях.
Я использовал в Kilo Code режимы Architect и Code и один и тот же промпт:
Мой выбор из трех упомянутых выше моделей:sonoma-dusk-alpha
Она лучше всех показала себя при решении этой простой задачи:
1) Короткий, но по делу "To-Do" лист
2) Быстрое написание кода
3) Рабочий прототип за пару десятков секунд, в котором ничего не надо было исправлять.
@llm_notes
#llm #free #large_context #sonoma #openrouter #kilo
На openrouter.ai стали доступны две новые модели: Sonoma Dusk Alpha и Sonoma Sky Alpha.
Обе работают бесплатно и поддерживают контекстное окно в 2 миллиона токенов.
Где протестировать:
1️⃣ Через любой бесплатный AI-кодер (Roo/Cline/Kilo/...), где можно указать openrouter в качестве провайдера (на requesty.ai пока нет)
Внутри Kilo есть свой провайдер Kilo Code (но модели все равно в названии имеют openrouter:
openrouter/sonoma-sky-alpha и openrouter/sonoma-dusk-alpha)2️⃣ Напрямую через OpenRouter API
Что известно:
• Некоторые эксперты предполагают, что за моделями стоит xAI
• Другие считают их новыми версиями Gemini 3
• Модели собирают данные промптов для улучшения работы ⚠️
Особенности:
• Бесплатное использование 💰
• Большой контекст (2M токенов) 📊
• Возможны ограничения по скорости запросов ⏱️
Рекомендую самостоятельно протестировать модели и сравнить их качество и производительность с другими моделями, например, такой трендовой как Grok Code Fast 1.
Я тестировал, используя Kilo Code на примере игры в сапера. Результаты можно посмотреть в комментариях.
Я использовал в Kilo Code режимы Architect и Code и один и тот же промпт:
Создай, пожалуйста, игру Сапер, используя JS, CSS и HTML.Мой выбор из трех упомянутых выше моделей:
Она лучше всех показала себя при решении этой простой задачи:
1) Короткий, но по делу "To-Do" лист
2) Быстрое написание кода
3) Рабочий прототип за пару десятков секунд, в котором ничего не надо было исправлять.
@llm_notes
#llm #free #large_context #sonoma #openrouter #kilo
Forwarded from Love. Death. Transformers.
newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization
толковый обзорный блогпост по квантизациям, вводят базовые понятия, довольно толково
толковый обзорный блогпост по квантизациям, вводят базовые понятия, довольно толково
Forwarded from Заскуль питона (Data Science)
Симуляция A/A тестов и зачем это нужно
A/A тест — это эксперимент, где обе группы одинаковы. Он нужен, чтобы проверить: работает ли наша система экспериментов честно и не выдумывает эффекты там, где их нет.
Самое главное, для чего мы проводим синтетический A/A тест (на большом количестве итераций) — это контроль ошибки первого рода. Ошибка первого рода (False Positive Rate) — это вероятность найти изменения там, где их нет. То есть мы заранее знаем, какой процент экспериментов ложно прокрасится (обычно, это очень маленькие вероятности в районе 0.01, 0.05, иногда 0.1, но достаточно редко).
Зачастую это нужно для проверки сплитовалке на определенном срезе пользователей / с кастомными метриками (которые будут участвовать в эксперименте).
В некоторых компаниях есть команда A/B платформы, которая занимается валидацией метрик, применением критериев к различным выборкам / метрикам.
В компании важно уметь пересчитывать ошибки I и II рода на разных срезах. Без этого мы не можем быть уверены, что группы изначально одинаковые. Если этого не будет, то утверждать о том, что изначально выборки были одинаковые (предположение для A/B теста) сказать нельзя. Метрики на предпериоде до эксперимента могут разъезжаться.
В каких случаях стоит запускать проверки?
1. Когда в компании уже есть процесс пересчёта метрик и нужно убедиться, что он работает корректно.
2. Когда появляется новая поверхность или метрика. Важно проверить, что группы не расходятся случайно.
3. Когда есть риск выбросов: несколько объектов могут сильно влиять на результат и завышать вероятность ложных срабатываний.
Как запустить синтетическую проверку?
Давайте запустим симуляцию: 10 000 A/A тестов на случайных группах и посмотрим, как ведут себя p-value
Что мы ожидаем увидеть в ходе синтетического A/A теста?
Равномерное распределение p-value, которое говорит нам о том, что все хорошо, нет проблем. Это значит, что система работает корректно: ложные срабатывания происходят ровно с той частотой, которую мы задали. Можно думать про это как про честную монетку (предположим, что мы подкидываем ее 100 раз, а затем проводим 10 000 симуляций): иногда выпадет значимо, но ровно с той частотой, которую мы сами задали (например, 5% при alpha=0.05).
A/A тесты — это краш-тест для платформы экспериментов. Если они честные, бизнес может доверять результатам A/B.
Понравился пост? Ставьте🐳 , пишите комментарии, что думаете по поводу A/A тестов.
A/A тест — это эксперимент, где обе группы одинаковы. Он нужен, чтобы проверить: работает ли наша система экспериментов честно и не выдумывает эффекты там, где их нет.
Самое главное, для чего мы проводим синтетический A/A тест (на большом количестве итераций) — это контроль ошибки первого рода. Ошибка первого рода (False Positive Rate) — это вероятность найти изменения там, где их нет. То есть мы заранее знаем, какой процент экспериментов ложно прокрасится (обычно, это очень маленькие вероятности в районе 0.01, 0.05, иногда 0.1, но достаточно редко).
Зачастую это нужно для проверки сплитовалке на определенном срезе пользователей / с кастомными метриками (которые будут участвовать в эксперименте).
В некоторых компаниях есть команда A/B платформы, которая занимается валидацией метрик, применением критериев к различным выборкам / метрикам.
В компании важно уметь пересчитывать ошибки I и II рода на разных срезах. Без этого мы не можем быть уверены, что группы изначально одинаковые. Если этого не будет, то утверждать о том, что изначально выборки были одинаковые (предположение для A/B теста) сказать нельзя. Метрики на предпериоде до эксперимента могут разъезжаться.
В каких случаях стоит запускать проверки?
1. Когда в компании уже есть процесс пересчёта метрик и нужно убедиться, что он работает корректно.
2. Когда появляется новая поверхность или метрика. Важно проверить, что группы не расходятся случайно.
3. Когда есть риск выбросов: несколько объектов могут сильно влиять на результат и завышать вероятность ложных срабатываний.
Я видел историю, когда был запущен эксперимент одним аналитиком, но при подведении итогов на определенном срезе покупателей (кто фактически видел эту фичу), получили ошибку первого рода 0.15 на целевой метрике (по которой мы принимаем решением), хотя ожидалось 0.05, то есть ошибку первого рода мы не контролируем => эксперимент невалиден. Затем я посмотрел, что происходило с группами на предпериоде, целевая метрика по группам разъехалась очень сильно, а это нарушает ключевое предположение A/B теста.
Как запустить синтетическую проверку?
Давайте запустим симуляцию: 10 000 A/A тестов на случайных группах и посмотрим, как ведут себя p-value
import numpy as np
import matplotlib.pyplot as plt
from scipy import stats
data = np.random.normal(loc=100, scale=10, size=10_000)
alpha = 0.05
p_values = []
for _ in range(10_000):
idx = np.random.permutation(len(data))
a_idx, b_idx = np.array_split(idx, 2)
a, b = data[a_idx], data[b_idx]
_, p = stats.ttest_ind(a, b)
p_values.append(p)
print('Ошибка первого рода:', np.mean(np.array(p_values) < alpha)) # в идеале здесь будет значение в районе 0.05
plt.hist(p_values, bins=50, edgecolor="black")
plt.xlabel("p-value")
plt.title("Распределение p-value в A/A тесте (10000 симуляций)")
plt.show()
Что мы ожидаем увидеть в ходе синтетического A/A теста?
Равномерное распределение p-value, которое говорит нам о том, что все хорошо, нет проблем. Это значит, что система работает корректно: ложные срабатывания происходят ровно с той частотой, которую мы задали. Можно думать про это как про честную монетку (предположим, что мы подкидываем ее 100 раз, а затем проводим 10 000 симуляций): иногда выпадет значимо, но ровно с той частотой, которую мы сами задали (например, 5% при alpha=0.05).
A/A тесты — это краш-тест для платформы экспериментов. Если они честные, бизнес может доверять результатам A/B.
Понравился пост? Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from что-то на инженерном
Режимы работы Spark: client vs cluster mode
На мой взгляд, вопрос про отличия клиентского режима от кластерного является одним из самых популярных вопросов на собеседованиях. Реже спрашивают про другие режимы. Давайте сегодня разберем, как можно ответить на этот вопрос.
Выбор режима зависит от того, где запускается Spark-приложение: на локальной машине или в распределённом кластере. Режим запуска определяется местоположением драйвера.
В кластере ресурсами управляет диспетчер ресурсов (Resource Manager), который выделяет виртуальные машины или процессы с заданным набором ресурсов для приложений. Мастер приложений (Application Master) координирует выполнение заданий, управление ресурсами и обеспечивает отказоустойчивость. Spark поддерживает разные менеджеры ресурсов: Hadoop YARN, Kubernetes, Standalone.
Есть два основных режима запуска:
⚫️ Client mode - драйвер работает на той же машине, откуда подаётся команда
Пример: вы запускаете Spark-скрипт со своей машины, и именно машина управляет выполнением задания.
Плюсы:
💗 удобно для разработки и отладки (stdout/stderr выводятся прямо в вашу консоль),
💗 легко менять код и получать результаты в интерактивном режиме (например, из spark-shell),
💗 прост в настройке.
Минусы:
💗 ограничение по ресурсам вашей машины,
💗 если машина «упала» или нарушена сеть, то задание тоже упадёт.
⚫️ Cluster mode - драйвер запускается не на вашей машине, а на одном из узлов кластера. Управление берёт на себя менеджер ресурсов (YARN, Kubernetes, Standalone).
Пример: вы отправляете задачу на Spark-кластер, и дальше распределением ресурсов занимаются сами узлы.
Плюсы:
💗 высокая масштабируемость,
💗 отказоустойчивость (если узел падает, задачи перераспределяются),
💗 изоляция ресурсов между драйвером и воркерами.
Минусы:
💗 сложнее настройка инфраструктуры,
💗 отладка может быть не такой удобной (логи нужно собирать через Spark UI или интерфейс менеджера ресурсов).
⭐️ Для домашнего использования Spark существует локальный режим (Local mode). В этом режиме всё приложение работает целиком на локальной машине: и драйвер, и исполнители.
Что в итоге?
🟣 Local mode - playground для новичков, кто хочет потрогать Spark в домашних условиях.
🟣 Client mode - выбор для разработки, прототипов, отладки и небольших задач. Как правило, такой режим выбирают для разработки процессов и анализа данных через Jupiter Notebook и подобные инструменты.
🟣 Cluster mode - выбор для продакшена, больших объёмов данных и настоящей распределенной работы.
Источники:
🤩 2 режима развертывания приложений Apache Spark
🤩 Client vs Cluster Mode in Apache Spark
🤩 Understanding Apache Spark Deployment Modes: Client Mode, Cluster Mode, and Local Mode
©️что-то на инженерном
На мой взгляд, вопрос про отличия клиентского режима от кластерного является одним из самых популярных вопросов на собеседованиях. Реже спрашивают про другие режимы. Давайте сегодня разберем, как можно ответить на этот вопрос.
Выбор режима зависит от того, где запускается Spark-приложение: на локальной машине или в распределённом кластере. Режим запуска определяется местоположением драйвера.
Тут напомню, что любое Spark-приложение состоит из процесса драйвера и множества процессов исполнителей (executors). Драйвер управляет всей информацией, планирует и распределяет работу исполнителей. Он превращает код в задачи (tasks), которые потом распределяются по исполнителям. Исполнители же непосредственно выполняют вычисления и работу с данными.
В кластере ресурсами управляет диспетчер ресурсов (Resource Manager), который выделяет виртуальные машины или процессы с заданным набором ресурсов для приложений. Мастер приложений (Application Master) координирует выполнение заданий, управление ресурсами и обеспечивает отказоустойчивость. Spark поддерживает разные менеджеры ресурсов: Hadoop YARN, Kubernetes, Standalone.
Есть два основных режима запуска:
spark-submit, т.е запускается задание. При этом исполнители находятся на кластере. Этот режим подходит для интерактивной работы и отладки. Пример: вы запускаете Spark-скрипт со своей машины, и именно машина управляет выполнением задания.
Плюсы:
Минусы:
Пример: вы отправляете задачу на Spark-кластер, и дальше распределением ресурсов занимаются сами узлы.
Плюсы:
Минусы:
Что в итоге?
Источники:
©️что-то на инженерном
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM