Использование Jupyter Notebook для разведочного анализа данных ⬝ Методические рекомендации

Блокноты Jupyter — это, уже довольно давно, один из самых неоднозначных инструментов в среде дата‑сайентистов. Одни яро критикуют Jupyter, другие горячо поддерживают этот проект. Но, тем не менее, многие согласятся с тем, что блокноты Jupyter, при правильном их использовании, могут быть очень ценным инструментом. Именно этому и посвящена данная статья — вторая в серии моих материалов про науку о данных и машинное обучение. Я поделюсь здесь методическими рекомендациями по использованию Jupyter Notebook для разведочного анализа данных.

Но для начала нам надо ответить на вопрос о том, почему блокноты Jupyter обосновались именно в научном сообществе. Когда тема Data Science была у всех на слуху, блокноты Jupyter ещё ничего из себя не представляли. До них у нас был IPython, интерактивная оболочка для Python, которую встраивали в различные IDE, вроде Spyder. Эти IDE пытались подражать работе RStudio или Matlab. Подобные инструменты получили широкое распространение среди исследователей.

В 2014 году из среды IPython вырос проект Jupyter. Масштабы его использования очень быстро стали просто огромными, чему, в основном, способствовали исследователи, которые перенесли в бизнес‑среду то, чем пользовались, занимаясь наукой. Но те подходы к использованию блокнотов, которые хороши для научных учреждений, не всегда нормально переносятся на анализ данных, проводимый в обычных организациях. Часто бывает так, что дата‑сайентистам, взятым на работу сразу после университета, очень сложно выдать то, что от них ожидают в бизнесе. Речь идёт о структуре аналитических разработок и об оформлении их результатов.

В этой статье мы поговорим о блокнотах Jupyter именно с точки зрения бизнеса, с точки зрения их применения в работе над реальными продуктами. Как я уже сказал, Jupyter — это тема спорная, поэтому я сразу озвучу то, что я о них думаю:

Блокноты Jupyter следует использовать ТОЛЬКО для разведочного анализа данных и для каких‑то расчётов, выполняемых от случая к случаю.

Блокнот — это не более чем отчёт. Так его и следует воспринимать. Важность кода, который он содержит, должна стремиться к нулю. Значение имеет лишь результат, который генерируется этим кодом. В идеале у нас должна быть возможность скрыть код, который содержится в блокноте, так как этот код представляет собой лишь инструмент, задача которого — дать ответ на некий вопрос.

Вот примеры таких вопросов:

• Каковы статистические характеристики данных в таблицах?

• Каковы свойства обучающего набора данных?

• Какое воздействие на организацию может оказать применение некоей модели в продакшне?

• Как удостовериться в том, что новая модель показывает лучшие результаты, чем предыдущая?

• Как выполняется данный AB‑тест?

Блокноты Jupyter могут пригодиться в различных сферах деятельности, они подходят для решения разных задач: исследование наборов данных, анализ экспериментов, анализ воздействия чего-либо на бизнес, моделирование

Блокноты Jupyter: рекомендации по эффективному сторителлингу

Когда делают записи в блокнот Jupyter — то, по сути, рассказывают некую историю, или отвечают на вопрос об исследуемой задаче. Но это не означает, что надо показывать тем, кто увидит блокнот, ту работу, которая проделана ради того, чтобы сделать некие выводы.

Блокноты Jupyter надо совершенствовать.

Блокноты существуют, преимущественно для того, чтобы тот, кто их создаёт, смог бы с их помощью разобраться в некоей проблеме. Но существуют они и для того, чтобы коллеги создателей блокнотов могли бы узнать то, к чему приходят их создатели, не вникая при этом в подробности задач, решаемых в блокнотах.

Исследуемая проблема

Когда в блокнотах исследуют наборы данных — такая деятельность обычно отличается нелинейным, древовидным характером. В них обычно содержатся разделы, представляющие собой тупиковые ветки исследований, эксперименты, проводимые в которых, не дают никаких ценных результатов. Если блокнот содержит результаты некоего исследования — в нём, после завершения работы, не должно быть ничего лишнего. Блокнот должен содержать минимальный объём выводов, которые представляют собой наилучший ответ на изучаемый вопрос. Каждое предположение, каждый вывод всегда должны снабжаться пояснительными комментариями.

