惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
The Blog of Author Tim Ferriss
WordPress大学
WordPress大学
博客园 - Franky
The Cloudflare Blog
T
Tailwind CSS Blog
宝玉的分享
宝玉的分享
小众软件
小众软件
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Apple Machine Learning Research
Apple Machine Learning Research
月光博客
月光博客
B
Blog
Y
Y Combinator Blog
V
V2EX
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
博客园 - 司徒正美
IT之家
IT之家
G
Google Developers Blog
C
Check Point Blog
Engineering at Meta
Engineering at Meta
Microsoft Security Blog
Microsoft Security Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
GbyAI
GbyAI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Инфраструктура для изучения основ машинного обучения на л...
VOrlyanskiy · 2026-05-12 · via Все публикации подряд на Хабре

Уровень сложностиСредний

Время на прочтение4 мин

Охват и читатели11K

Это первая часть из двух. Вторая доступна по ссылке.

Соавтор

Данная статья создана с помощью @svantonov за что ему отдельная благодарность и признательность за помощь. Без него данный результат был бы не достижим.

Описание задачи

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

Первой задачей будет следующая. Предположим, откуда-то получаются файлы нескольких типов, например 10 различных типов. Один из получаемых типов будет вызывать увеличение загрузки процессора.

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

Эта статья посвящена описанию того, как создать исходные данные для анализа и запустить базовую инфраструктуру машинного обучения на локальном компьютере, но при этом готовую к практически бесконечному масштабированию благодаря использованию Apache Spark.

БД с исходными данными

Описание базы данных

Структура базы данных сделана максимально простой.

В качестве БД выбран PostgreSQL.

Для хранения информации о времени пришедших типов файлов создана таблица received_types. В ней два значимых поля: тип пришедшего файла и время его получения.

Для хранения информации о загрузке процессора создана таблица cpu_load. В ней три значимых поля:

  1. time_frame_start - время начала периода сбора информации о загрузке CPU.

  2. time_frame_finish - время окончания периода сбора информации о загрузке CPU.

  3. Процент загрузки CPU

Прямой связи между таблицами received_types и cpu_load нет. Связь между ними будет создаваться через поля времени.

Скрипт заполнения базы данных

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

Какой именно тип файла будет создавать увеличенную нагрузку на процессор, определяется в скрипте.

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

На втором этапе, в таблицу cpu_load создаются записи о загрузке процессора за каждые 5 секунд. Т. е. в выбранном диапазоне дат, для каждых 5 секунд создается запись.

Если в эти 5 секунд есть записи о пришедших типах файла с большой загрузкой, то для этих записей выбирается случайным образом загрузка процесса в диапазоне 70-99,99%.

Если в эти 5 секунд есть записи о пришедших других типах файлов, не вызывающих загрузку процессора, то выбирается случайным образом число в диапазоне 10-30%.

Если в эти 5 секунд, нет записей о пришедших файлах, то создается запись о загрузке процессора в пределах 1-5%.

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

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

Понимаемые ограничения и упрощения

В описанном примере есть ограничения и упрощения, так как это учебный пример самого начального уровня:

  1. Пришедший файл увеличивает загрузку ровно в том же диапазоне времени, в котором он пришел. В реальности файл, пришедший в конце периода, вызовет загрузку в следующем периоде.

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

Запуск инфраструктуры

PostgreSQL

Наиболее удобным и простым способом работы с PostgreSQL для локальной работы является запуск его в Docker. Описанию этого процесса посвящено множество инструкций, начиная с приведенной ссылки на сам сайт hub.docker.com, поэтому здесь не будет описания как устанавливать PostgreSQL.

Apache Spark

Причина выбора

В данном примере для инфраструктуры машинного обучения выбран Apache Spark в силу своей доступности, распространенности и возможности установки как в локальном варианте, показанном здесь, так и в рабочей инфраструктуре под большую нагрузку.

Как запускать

Сам Apache Spark имеет описание, как запускать его локально в Docker с помощью compose файлов. Однако для данного примера было решено разработать свой compose файл с целью решения следующих задач:

  1. Добавление в Apache Spark jdbc драйвера для подключения к PostgreSQL.

  2. Активация в Apache Spark работы через spark-connect, который облегчает работу с Apache Spark в задачах обучения и тестирования.

Проект для compose файла запуска Apache Spark с учетом описанных выше требований доступен по ссылке. Пояснения по используемому проекту:

  1. При запуске в образ apache-spark добавляется jdbc драйвер для подключения к PostgreSQL.

  2. В compose файл добавлен блок запуска spark-connect для облегчения работы с Apache Spark.

  3. При запуске Apache Spark скачивается библиотека поддержки Hadoop.

  4. Самым простым способом запуска выбран запуск проекта с помощью make файла командой make spark-up из корня проекта. Утилита make не входит в Windows. Для Windows ее придется искать и устанавливать отдельно.

Связь с PostgreSQL

Получается, что PostgreSQL и Apache Spark работают в разных виртуальных сетях Docker, и напрямую Apache Spark не сможет подключиться к PostgreSQL.

Для решения этой проблемы при запуске задач Apache Spark будет указываться адрес подключения PostgreSQL в таком виде:

DB_URL=jdbc:postgresql://host.docker.internal:5432/logs

где указание «host.docker.internal» приведет Apache Spark к IP-порту компьютера, на котором запущен Docker.

Конечно, можно создать общий docker compose файл для PostgreSQL и Apache Spark или связать их через общую docker сеть, но обсуждение таких нюансов выходит за рамки данной статьи.

Необходимые открытые IP порты

Для работы с PostgreSQL он должен быть доступен. Наиболее простым способом является открытие IP порта 5432 из Docker container для PostgreSQL.

IP порты для Apache Spark описаны в docker compose файле для Apache Spark в этом, этом и этом местах.

Версия Python

В следующей статье все примеры будут сделаны на Python с помощью PySpark. На текущий момент времени примеры работают на версии Python 3.12

Зависимости Python скриптов

Все зависимости описаны в requirements.txt. На данный момент времени они ограничены этими тремя:

  1. pyspark

  2. pyspark-client

  3. pyspark-stubs

Выводы

Описанная инфраструктура позволяет:

  1. Запустить на локальном компьютере, в Docker, связку Apache Spark + PostgreSQL.

  2. Создать базу данных с тестовыми данными.

  3. Подключиться к Apache Spark с целью запуска Spark задач.