Forwarded from Борис опять
С этими знаниями уже можно собрать рабочую схему деплоя табличной ML модели.
0. Поднимаем контейнер с базой данных.
1. На размеченных данных из бд обучаем Sklearn Pipeline, сохраняем с помощью pickle. Можно записать ее в БД, загрузить на облачное хранилище или просто сохранить на диск.
2. В контейнере для инференса периодически запускаем batch job: загрузили модель, достали из БД неразмеченные данные, сделали для них инференс, сохранили предсказания в БД.
3. Если batch job не подходит, то в контейнере для инференса запускаем API (flask, apiflask или fastapi). Принимает на вход POST запрос с json фичами примера, загружает модель, делает предикт, сохраняет пример и предсказание в БД (для дальнейшей доразметки и дообучения), возвращает предикт в виде JSON. Про API в данном гайде нет, но тоже очень полезно знать. Изучается за вечер, достаточно пройти один туториал.
0. Поднимаем контейнер с базой данных.
1. На размеченных данных из бд обучаем Sklearn Pipeline, сохраняем с помощью pickle. Можно записать ее в БД, загрузить на облачное хранилище или просто сохранить на диск.
2. В контейнере для инференса периодически запускаем batch job: загрузили модель, достали из БД неразмеченные данные, сделали для них инференс, сохранили предсказания в БД.
3. Если batch job не подходит, то в контейнере для инференса запускаем API (flask, apiflask или fastapi). Принимает на вход POST запрос с json фичами примера, загружает модель, делает предикт, сохраняет пример и предсказание в БД (для дальнейшей доразметки и дообучения), возвращает предикт в виде JSON. Про API в данном гайде нет, но тоже очень полезно знать. Изучается за вечер, достаточно пройти один туториал.
Forwarded from Борис опять
# Минимальные знания Software Engineering для Data Scientist 3/3
## Map Reduce
Туториал
Чтение
Общая парадигма того, как быстро обрабатывать данные, которые не влезают в оперативную память или даже диск сервера. Не вся Биг Дата это Map Reduce. Но позволит понять основные идеи.
## Распределенные вычисления
Выбрать одно: Spark Quickstart, Dask Quickstart
Apache Spark, Dask и аналоги это инструменты, которые реализуют Map Reduce и другие парадигмы. Они делают чтобы было быстро несмотря на то, что очень много. Очень часто встречаются в требованиях на вакансии DS, MLE и не только. Apache Spark более популярный, Dask - проще и приятнее. Для ознакомления выбирайте любой.
Для закрепления: переписываем из пункта Sklearn Pipelines так, чтобы feature engineering выполнялся с помощью Spark или Dask.
## MLOps - MLFlow
Однажды люди поняли, что при создании ML проектов можно не просто творить как получится, а использовать накопленные человечеством 40+ лет знаний о разработке софта. И придумали MLOps. Это о том, как менеджерить данные, модели, эксперименты и код экспериментов. Главные компоненты MLOps: структурирование проектов, трекинг экспериментов, версионирование данных и моделей, деплой моделей. Деплой моделей мы опустим, чтобы сэкономить в голове место, потому что для минимума он не критичен. Проще всего не осваивать все по-отдельности, а разобраться в самой популярной платформе, которая их объединяет: MLFlow.
Читаем для познания основных идей:
- Версионирование данных и моделей
- Трекинг экспериментов (сразу с MLFlow примером)
Проходим туториал по MLFlow
Для закрепления: добавляем MLFlow в свой ML проект.
- Метрики эксперимента должны отправляться при обучении в MLFlow.
- После обучения модель должна сохраняться в MLFlow Model Registry.
## Map Reduce
Туториал
Чтение
Общая парадигма того, как быстро обрабатывать данные, которые не влезают в оперативную память или даже диск сервера. Не вся Биг Дата это Map Reduce. Но позволит понять основные идеи.
## Распределенные вычисления
Выбрать одно: Spark Quickstart, Dask Quickstart
Apache Spark, Dask и аналоги это инструменты, которые реализуют Map Reduce и другие парадигмы. Они делают чтобы было быстро несмотря на то, что очень много. Очень часто встречаются в требованиях на вакансии DS, MLE и не только. Apache Spark более популярный, Dask - проще и приятнее. Для ознакомления выбирайте любой.
Для закрепления: переписываем из пункта Sklearn Pipelines так, чтобы feature engineering выполнялся с помощью Spark или Dask.
## MLOps - MLFlow
Однажды люди поняли, что при создании ML проектов можно не просто творить как получится, а использовать накопленные человечеством 40+ лет знаний о разработке софта. И придумали MLOps. Это о том, как менеджерить данные, модели, эксперименты и код экспериментов. Главные компоненты MLOps: структурирование проектов, трекинг экспериментов, версионирование данных и моделей, деплой моделей. Деплой моделей мы опустим, чтобы сэкономить в голове место, потому что для минимума он не критичен. Проще всего не осваивать все по-отдельности, а разобраться в самой популярной платформе, которая их объединяет: MLFlow.
Читаем для познания основных идей:
- Версионирование данных и моделей
- Трекинг экспериментов (сразу с MLFlow примером)
Проходим туториал по MLFlow
Для закрепления: добавляем MLFlow в свой ML проект.
- Метрики эксперимента должны отправляться при обучении в MLFlow.
- После обучения модель должна сохраняться в MLFlow Model Registry.
Forwarded from Базы данных & SQL
Хабр
Не все типы репликации одинаково полезны, или почему две MySQL лучше одной
В это сложно поверить, но MySQL как продукт появился еще в 1995 году. Со временем название СУБД стало таким же нарицательным, как Xerox. Сегодня под этим термином могут понимать самые разные связки:...
Forwarded from Дмитрий phd anetto
В тему последней рекламы платных курсов по питону. Перед тем, как брать курсы, посмотрите на тонны бесплатного материала. Сможете понять, надо ли вам оно
Если нужно, я подобрал годные бесплатные материалы (курсы, книги, лекции) по питону, SQL, git, тестам, докеру и другим нужным начинающему разработчику темам
Если нужно, я подобрал годные бесплатные материалы (курсы, книги, лекции) по питону, SQL, git, тестам, докеру и другим нужным начинающему разработчику темам
Пикабу
Ответ trdm в «Яндекс и "Цифровые профессии"»
Автор: anetto1502
#python #career
Тут в свободный доступ выложили книгу «Software engineering at Google» издательства O’Reilly
https://abseil.io/resources/swe-book/html/toc.html
Тут в свободный доступ выложили книгу «Software engineering at Google» издательства O’Reilly
https://abseil.io/resources/swe-book/html/toc.html
Forwarded from Quant Valerian
Как считать волу?
Давеча мне, внезапно, понадобилось посчитать по работе волатильность в паре, для которой мои товарищи мне волу дать не могли (рынка нет). Я закатал рукава и... пошел искать в своем канале, как там эстимировать волу эту вашу. И не нашел ответа, только вопрос в зал. Короче, пришлось заново вспоминать, перепроверять на монте-карлах и вообще тратить время. Документируем-с.
Итак, чуть больше деталей задачи. Хочется очень примерно, но очень быстро прикинуть АТМ волатильность на короткий срок (меньше месяца). Делаем сильное предположение о нормальности распределения данных. Есть несколько способов (но на самом деле они все одинаковые), щас мы с вами их разберем в деталях и поймем, когда чем пользоваться.
В интернетике есть такой rule of thumb: (max - min) / 4, чуть реже можно встретить (max - min) / 6. Смысл здесь вот какой. Предполагается, что мы смотрим на small sample, т.е. данных мало. С вероятностью 95% все эти данные лежат в интервале двух сигм, с вероятностью 99% — в интервале трёх сигм. Тогда (max - min) / 2 = 2*sigma для 95%% или (max - min) / 2 = 3*sigma для 99%%.
Уточним, что у нас все-таки случайный процесс, поэтому наш разброс не просто sigma, а sigma*sqrt(t). Чтобы получить именно сигму, нужно делить на корень из времени.
Можно посмотреть по картинке (стартуем из 100, с sigma=5%, t=5 дней, 15 реализаций). Видим max=125, min=75. (125 - 75) / 4 = 12,5 (sigma=5,6%); (125 - 75) / 6 = 8,3 (sigma=3,7%); avg(12,5; 8,3) = 10,4 (sigma=4,65%). То есть истина где-то посередине на такой выборке.
Что мы имеем в жизни? У нас не то, что small sample, у нас вообще всего одна реализация, одна единственная траектория. Вспомним, что с вероятностью 68% мы в одной сигме с этой своей одной траекторией. И на самом деле, если использовать sigma = (max - min) / 2, то получается даже точнее.
Не лишним будет отметить, что по выходным торгов нет, поэтому оценивая волатильность за неделю, нужно брать t=5, а за месяц — t=22. При этом волатильность котируется в процентах годовых (причем в календарных днях), поэтому сигму нужно умножить на sqrt(365) и поделить на спот, чтобы получить котировку.
Итого. Чтобы посчитать АТМ 1W:
1. смотрим, какой примерно был разброс за неделю
2. делим этот разброс на средний за неделю или на текущий спот (не суть на самом деле)
3. делим пополам
4. делим на sqrt(5)~2.2
5. умножаем на sqrt(365)~19
Формулы для кручения в мозгу:
(max - min) / (max + min) * 19 / 2.2
(max - min) / (2 * spot) * 19 / 2.2
Давеча мне, внезапно, понадобилось посчитать по работе волатильность в паре, для которой мои товарищи мне волу дать не могли (рынка нет). Я закатал рукава и... пошел искать в своем канале, как там эстимировать волу эту вашу. И не нашел ответа, только вопрос в зал. Короче, пришлось заново вспоминать, перепроверять на монте-карлах и вообще тратить время. Документируем-с.
Итак, чуть больше деталей задачи. Хочется очень примерно, но очень быстро прикинуть АТМ волатильность на короткий срок (меньше месяца). Делаем сильное предположение о нормальности распределения данных. Есть несколько способов (но на самом деле они все одинаковые), щас мы с вами их разберем в деталях и поймем, когда чем пользоваться.
В интернетике есть такой rule of thumb: (max - min) / 4, чуть реже можно встретить (max - min) / 6. Смысл здесь вот какой. Предполагается, что мы смотрим на small sample, т.е. данных мало. С вероятностью 95% все эти данные лежат в интервале двух сигм, с вероятностью 99% — в интервале трёх сигм. Тогда (max - min) / 2 = 2*sigma для 95%% или (max - min) / 2 = 3*sigma для 99%%.
Уточним, что у нас все-таки случайный процесс, поэтому наш разброс не просто sigma, а sigma*sqrt(t). Чтобы получить именно сигму, нужно делить на корень из времени.
Можно посмотреть по картинке (стартуем из 100, с sigma=5%, t=5 дней, 15 реализаций). Видим max=125, min=75. (125 - 75) / 4 = 12,5 (sigma=5,6%); (125 - 75) / 6 = 8,3 (sigma=3,7%); avg(12,5; 8,3) = 10,4 (sigma=4,65%). То есть истина где-то посередине на такой выборке.
Что мы имеем в жизни? У нас не то, что small sample, у нас вообще всего одна реализация, одна единственная траектория. Вспомним, что с вероятностью 68% мы в одной сигме с этой своей одной траекторией. И на самом деле, если использовать sigma = (max - min) / 2, то получается даже точнее.
Не лишним будет отметить, что по выходным торгов нет, поэтому оценивая волатильность за неделю, нужно брать t=5, а за месяц — t=22. При этом волатильность котируется в процентах годовых (причем в календарных днях), поэтому сигму нужно умножить на sqrt(365) и поделить на спот, чтобы получить котировку.
Итого. Чтобы посчитать АТМ 1W:
1. смотрим, какой примерно был разброс за неделю
2. делим этот разброс на средний за неделю или на текущий спот (не суть на самом деле)
3. делим пополам
4. делим на sqrt(5)~2.2
5. умножаем на sqrt(365)~19
Формулы для кручения в мозгу:
(max - min) / (max + min) * 19 / 2.2
(max - min) / (2 * spot) * 19 / 2.2
Forwarded from DziS Science | Data Science
В процессе реализации решений на Leetcode понял, что совсем не помню алгоритмы прохода по бинарному дереву 🌳.
Предлагаю вспомнить варианты поиска в глубину (Depth-first search).
Классических вариантов 3:
1. DFS Preorder. Классический проход в глубину, где сначала проходится корень дерева, далее спускается по каждой ветке слева направо вглубь до самого глубокого листа.
2. DFS Inorder. Обратный проход. Начинается с левого листа, далее в вершину, потом обратно на уровень ниже в правый лист.
3. DFS Posorder. Обратный проход. Начинается с левого листа нижнего, проходя по всем одноуровневым листам слева направо, только потом поднимаемся на уровень выше.
Для тех кто ничего не понял, приведены картинки и справа для сравнения поиск в ширину (BFS).
Предлагаю рассмотреть красивые рекурсивные реализации данных методов для примера с картинки.
Предлагаю вспомнить варианты поиска в глубину (Depth-first search).
Классических вариантов 3:
1. DFS Preorder. Классический проход в глубину, где сначала проходится корень дерева, далее спускается по каждой ветке слева направо вглубь до самого глубокого листа.
2. DFS Inorder. Обратный проход. Начинается с левого листа, далее в вершину, потом обратно на уровень ниже в правый лист.
3. DFS Posorder. Обратный проход. Начинается с левого листа нижнего, проходя по всем одноуровневым листам слева направо, только потом поднимаемся на уровень выше.
Для тех кто ничего не понял, приведены картинки и справа для сравнения поиск в ширину (BFS).
Предлагаю рассмотреть красивые рекурсивные реализации данных методов для примера с картинки.
class Node:В целом, полезно знать при работе с графами. Могут спросить на душных технических собесах, к которым я и готовлюсь🤓💼
def __init__(self, key):
self.left = None
self.right = None
self.val = key
def preorder(root):
return [root.val] + preorder(root.left) + preorder(root.right) if root else []
def inorder(root):
return inorder(root.left) + [root.val] + inorder(root.right) if root else []
def postorder(root):
return postorder(root.left) + postorder(root.right) + [root.val] if root else []
# Пример
if __name__ == "__main__":
root = Node(1)
root.left = Node(2)
root.right = Node(3)
root.left.left = Node(4)
root.left.right = Node(5)
# Вызов функций
print(f"DFS preorder {preorder(root)}")
print(f"DFS inorder {inorder(root)}")
print(f"DFS postorder {postorder(root)}")
Forwarded from DevFM
Практика распила монолита
Несколько лет в индустрии шли жаркие споры "микросервисы против монолитов". У каждой из сторон было множество адептов. Однозначного решения нет.
Нам, как разработчикам, интересна статья про переход от монолитной архитектуры к микросервисной. Своё повествование автор ведет в разрезе высокоуровневых задач, которые приходится решать при использовании микросервисной архитектуры:
— оркестрация, управление множеством сервисов, их масштабированием и распределением нагрузки между разными серверами
— контейнеризация и хранение контейнеров
— применение API Gateway, настоящего швейцарского ножа в мире микросервисов для решения сотни инфраструктурных задач
— организация межсервисного взаимодействия. Вопрос организации остро встаёт с ростом числа команд, занимающихся разными сервисами. Без выстроенного взаимодействия уровень энтропии быстро нарастает, а проект превращается в хаос
— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование
— шаблоны сервисов — не совсем очевидный пункт, но очень важный. Всё, что приведено выше, обычно решается в процессе расширения системы. Шаблонами же следует заняться с самого начала. В будущем сэкономит много времени и позволит избежать зоопарка таких похожих, но таких разных сервисов :)
В статье приводятся не только теоретические выкладки, но и конкретные инструменты. Отдельно можно порекомендовать сервис, которым пользуется автор для выбора инструментов — Cloud Native Computing Foundation. Очень классная интерактивная и наглядная карта, где для различных задач собраны сервисы, решающие эти задачи.
В заключении автор напоминает: прежде чем внедрять — подумайте, какие задачи и проблемы вы этим решаете. Эта истина применима к любой технологии
#skills
Несколько лет в индустрии шли жаркие споры "микросервисы против монолитов". У каждой из сторон было множество адептов. Однозначного решения нет.
Нам, как разработчикам, интересна статья про переход от монолитной архитектуры к микросервисной. Своё повествование автор ведет в разрезе высокоуровневых задач, которые приходится решать при использовании микросервисной архитектуры:
— оркестрация, управление множеством сервисов, их масштабированием и распределением нагрузки между разными серверами
— контейнеризация и хранение контейнеров
— применение API Gateway, настоящего швейцарского ножа в мире микросервисов для решения сотни инфраструктурных задач
— организация межсервисного взаимодействия. Вопрос организации остро встаёт с ростом числа команд, занимающихся разными сервисами. Без выстроенного взаимодействия уровень энтропии быстро нарастает, а проект превращается в хаос
— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование
— шаблоны сервисов — не совсем очевидный пункт, но очень важный. Всё, что приведено выше, обычно решается в процессе расширения системы. Шаблонами же следует заняться с самого начала. В будущем сэкономит много времени и позволит избежать зоопарка таких похожих, но таких разных сервисов :)
В статье приводятся не только теоретические выкладки, но и конкретные инструменты. Отдельно можно порекомендовать сервис, которым пользуется автор для выбора инструментов — Cloud Native Computing Foundation. Очень классная интерактивная и наглядная карта, где для различных задач собраны сервисы, решающие эти задачи.
В заключении автор напоминает: прежде чем внедрять — подумайте, какие задачи и проблемы вы этим решаете. Эта истина применима к любой технологии
#skills
Хабр
Микросервисы для чайников: как на них перейти с монолита с нуля
Меня зовут Семен Катаев , я работаю в Авито над процессом перехода от монолитной архитектуры к микросервисам. Переход у нас все еще продолжается, но мне уже есть чем с вами поделиться. Это краткий...
Forwarded from Big data world
This media is not supported in your browser
VIEW IN TELEGRAM
Представляем PivotTableJS,которыйпозволяет интерактивно анализировать данные в Jupyter 🚀
https://shly.link/ghM2PV
https://shly.link/ghM2PV
#interview #ml #systemdesign
По описанию показалось, что там много материала. Но пробежаться достаточно
По описанию показалось, что там много материала. Но пробежаться достаточно
Forwarded from Записки MLEшника (Egor)
Как говорил Сократ: "Я знаю только то, что ничего не знаю". Словил сегодня вечером это чувство, когда блуждал по репе Тинькоф.
В секции подготовки к мл интервью много всякой годноты. Тут помимо прочего прилично ссылок на рускоязычные курсы, а тут по дизайну мл систем.
Ех, вот и как развиваться, когда глаза разбегаются 🥲
В секции подготовки к мл интервью много всякой годноты. Тут помимо прочего прилично ссылок на рускоязычные курсы, а тут по дизайну мл систем.
Ех, вот и как развиваться, когда глаза разбегаются 🥲
Forwarded from DevFM
Покоряем большие CSV
Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.
В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра
— разбиение большого файла на части, с которыми дальше удобнее работать
— перемешивание строк в файле. Такое бывает нужно, когда данные используются для обучения модельки машинного обучения
— хранение в виде столбцов ускорит выполнение запросов путём ограничения данных, среди которых идет поиск. Этот пункт достаточно хардкорный, рекомендуем пройтись отладчиком по коду — иначе не разобраться в нюансах
Мы на практике неоднократно сталкивались с гигабайтными CSV, которые иногда даже не умещались в оперативную память.
Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python
Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.
В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра
— разбиение большого файла на части, с которыми дальше удобнее работать
— перемешивание строк в файле. Такое бывает нужно, когда данные используются для обучения модельки машинного обучения
— хранение в виде столбцов ускорит выполнение запросов путём ограничения данных, среди которых идет поиск. Этот пункт достаточно хардкорный, рекомендуем пройтись отладчиком по коду — иначе не разобраться в нюансах
Мы на практике неоднократно сталкивались с гигабайтными CSV, которые иногда даже не умещались в оперативную память.
Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python
Medium
Working with large CSV files in Python from Scratch
5 Techniques