Рекомендуется всегда включать в блокнот резюме исследования. Такие резюме отлично подходят для тех, кто как‑то заинтересован в исследовании, кто быстро просматривает материалы и уделяет задачам, исследуемым в блокнотах, лишь весьма ограниченное время. Краткие сводки, кроме того, хорошо помогают подготовить коллег создателей блокнотов к более глубокому знакомству с тонкостями исследований.

Аудитория, на которую рассчитан блокнот

Люди, которые читают блокноты Jupyter, обычно или хорошо разбираются в технологиях, или нацелены на задачи бизнеса. В результате вполне ожидаемо то, что в тексте блокнота будут встречаться специальные термины. Но при этом резюме или некие выводы всегда стоит писать простым языком, давая ссылки на отдельные разделы блокнота, содержащие более глубокие пояснения различных идей. Если вы ловите себя на мысли о том, что вам тяжело составить блокнот, рассчитанный на людей, далёких от технологий, то вам, возможно, стоит задуматься о том, чтобы создать не блокнот Jupyter, а обычную презентацию. Там можно использовать инфографику, всяческие понятные рисунки, там в вашем распоряжении будет более широкий диапазон средств для объяснения своих идей.

Лица, заинтересованные в результатах деятельности дата-сайентиста, предъявляют к ним различные требования. Это — его коллеги, специалисты по машинному обучению и по работе с данными, продакт-менеджеры, руководство компании.

Описание ситуации

Составляя блокнот — всегда описывайте то, что окружает исследуемую задачу. Одних только данных не достаточно для того чтобы рассказать связную историю. Поэтому надо показывать весь анализ в том контексте, в той сфере деятельности, к которым он относится. Благодаря этому читателям блокнота будет легче и удобнее воспринимать прочитанное. Для подкрепления своих заявлений используйте ссылки на статьи из базы знаний компании. Соберите эти ссылки в отдельном разделе блокнота.

Структурирование содержимого блокнотов Jupyter

В этом разделе я расскажу о структуре блокнотов, которой я обычно пользуюсь. Может показаться, что такая структура избыточна, но я, всё равно, рекомендую создать шаблон блокнота, содержащий следующие разделы, оставив места, в которые можно внести то, что имеет отношение к вашему проекту. Подобные шаблоны, поддерживающие настройку под конкретную задачу, сэкономят вам массу времени и обеспечат единообразный внешний вид всех ваших блокнотов.

1. Заголовок. В идеале тут будет имя задачи из JIRA (или из любой программы для отслеживания задач), связанной с исследуемой в блокноте проблемой. Это позволяет вам и вашей аудитории однозначно связать ответ — блокнот, и вопрос — задачу JIRA.

2. Описание. Чего вы хотите достичь, решив задачу? Тут всё должно быть очень кратко.

