Интересное что-то
552 subscribers
2.79K photos
253 videos
140 files
4.59K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.iss.one/asisakov_channel
Чат: https://t.iss.one/youknowds_chat
Download Telegram
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.
В тему последней рекламы платных курсов по питону. Перед тем, как брать курсы, посмотрите на тонны бесплатного материала. Сможете понять, надо ли вам оно

Если нужно, я подобрал годные бесплатные материалы (курсы, книги, лекции) по питону, SQL, git, тестам, докеру и другим нужным начинающему разработчику темам
#python #career

Тут в свободный доступ выложили книгу «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
В процессе реализации решений на Leetcode понял, что совсем не помню алгоритмы прохода по бинарному дереву 🌳.

Предлагаю вспомнить варианты поиска в глубину (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
Forwarded from Big data world
This media is not supported in your browser
VIEW IN TELEGRAM
Представляем PivotTableJS,которыйпозволяет интерактивно анализировать данные в Jupyter 🚀

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
#ml #finance
Цикл статей про ML в банках