3. Содержание. Записи в содержании должны вести к разделам блокнота, что позволяет читателю перейти прямо к тому разделу, который ему интересен. (Jupyter создаёт HTML‑якорь для каждого заголовка, полученного из исходного заголовка с помощью headline.lower().replace(” “, “-“). К таким заголовкам можно обращаться, используя простые Markdown‑ссылки, наподобие [section title3](#section‑title). В блокноте можно размещать и собственные якорные ссылки, добавляя в Markdown‑ячейки конструкции вида <a id=’your-anchor’></a>.)

4. Справочная информация. Тут могут быть ссылки на внутренние документы компании или на внешние ресурсы, содержащие сведения, как общие, так и специальные, используемые в ходе анализа, представленного в блокноте.

5. TL;DR или Резюме. Тут, очень кратко, надо объяснить результаты всего исследования, выделив ключевые выводы (или вопросы), к которым вы пришли.

6. Введение и история вопроса. Здесь надо показать задачу в той среде, в которой она родилась, добавить сведения о похожих задачах, встававших перед бизнесом, более подробно объяснить суть задачи.

7. Импорт библиотек и настройки. В этом разделе находятся команды для импорта библиотек и для выполнения различных настроек. Здесь надо сделать настройки, необходимые для библиотек сторонних разработчиков, вроде matplotlib или seaborn. Сюда же добавляют переменные окружения, вроде тех, что содержат даты и позволяют зафиксировать временные рамки исследования.

8. Исследуемые данные. Здесь надо описать таблицы или наборы данных, анализ или исследование которых выполняется в блокноте, надо дать ссылки на источники этих данных. В идеале — надо объяснить то, как создаются каждый набор данных или каждая таблица, рассказать о том, как часто они обновляются. Этот раздел можно связать с любым другим фрагментом документа.

9. Анализ. Ячейки, в которых производится анализ данных.

10. Итоги. Подробное объяснение ключевых результатов, полученных в разделе Анализ, со ссылками на конкретные фрагменты блокнота, в которых читатель может найти дальнейшие пояснения.

Помните о том, что при оформлении заголовков всегда нужно использовать Markdown‑форматирование. Его же надо применять и для выделения важных заявлений и цитат. Узнать подробности об использовании Markdown в Jupyter можно здесь.

Пример шаблона блокнота для разведочного анализа данных

Как организовать код в Jupyter Notebook

Читателю блокнота, в котором решают задачи разведочного анализа данных, не особенно важен код, отвечающий за выполнение SQL‑запросов, за первичную подготовку данных в датафреймах pandas, за создание графиков.

Но этот код важен для тех, кто проверяет блокнот, поэтому и подобный код надо поддерживать в хорошем состоянии — он должен обладать высоким качеством и хорошей читабельностью.

Поделюсь советами по поводу работы с кодом в блокнотах Jupyter.

Перемещение вспомогательных функции в обычные Python-модули

В общем случае можно сказать, что импорт функций, определённых в Python‑модулях — это лучше, чем определение их прямо в блокноте. Начнём хотя бы с того, что в Git сравнения разных версий.py‑файлов гораздо легче читать, чем сравнения разных версий кода блокнотов. При таком подходе читателю, чтобы разобраться в блокноте, не надо знать о том, чем именно занимается функция.

Например, обычно в блокнотах применяются функции для чтения данных, для выполнения SQL‑запросов, для предварительной обработки, преобразования, расширения используемых наборов данных. Все эти функции стоит перенести в.py‑файлы, а затем импортировать в блокнот, чтобы читатель видел лишь вызовы функций. Если тому, кто проверяет блокнот, нужно больше деталей — он всегда может заглянуть в соответствующий Python‑модуль.

Я нахожу такой подход особенно полезным, например, при оформлении функций, ответственных за визуализацию данных. Часто бывает так, что одну и ту же функцию, скажем, для построения столбчатой диаграммы, я использую во многих местах блокнота. При этом мне надо вносить в такие диаграммы небольшие изменения — вроде использования разных наборов данных или разных заголовков, но макет и стиль диаграмм остаются одинаковыми. Вместо того чтобы постоянно копипастить одни и те же куски кода, я просто создаю модуль utils/plots.py и размещаю в нём функции, которые можно импортировать в блокнот и адаптировать к каждой конкретной ситуации, передавая им аргументы.

Вот — простой пример такого модуля:

import matplotlib.pyplot as plt
import numpy as np
 
def create_barplot(data, x_labels, title='', xlabel='', ylabel='', bar_color='b', bar_width=0.8, style='seaborn', figsize=(8, 6)):
    """Создаёт настраиваемую столбчатую диаграмму с использованием Matplotlib.
 
    Параметры:
    - data: Список или массив с данными, которые нужно вывести на диаграмме.
    - x_labels: список подписей для оси x.
    - title: Заголовок диаграммы.
    - xlabel: Подпись для оси x.
    - ylabel: Подпись для оси y.
    - bar_color: Цвет столбцов (по умолчанию - синий).
    - bar_width: Ширина столбцов (по умолчанию -  0.8).
    - style: Стиль Matplotlib, используемый для диаграммы (например - 'seaborn', 'ggplot', 'default').
    - figsize: Кортеж, задающий размер фигуры (ширину и высоту).
 
    Возвращает:
    - Ничего
    """
    # Задать стиль Matplotlib
    plt.style.use(style)
 
    # Создать фигуру и ось
    fig, ax = plt.subplots(figsize=figsize)
 
    # Сгенерировать позиции x для столбцов
    x = np.arange(len(data))
 
    # Создать диаграмму
    ax.bar(x, data, color=bar_color, width=bar_width)
 
    # Задать подписи для оси х 
    ax.set_xticks(x)
    ax.set_xticklabels(x_labels)
 
    # Задать подписи и заголовок
    ax.set_xlabel(xlabel)
    ax.set_ylabel(ylabel)
    ax.set_title(title)
 
    # Показать диаграмму
    plt.show()
 
# Пример использования в ячейке блокнота
create_barplot(
    data,
    x_labels,
    title=”Customizable Bar Plot”,
    xlabel=”Categories”,
    ylabel=”Values”,
    bar_color=”skyblue”,
    bar_width=0.6,
    style=”seaborn”,
    figsize=(10,6)
)

Создавая подобные Python‑модули, помните о том, что код, находящийся в них, является частью вашего проекта по разведочному анализу данных. Поэтому, если только вы не используете этот код в каких‑то других частях проекта, он не должен быть идеальным. Достаточно — чтобы он был бы читабельным, чтобы его могли бы понять те, кто делает код‑ревью блокнота.

Функции для вывода графиков, для загрузки и подготовки данных, для расчёта каких-то метрик, рекомендуется размещать в обычных Python-модулях. Это позволяет, в тексте самого Jupyter-блокнота, сосредоточится на разведочном анализе данных.

Использование SQL в ячейках Jupyter-блокнота

В некоторых случаях данные находятся не в памяти (например — в объекте pandas DataFrame), а в хранилище компании (вроде Redshift). В подобных случаях большая часть операций по исследованию и первичной обработке данных выполняется посредством SQL.

Существует несколько способов использования SQL в блокнотах Jupyter. Так, JupySQL позволяет писать SQL‑код прямо в ячейках блокнота и выводит результаты запросов так, как если бы они были бы датафреймами pandas. SQL‑скрипты, кроме того, можно хранить в сопутствующих файлах, или в дополнительных Python‑модулях, о которых мы говорили в предыдущем разделе.

Применение того или иного способа работы с SQL зависит, в основном, от нужд конкретного проекта.

Если вы заняты анализом, в ходе которого используется несколько таблиц из хранилища данных, и вы хотите продемонстрировать коллегам качество и правильность этих данных, тогда, как правило, самый лучший вариант — это показ SQL‑запросов в самом блокноте. Те, кто делает код‑ревью, оценят то, что они могут сразу видеть то, как именно выполняются запросы к таблицам, то, какие соединения данных выполняются для получения определённого результата, то, какие фильтры понадобилось применить, и так далее.

Но если вы всего лишь генерируете набор данных для проверки модели машинного обучения, и главное в блокноте — показ различных метрик и объяснимость выходных данных — тогда я порекомендовал бы как можно лучше скрыть операции по подготовке набора данных и держать запросы в отдельном SQL‑скрипте или в Python‑модуле.

Рассмотрим примеры, демонстрирующие применение обоих подходов.

Чтение и выполнение запросов из .sql-файлов скриптов

Можно пользоваться .sql-файлами, которые открывают и выполняют из блокнота посредством библиотеки для соединения с базами данных.

Предположим, имеется следующий запрос, хранящийся в файле select_purchases.sql:

SELECT * FROM public.ecommerce_purchases WHERE product_id = 123

Для его выполнения можно определить такую функцию:

import psycopg2
 
def execute_sql_script(filename, connection_params):
    """
    Выполняет SQL-скрипт из файла, используя psycopg2.
 
    Параметры:
    - filename: Имя файла с SQL-скриптом, который нужно выполнить.
    - connection_params: Словарь, содержащий параметры соединения PostgreSQL,
                        такие, как 'host', 'port', 'database', 'user', и 'password'.
 
    Возвращает:
    - Ничего
    """
    # Извлечь параметры соединения
    host = connection_params.get('host', 'localhost')
    port = connection_params.get('port', '5432')
    database = connection_params.get('database', '')
    user = connection_params.get('user', '')
    password = connection_params.get('password', '')
 
    # Установить соединение с базой данных
    try:
        conn = psycopg2.connect(
            host=host,
            port=port,
            database=database,
            user=user,
            password=password
        )
        cursor = conn.cursor()
 
        # Прочитать и выполнить SQL-скрипт
        with open(filename, 'r') as sql_file:
            sql_script = sql_file.read()
            cursor.execute(sql_script)
        
        # Загрузить результат в объект Pandas DataFrame
        result = cursor.fetchall()
        column_names = [desc[0] for desc in cursor.description]
        df = pd.DataFrame(result, columns=column_names)

        # Применить изменения и закрыть соединение
        conn.commit()
        conn.close()
        return df

    except Exception as e:
        print(f"Error: {e}")
        if 'conn' in locals():
            conn.rollback()
            conn.close()

Обратите внимание на то, что мы должны предоставить системе значения параметров подключения к базе данных, применяемые по умолчанию. Это позволит не указывать их каждый раз при работе с блокнотом. Но тут стоит помнить о том, что в Python‑скрипты никогда не должны попадать секретные данные или другая важная информация! (Позже, в других публикациях из этой серии, мы обсудим различные способы решения этой задачи).

Теперь в блокноте можно, для выполнения скрипта, воспользоваться следующей однострочной конструкцией:

df = execute_sql_script('select_purchases.sql', connection_params)

Использование JupySQL

До недавнего времени для выполнения SQL‑запросов из блокнотов Jupyter обычно использовалась библиотека ipython‑sql. Но в апреле 2023 года её создатель сообщил о том, что её дни сочтены, и порекомендовал переключиться на JupySQL — её форк, над которым ведётся активная работа. Теперь все улучшения и новые возможности будут появляться только в JupySQL.

Для того чтобы установить библиотеку ради использования её с Redshift, надо сделать следующее:

pip install jupysql sqlalchemy-redshift redshift-connector 'sqlalchemy<2'

(Её можно использовать и с другими базами данных, вроде snowflake или duckdb).

В Jupyter-блокноте теперь можно будет использовать «магическую» SQL-команду %load_ext для включения SQL, и применить следующий фрагмент кода для создания объекта sqlalchemy.engine для Redshift:

from os import environ
from sqlalchemy import create_engine
from sqlalchemy.engine import URL
 
user = environ["REDSHIFT_USERNAME"]
password = environ["REDSHIFT_PASSWORD"]
host = environ["REDSHIFT_HOST"]
 
url = URL.create(
    drivername="redshift+redshift_connector",
    username=user,
    password=password,
    host=host,
    port=5439,
    database="dev",
)
 
engine = create_engine(url)

А потом достаточно передать объект engine «магической» команде:

%sql engine --alias redshift-sqlalchemy

Готово!

С этого момента всё выглядит крайне просто — берём «магическую» команду и пишем любые запросы, которые нужно выполнить. Их результаты попадут в выходные данные ячейки:

%sql
SELECT * FROM public.ecommerce_purchases WHERE product_id = 123

Проверка того, что код ячеек выполняется по порядку

Рекомендую всегда выполнять все ячейки с кодом перед отправкой блокнота в репозиторий. Блокноты Jupyter сохраняют выходное состояние каждой ячейки после её выполнения. Это означает, что код, который был написан или отредактирован, может не соответствовать тем данным, что присутствуют на выходе ячейки.

Выполнение кода блокнота от начала и до конца — это ещё, кроме прочего, хороший способ проверить, нужно ли пользователю что‑либо вводить для того чтобы обеспечить правильную работу блокнота. В идеале всё должно просто выполниться без какого‑либо вмешательства с вашей стороны. Если это не так — значит, проведённый вами анализ, скорее всего, не сможет воспроизвести кто‑то другой, или даже, в будущем, вы сами.

Один из способов проверки того, что все ячейки блокнота были выполнены в правильном порядке — это использование хука pre‑commit nbcheckorder. Он проверяет, выполняются ли ячейки друг за другом. Если это не так — это указывает на то, что ячейки не были выполнены одна за другой, и хук не даёт сделать коммит в Git‑репозиторий.

Вот пример файла .pre-commit-config.yaml:

- repo: local
   rev: v0.2.0
   hooks:
     - id: nbcheckorder

Если вы ещё не пользуетесь pre‑commit‑хуками — я очень рекомендую вам взять на вооружение этот маленький инструмент. Советую начать их изучение с этого материала. Позже можете обратиться к подробной документации по ним для того чтобы разобраться со всеми их возможностями.

Очистка выходных данных ячеек

Вот совет, который даже лучше, чем предыдущий: очищайте выходные данные ячеек блокнотов. Одно из преимуществ, которое это даёт, заключается в том, что это позволяет игнорировать состояния ячеек и их выходные данные. Но, с другой стороны, это принуждает тех, кто делает код‑ревью блокнота, выполнять код локально в том случае, если им нужно увидеть результаты работы кода.

Для решения этой задачи можно воспользоваться, вместе с другими pre‑commit‑хуками, хуком nbstripout, делая это в соответствии с пояснениями его автора на GitHub.

- repo: local
  rev: 0.6.1
  hooks:
    - id: nbstripout

Ещё можно воспользоваться командой nbconvert --ClearOutputpPreprocessor в пользовательском pre-commit хуке, как рассказано здесь.

  - repo: local
    hooks:
      - id: jupyter-nb-clear-output
        name: jupyter-nb-clear-output
        files: \.ipynb$
        stages: [ commit ]
        language: python
        entry: jupyter nbconvert --ClearOutputPreprocessor.enabled=True --inplace
        additional_dependencies: [ 'nbconvert' ]

Создание отчётов с помощью Jupyter Notebook и предоставление их заинтересованным лицам

Теперь мы подошли к вопросу, на который нет чёткого ответа. Как лучше всего поделиться блокнотом с членами команды и с другими заинтересованными лицами?

В вопросе показа результатов анализа, проведённого в блокнотах Jupyter, имеется разделение на три направления, которые соответствуют различным типам команд, где одобряются разные подходы к работе.

Команды «переводчиков»

Члены таких команд уверены в том, что управленцам или продакт‑менеджерам неудобно читать Jupyter‑блокноты в их исходном виде. Поэтому они адаптируют результаты своих анализов и отчёты в расчёте на ожидаемую аудиторию.

«Переводчики» берут результаты своих изысканий из блокнотов и добавляют их в базы знаний компаний (например — Confluence, Google Slides и так далее). Среди отрицательных побочных эффектов такого подхода можно отметить то, что из‑за этого, в некоторой степени, теряется связь с исходными блокнотами. Дело в том, что так сложнее становится просмотреть историю различных версий отчёта. Но «переводчики» защищают свою позицию тем, что это позволяет им эффективнее донести результаты их исследований до заинтересованных лиц.

Если вам близка эта идея — рекомендую поддерживать связь между экспортированным документом и блокнотом Jupyter, на котором он основан, сделав так, чтобы они всегда были бы синхронизированы. При таком подходе можно пользоваться блокнотами, в которых будет меньше текста и выводов, уделив внимание, в основном, необработанным фактам или свидетельствам чего‑либо, которые дают сами данные. А система документации компании будет использоваться для расширения резюме исследований и для комментирования полученных результатов. В таком случае можно разделить то, что получается на выходе исследования: код, с помощью которого изучают данные, и результаты их изучения.

Команды, дающие всем доступ к исходным блокнотам

Такие команды используют локальные Jupyter‑блокноты и дают доступ к ним всем остальным бизнес‑подразделениям компаний, создавая решения, привязанные к базам знаний и инфраструктуре компаний. Дата‑сайентисты из таких команд твёрдо уверены в том, что все, кто заинтересован в результатах их работы, должны обладать возможностью понять то, что имеется в их блокнотах. Они уверены и в том, что нужно поддерживать чёткую связь между результатами исследования и исходными данными.

Но вряд ли члены финансового отдела компании обратятся к GitHub или к Bitbucket для того чтобы почитать блокноты дата‑сайентистов.

Я видел несколько решений, реализованных в этой сфере. Например — можно воспользоваться чем‑то вроде nbconvert для генерирования PDF‑файлов из блокнотов Jupyter. Блокноты можно экспортировать и в HTML. Это позволит легко делиться ими с кем угодно, даже с теми, кто не входит в состав технических команд.

Блокноты можно даже переместить в хранилище Amazon S3 и захостить их там в виде статических, уже сформированных веб‑сайтов. Можно воспользоваться механизмами CI/CD для того чтобы создавать из блокнотов HTML‑страницы, рендерить их и отправлять в хранилище в том случае, когда код добавляется в некую ветку репозитория.

Команды — приверженцы инструментов сторонней разработки

Такие команды применяют инструменты, которые позволяют им не только заниматься разработкой блокнотов, но и помогают делиться результатами своих исследований с другими людьми из их организации. Сюда обычно входит упрощение различных сложных задач вроде обеспечения безопасности и простого доступа к внутренним хранилищам компании, к озёрам данных, к базам данных.

Среди подобных инструментов наиболее широкое распространение получили Deepnote, Amazon SageMaker, Google Vertex AI и Azure Machine Learning. Это — полноценные платформы для работы с блокнотами, которые позволяют разворачивать виртуальные окружения на удалённых машинах, используемые для выполнения пользовательского кода. Они предоставляют инструменты для интерактивного построения графиков, для исследования данных и результатов экспериментов. Это упрощает весь жизненный цикл data science‑проектов. Например, SageMaker позволяет визуализировать всю информацию по экспериментам, наблюдение за которой организовано с помощью Sagemaker Experiments. А Deepnote очень сильно облегчает визуализацию данных с помощью инструмента Chart Blocks.

И, помимо этого, Deepnote и SageMaker позволяют делиться блокнотами с коллегами. Доступ к блокнотам может выглядеть и как разрешение на их чтение, и как организация совместной работы в реальном времени с использованием той же самой среды выполнения блокнотов.

Существуют и опенсорсные альтернативы этим инструментам, такие, как JupyterHub. Но для приведения их в рабочее состояние требуются неоправданно большие усилия на их настройку и поддержку. Локальное развёртывание JupyterHub может оказаться не самым удачным решением, прибегать к которому имеет смысл лишь в очень редких случаях (например — когда речь идёт об очень особенных рабочих нагрузках, требующих применения весьма специфического аппаратного обеспечения). Используя облачные службы вы можете задействовать экономические механизмы, связанные с масштабированием. Они гарантируют применение архитектур, гораздо лучше защищённых от сбоев, чем способны предложить компании, работающие в других сферах бизнеса. Размышляя об опенсорсных решениях, нужно учесть стоимость их первоначальной настройки. Нужно обеспечить, чтобы команда, занимающаяся ИТ‑системами компании, поддерживала бы эти решения в рабочем состоянии, давая дата‑сайентистам доступ к ним. Нужно гарантировать информационную безопасность решения и защиту данных. Получается, что выбор управляемых сервисов позволяет избежать бесконечных сложностей, связанных с поддержкой собственной инфраструктуры.

В целом — дам такой совет относительно исследования подобных продуктов: если ваша компания уже работает с провайдером облачных услуг вроде AWS, Google Cloud Platform или Azure — то, возможно, стоит подумать о внедрении у себя и решений этого провайдера, нацеленных на Jupyter‑блокноты. Это позволит упростить работу с инфраструктурой компании и будет менее рискованно, чем выбор совершенно нового провайдера.

Освоение методических рекомендаций по работе с Jupyter Notebook

В этом материале мы обсудили методические рекомендации и советы по оптимизации работы с блокнотами Jupyter.

Вот самый главный вывод, который можно сделать:

Всегда приступайте к работе над блокнотом, учитывая то, на какую аудиторию он рассчитан, и то, какова конечная цель его создания. При таком подходе вы будет знать о том, сколько внимания нужно будет уделить различным аспектам блокнота (коду, анализу, резюме и прочему).

В итоге скажу, что я горячо рекомендую дата‑сайентистам пользоваться платформой Jupyter Notebook, но — только для разведочного анализа данных и для создания отчётов.

Продакшн‑артефакты, такие, как модели, наборы данных, или гиперпараметры, не должны быть напрямую связаны с блокнотами. То, на чём они основаны, должно находиться в продакшн‑средах, которые можно воспроизводить и перезапускать. Например, это SageMaker Pipelines или Airflow DAG — отлично поддерживаемые и хорошо проверенные системы.

О, а приходите к нам работать? 🤗 💰

Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.

Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.

Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.

Присоединяйтесь к нашей команде