Apache Hadoop

Источник: wikimedia.org

Hadoop — проект фонда Apache Software Foundation, созданный в 2005 году и предназначенный для эффективного хранения и обработки больших наборов данных объемом от сотен гигабайт до петабайтов.
Под словом Hadoop может подразумеваться:
— Несколько сервисов, составляющих ядро Hadoop (YARN, HDFS, MapReduce)
— Вся экосистема сервисов Hadoop
— Кластер под управлением Hadoop

Предпосылки создания Hadoop

Из-за значительного роста обрабатываемых данных (терабайты, петабайты) действующие на тот момент системы уже эффективно не справлялись с обработкой такого потока данных. Помимо этого необходимо было где-то разместить (хранить) такое кол-во данных без потери информации, с сохранением ее постоянной доступности. Так появилась потребность в распределенном хранилище данных. Чтобы обеспечить высокую пропускную способность большого кол-ва данных необходимо было распараллелить вычисления эффективным и отказоустойчивым способом на кластере машин. Кроме того появление новых источников нетабличных данных как, например, логи, содержимое веб-страниц, тоже являлось предпоссылкой создания нового решения обработки и хранения данных, так как сложно решить данные задачи посредством обычных реляционных БД. Одним из основных достоинств Hadoop является то, что он проектировался так, чтобы стабильно работал на кластерах серверов не премиального класса.

В то время при разработке приложений для распределенной обработки данных возникали следующие проблемы:
1) В кластере серверов сложно определить какой сервер является лидером, то есть сервер, который управляет всеми остальными
2) Проблема координации кластера
3) Отсутствие достаточной отказоустойчивости. При реализации сценария выхода из строя одной ноды не было четкого плана действий, механизмов у кластера для автоматического восстановления работы системы или продолжения функционирования системы без отказавших нод
4) Проблема консистентности данных. Сложность разработки приложения с распределенной обработкой
5) Отсутствие инструмента по управлению приоритетов обработки данных, по управлению вычислительными ресурсами кластера (CPU, RAM, HDD) в том числе если ресурсы запрашивают сразу несколько приложений

Поэтому чтобы решить все вышеперечисленные проблемы был создан Hadoop.

Ядро Hadoop 2.0

Источник: www.dotnettricks.com

MapReduce — это фреймворк для обработки наборов данных с помощью параллельного распределенного алгоритма
HDFS — файловая система, предназначенная для хранения файлов больших размеров, поблочно распределенных между узлами вычислительного кластера
YARN — модуль, отвечающий за управление ресурсами кластеров и планирование заданий
Others data processing — остальные фреймворки по процессингу данных, например, Apache Spark, Apache Kafka, которые позволяют обрабатывать данные с помощью новых оптимизаций, что приводит к значительному приросту производительности по сравнению с MapReduce

Apache ZooKeeper

Apache ZooKeeper — инструмент, который следит за синхронизацией, координацией, состоянием всего кластера распределенных приложений. ZooKeeper позволяет Big Data разработчику сосредоточиться над логикой своего приложения, вся координация сервисов ложится на плечи ZooKeeper. Apache ZooKeeper представляет из себя консистентную файловую систему небольшого размера.

Источник: dataview.in

Архитектура HDFS

Источник: linkedin.com

HDFS (Hadoop Distributed File System) — это распределенная файловая система для хранения файлов больших размеров, поблочно распределенной по узлам вычислительного кластера. Любая файловая система состоит из иерархии каталогов с вложенными в них подкаталогами и файлами.

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

Secondary NameNode — отдельный сервер, единственный в кластере, который копирует образ HDFS (fsimage) и лог транзакционных операций (чтения, записи, удаления и т. д.) с файловыми блоками, применяет изменения, накопленные в логе к образу HDFS, а также записывает его на узел NameNode. Secondary NameNode необходим для быстрого ручного восстановления NameNode в случае его выхода из строя.

fsimage — образ файловой системы HDFS, в котором хранятся логи операций, которые происходили на NameNode. Так как вычитывать все операции логов над блоками за глубокую историю HDFS неэффективно, значит нужно объединять (merge) предыдущую версию логов операций с файловой системой с новоприбывшей пачкой логов. Данный процесс и происходит в fsimage, где он периодически обновляется новыми логами. В случае выхода из строя NameNode и его успешного восстановления, то чтобы ему вернуться к актуальному состоянию файловой системы HDFS происходит чтение fsimage с последнего объединения логов в Secondary NameNode.

DataNodes — множество серверов в кластере, отвечающие за файловые операции, хранение и работу с блоками данных. Основная необходимость DataNode — это чтение и запись данных, выполнение команд от NameNode по созданию, удалению и репликации блоков, а также периодическую отправку сообщений о состоянии обработки запросов на чтение и запись, поступающих от клиентов файловой системы HDFS.

Источник: phoenixnap.com

Блоки и файлы
Файл — это только запись в мета-данных на NameNode, содержимое же файла хранится в нескольких блоках одинакового размера на DataNode’ах. Основное назначение блоков в том чтобы сделать процесс чтения и записи предсказуемым. Сложно управлять одним большим файлом, переместить с одного сервера на другой, так как он может быть большим по объему. Когда нам нужно прочитать этот файл, то мы смотрим в справочник метаданных на NameNode и узнаем на каких DataNode’ах находятся блоки этого файла.

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

Источник: stackoverflow.com

Репликация — процесс создания копии данных с целью обеспечения сохранности данных, в случае потери одной реплики у нас всегда оставалась запасная, резервная. Создавая файл в HDFS можно указать размер файла (64 МБ по умолчанию) и кол-во реплик, по умолчанию 3. Для достижения максимальной надежности 2 и 3 реплика помещаются на разные стойки узлов данных. HDFS следит за тем, что если какие-то файлы у него недореплицированы, то он сам автоматически начинает их реплицировать до нужного количества.

Источник: hadoop.apache.org

Чтение данных в HDFS
Клиент HDFS запрашивает информацию у NameNode через специальный интерфейс Distributed File System о файле, проверяет существует ли он, какие права доступа. В случае прохождения всех этапов проверки NameNode выдает клиенту информацию о файле, где находятся его блоки на DataNode. Получив эту информацию клиент с помощью интерфейса FSDataInputStream идет на каждую DataNode’у и выкачивает нужную информацию.

Источник: javatpoint.com

Запись данных в HDFS
Клиент HDFS иниицирует запрос на запись файла к NameNode. NameNode со своей стороны проверяет существует ли такой файл и есть ли у клиента права на запись в этот файл. Если проверки прошли успешно, то NameNode в своих мета-данных создает запись для файла. Далее клиент делит файл на несколько пакетов согласно установленному размеру блока и управляет ими в форме очереди данных. HDFS последовательно отправляет пакеты на запись в DataNode’у, создавая новые блоки. Запись происходит в 1 DataNode, дальше идет репликация записанного блока на две другие DataNode’ы, как только репликация завершается клиенту возвращается подтверждение (ack packet) того что запись файла завершена успешно.

Источник: javatpoint.com

Высокая доступность
NameNode (standby) — это сервер, который необходим в случае если активная NameNode в кластере выведена из строя. В Journal Node пишутся все изменения, а NameNode (standby) читает эти изменения и становится управляющим NameNode кластера в случае потери активной NameNode.

Источник: doc.hcs.huawei.com

YARN

YARN (Yet Another Resource Negotiator) — модуль, отвечающий за управление ресурсами кластера и планирование заданий. YARN работает с Java контейнерами, похожая сущность что у Kubernetes и Mesos, но YARN больше заточен для экосистемы Hadoop. Основная идея YARN состоит в том, чтобы предоставить абстракцию управления ресурсами и запуск/мониторинг задач двум отдельным компонентам: глобальному менеджеру ресурсов Resource Manager и локальному серверному менеджеру Node Manager.

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

Resource Manager выполняет следующие задачи:
— принимает задание от Client
— смотрит на доступные ресурсы и выбирает сервер, на котором есть доступные ресурсы
— запускает на сервере Application Master для того, чтобы следить как выполняется задание, успешно ли оно выполняется
— передает задание Application Master
— выделяет по запросу Application Master контейнеры с ресурсами

Application Master — главный контейнер в YARN, который отвечает за координацию всех остальных контейнеров. Если выходит из строя Application Master, то все остальные контейнеры тоже отключаются. На Application Master запускается JAR файл приложения, переданный от клиента, дальше Application Master запрашивает у Resource Manager запуск контейнеров, Resource Manager опрашивает на каких Node Manager есть свободные ресурсы, определившись у каких серверов есть необходимые ресурсы Application Master отправляет запросы этим Node Manager для запуска контейнеров. Само приложение внутри контейнера может иметь свой планировщик ресурсов, который может запрашивать дополнительные ресурсы у Resource Manager.

Node Manager — процесс, работающий на каждом вычислительном узле и отвечающий за запуск контейнеров приложений, мониторинг использования ресурсов контейнера (процессор, память, диск, сеть) и передачу этих данных Resource Manager.

Разделение ресурсов
YARN может приоритезировать какому приложению в первую очередь выделить ресурсы. Настроить приоритезацию можно следующим образом:
— Отдельная очередь для долгих тяжелых задач
— Отдельная очередь для мелких ad-hoc запросов
— Отдельная очередь для обучения ML моделей
— Отдельная очередь на каждый отдел и т. д.

Источник: edureka.co

MapReduce

MapReduce — это фреймворк для обработки наборов данных с помощью параллельного распределенонго алгоритма.

Вычислительная модель MapReduce состоит из 3 этапов:
map — каждый узел кластера, хранящий данные, применяет к каждой записи записи некоторую функцию и выдает результат в формате ключ-значение
shuffle — перераспределение данных по сети по вычислительным узлам на основе ключей из этапа map
reduce — применение аггрегирующей функции к сгруппированным данным благодаря этапу shuffle и расчет финального результата

Достоинства такого фреймворка:
— Можно обрабатывать огромные объемы данных
— Отказоустойчивость при обработке
— Data Locality — данные хранятся на тех же узлах, где происходят вычисления

Недостатки:
— Частые операции чтения и записи на диск
— Ограниченная область применения

Источник: todaysoftmag.com

Hive

Hive — пользовательский интерфейс, где написанный клиентом SQL запрос преобразуется в MapReduce job и запускается на Hadoop. Благодаря Hive можно выполнять запросы к слабоструктурированным данным, для запросов используется HiveQL и у Hive нет своего хранилища, но он имеет свой Hive Metastore для хранения метаданных о таблицах.

Как выглядит архитектура Hive, клиенты отправляют SQL запрос на выполнение, запрос принимает HiveServer2, который отвечает за взаимодействие с клиентами. После запрос парсится с помощью компилятора для проверок наличия такой таблицы в Hadoop, следующим этапом запрос передается оптимизатору, после оптимизации запроса результат оптимизатора передается на исполнение в виде MapReduce job. Помимо MapReduce Hive может выполняться поверх Apache Spark. К сожалению, Hive — это не про скорость выполнения запроса, а про всеядность обработки больших объемов данных с понятным для пользователей интерфейсом, так как запуск job в YARN с процессом его приоритизаций, выделения ресурсов не быстрое действие.

Источник: interviewbit.com

Apache Hive Beeline — это клиент Hive для запуска HiveQL запросов с помощью командной строки.

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

У Hive нет контроля над хранилищем HDFS и если случилось так, что в папку таблицы были записаны данные отличным от Hive инструментом, например, Apache Spark, то Hive не увидит эти изменения. Чтобы избавиться от несогласованности данных в этой таблице необходимо выполнить команду MSCK REPAIR TABLE. Благодаря этой команде Hive проанализирует таблицу и новые партиции станут доступны в Hive.

Форматы хранения данных в Hadoop

Основными форматами хранения в Hadoop являются:
— Parquet
— ORC
— Avro

Parquet и ORC — это колоночный формат хранения данных, а Avro является построчным форматом. Одним из плюсов перечисленных форматов в том, что в них записана схема, то есть указаны какие поля есть в таблице, какого они типа. Помимо этого плюсом колоночного формата хранения является то, что каждый столбец таблицы — это отдельный файл в HDFS, что позволяет гораздо быстрее считывать данные по сравнению с построчным хранением данных. В случае если нам нужна высокая скорость записи широких по столбцам таблиц, то необходимо присмотреться на строковый формат хранения Avro

Реляционные и нереляционные БД

Источник: bigdataschool

Реляционные БД

SQL подход — это семейство реляционных баз данных, основанное на отношениях (связях) таблиц друг с другом. Каждая таблица представлена в виде столбцов и строк. Столбец имеет свой предопределенный тип данных, в каждой ячейке значение. Строка хранит набор связанных значений, относящихся к объекту. Для определения уникальности строки существуют уникальный идентификатор (primary key). Строки из нескольких таблиц могут быть связаны посредством внешних ключей (foreign key).

Отличительные черты реляционной модели:
— подходит для решения большинства существующих задач
— запись и чтение структурированных данных
— данные связаны в виде логических отношений таблиц
— в таблицах есть строки и столбцы, где каждый атрибут имеет свой тип данных, а в ячейке свое значение
— есть уникальный ключ (primary key) для определения уникальности записи
— есть внешний ключ (foreign key) для отношения (связи) строк одной таблицы с строками другой таблицы
— необходима фиксированная схема (schema), где описана структура таблицы (наименование полей, тип полей и т. п.) наложенные на таблицу ограничения (constraints, checks, excludes)
— благодаря поддержки ACID свойств обеспечивается целостное хранение и согласованность данных, высокая отказоустойчивость и надежность
— поддержка языка SQL для манипуляций с данными

Недостатки реляционных БД:
— сложно горизонтально масштабироваться
— невозможно хранить данные с заранее неизвестной структурой
— менее эффективны в обработке больших объемов данных (террабайты, петабайты), чем нереляционные БД

Популярными представителями реляционных СУБД являются: Oracle, MySQL, MSSQL, Postgres

Нереляционные БД (NotOnlySQL)

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

Отличительные черты нереляционной модели:
— используются для решения узкоспециализированных задач
— запись и чтение неструктурированных данных
— гибкость, отсутствует фиксированное описание схемы из-за хранения данных без строгой структуры в виде документов, ключ-значений, графов и т. д.
— взамен ACID принципов используются BASE принципы, которые основаны на CAP теореме
— возможность горизонтального масштабирования путем добавления нового сервера в кластер
— поддержка шардирования
— высокая доступность и отказоустойчивость благодаря репликации данных
— обработка больших объемов неструктированных данных с низкой временной задержкой
— поддержка собственных SQL-подобных языков запросов, RESTful-интерфейсов, API и сложных типов данных

Недостатки нереляционных БД:
— отсутствие сильной целостности данных приводит к случаям чтения неактуальной информации, реплика не всегда может успеть обновиться актуальными данными
— сильная привязка к специфике внутреннего языка запросов конкретной СУБД, когда в реляционной БД есть SQL, который универсален для всех реляционных баз. Это приводит к сложности перехода от одной нереляционной БД к другой

Виды NoSQL БД:
Ключ-значение (key-value)

Источник: cloud.yandex.ru

В БД данного типа записи хранятся в парах ключ-значение, где ключ — уникальный идентификатор. Key-value БД используются для систем, где очень важна скорость и данные представлены не в сложном виде. Такие БД хорошо подходят например, для хранения кэша данных, пользовательских сессий, корзин в интернет магазине.

Популярными представителями являются: Redis (Remote Dictionary Server), DynamoDB, Memcached

Колоночные (column family store)

Стандартная строковая СУБД. Источник: clickhouse.com
Столбцовая СУБД. Источник: clickhouse.com

В колоночных БД данные каждой колонки хранятся отдельно независимо друг от друга (для каждого столбца создается свой файл). Такой принцип позволяет считывать с диска только данные тех столбцов что указаны в запросе — это ускоряет процесс чтения данных из больших таблиц, предназначенных для аналитических целей. Также преимуществом такого хранения является возможность сильно сжимать данные, что значительно экономит место на диске. Недостатком является выполнение операций над строками, у такого типа БД они более затратные.

Популярными представителями являются: Cassandra, Apache Hbase, ClickHouse

Документоориентированные (document-oriented store)

Схема документоориентированного БД. Источник practicum.yandex.ru

Данные в этом типе БД хранятся в виде документов в формате JSON, YAML, XML. Документы складываются в коллекции, а коллекции группируются логически тем самым создается иерархия. Преимуществом такой БД является гибкость, значения и структура документов может меняться в процессе разработки. Такие БД часто применяются для каталогов товаров в маркетплейсах, в соцсетях, платформ с блогами и видео, геоаналитики.

Популярными представителями являются: MongoDB, Amazon DynamoDB, CouchDB

Бонус

Классное и креативное объяснение NoSQL простым языком:

Традиционная БД против MPP БД

Предисловие

В данной статье разберу чем традиционные БД отличаются от MPP, в каких задачах достаточно иметь традиционную, а в каких MPP значительно лучше.

Симметричная многопроцессорная архитектура SMP

Традиционные СУБД как Oracle, Postgres, MySQL, MSSQL используются в симметричной многопроцессорной архитектуре (SMP).
SMP архитектура — это share-everything архитектура, где несколько процессоров сервера одинаковой производительности совместно используют оперативную память, что позволяет быстро обмениваться данными между процессами, жесткие диски для хранения данных. Каждый процессор может решать разные задачи причем делает это независимо друг от друга.

SMP архитектура

Преимущества SMP архитектуры относительно СУБД:
— Хорошо масштабируется по вертикали, добавляются дополнительные ресурсы сервера (CPU, RAM, HDD), тем самым повышая скорость отработки запросов
— Один сервер легче администрировать и обслуживать (управлять правами доступа, делать резервное копирование, накатывать обновления для СУБД и т. д.)
— Высокая производительность на небольших объемах данных, так как данные хранятся в одном месте не нужно передавать их по сети
— Равномерное распределение нагрузки на процессоры сервера
— Отлично подходит для обработки постоянного потока (real time) небольших транзакций характерных для OLTP систем
— Благодаря грамотному использованию индексов достигается высокая скорость чтения данных
— Отказоустойчивость, выход из строя одного процессора не заблокирует работу всего сервера

Недостатки:
— Совместное использование, конкуренция за ресурсы сервера пользователями СУБД
— В вертикальном масштабировании можно упереться в потолок, где добавление новых компонент (CPU, RAM) не будет давать прирост серверу в производительности
— Отсутствие горизонтального масштабирования
— Медленная обработка аналитических-OLAP запросов

Традиционные СУБД с SMP архитектурой хорошо показывают себя в
OLTP-системах, где важно обрабатывать постоянный поток (real-time) небольших по размеру транзакций с бОльшей долей операций вставки. Поэтому традиционные СУБД используются в микросервисах, веб-сайтах, CRM/ERP системах, в банках при обработке платежных транзакций.

Массивно-параллельная архитектура MPP

Массивно-параллельная архитектура — это зачастую shared-nothing архитектура, где каждому серверу выделены свои процессоры, своя оперативная память, а иногда и жесткие диски. Для общения и передачи данных между серверами все сервера подключены в одну сеть. Помимо этого в MPP СУБД встроена автоматическая разбивка данных по серверам под названием sharding. Если говорить грубо, то MPP — это несколько серверов, которые параллельно трудятся для решения одной задачи. К распространенным MPP СУБД можно отнести следующие продукты: ClickHouse, Greenplum, Vertica, Teradata.

MPP архитектура

Преимущества MPP архитектуры относительно СУБД:
— Легкая и доступная горизонтальная масштабируемость за счет добавления новых серверов в кластер
— Быстрая обработка аналитических-OLAP запросов за счет шардирования и партицирования
— Шардирование — разделение объектов базы данных на разные сегменты. Благодаря шардированию осуществляются распределенные вычисления. Шардирование в комплексе с shared-nothing концепцией дают хороший буст в производительности. Шардирование происходит благодаря дистрибуции данных по ключу, при правильном выборе ключа дистрибуции данные распределяются по сегментам равномерно, что играет ключевую роль
— Партицирование — разделение больших таблиц на секции, влечет за собой повышение производительности запросов путем снижения объема сканируемых данных, читаем только нужные секции. Также облегчает обслуживание таблиц, например, проще и эффективнее удалять, перемещать секции чем всю таблицу целиком
— Идеально подходит для корпоративных хранилищ данных
— Повышенная отказоустойчивость, отсутствует единая точка отказа. При выводе из строя одного из серверов кластера, работа СУБД не прерывается
— Возможность работать с несколькими источниками, например, разными OLTP системами, другими хранилищами или озерами данных

Недостатки:
— Высокие требования к сети, объединяющая сервера в один кластер. Сеть должна стабильно работать и иметь высокоскоростное соединение для передачи данных
— Низкая производительность для OLTP нагрузок с постоянным потоком транзакций
— Возможность возникновения перекоса данных на серверах кластера из-за неверно подобранного ключа дистрибуции, то есть в одном сегменте потребуется обработать значительно больше данных чем в других — это приведет к низкой производительности и нехватки памяти

В MPP СУБД фокус идет на аналитику больших данных (терабайты, петабайты), а значит предназначена решать задачи OLAP нагрузки, например, для построения корпоративного хранилища данных с обеспечением пользователей регулярными отчетами (МСФО, РСБУ), предиктивной аналитикой, подготовки данных с целью визуализации через BI инструменты.

История создания трека Inferno

06.11.2023 года в составе EP на британском лейбле JOOF Recordings вышел наш совместный трек с Enlusion Inferno. Сегодня расскажу вам историю его создания.

Обложка трека с Beatport

The Beauty of the Past

Изначально трек не планировалось издавать как совместную работу. В сентябре 2022 года я закончил свой новый трек под кодовым названием The Beauty of the Past, где был такой трансовый вайб с несколькими дорожками прогрессив бэйс лайна, с похожей лид партией из моих прошлых успешных работ, например, The Shockwave, аранжировку трека можно легко узнать с моего Terminate, да и что тут скрывать, хотелось написать трек в стиле крутого Slam Duck, вот наглядные примеры:

Моя версия в целом мне очень нравилась особенно своей атмосферой, прогрессией и сочетанием драмсов с басс линией. И вот я решил скинуть данный трек Enlusion и Daniel Lesden, чтобы узнать их мнение о треке, может уже пора релизить думал я, но рано было радоваться 😄

Вот так звучала первая версия Inferno The Beauty of the Past:

И вот первые впечатления от коллег:

Daniel Lesden: Мне какого-то лида не хватает, основной темы. Сейчас это по сути филер

Enlusion: Трек звучит приглушённо, все ключевые партии играют фоном вместо того, чтобы быть на переднем плане. Думаю, что он оживёт, если ты пересведёшь его. Мне по идеям нравится трек

Многочисленные правки с моей стороны не приводили в восторг никого.

Enlusion: Стало лучше. До ямы хорошо нагнетается напряжение, но после ямы ожидаешь усиления. Этого не происходит, трек просто начинается ещё раз и потом заканчивается, теперь нужно усилить напор после ямы, дать более мощный заряд

В конечном итоге произошло это:

Enlusion: Короче я готов закончить этот трек

Трансформация The Beauty of the Past в Inferno

У Кирилла (так зовут Enlusion) всегда в треках получались мастерские прогрессив бэйс лайны, поэтому первым же делом он решил заменить этот элемент, послушайте такую версию:

Сразу заметно, что трек сильно подрос в качестве, он стал более полным и звучать громче, Кирилл отлично постарался со сведением трека, но все же мне не нравилась добавленная им лид партия.

Daniel Lesden: Мне кажется тут бас-линия нужна более качающая. Мб тек-хаусовая? Кажется что трек пытается быть драйвовым пик-таймовым, а такой отрывистый короткий бас больше к прогу подходит

Кирилл решил поэксперементировать и вписать тек-хаусовый движок:

Была и такая версия, Кирилл любит потрудиться 😁

В это время я решил попробовать сделать свою техно версию трека, основываясь на изначальный The Beauty of the Past, Кириллу очень понравилась отсюда бочка, но в итоге пришли к мнению, что не стоит допиливать.

Кирилл не останавливается и продолжает потеть над треком, здесь он отказывается от тек-хаусового движка и решает добавить наикрутейший риз и мид-перк басс, зацените:

Daniel Lesden: Открытых хэтов очень не хватает в оффбит. Кажется в первую половину ещё какой-то музыкальный элемент нужен. Может стаб или что-то такое простое, буквально пару нот. Эсид(?) лид в кульминации лишний. Он там ещё и прячется как-то странно как енот-воришка, будто боится выйти из тени. Ни туда, ни сюда

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

Итого

Создание треков — это длительный, кропотливый труд, который, к сожалению, мало кто замечает, так как все оценивают финальный результат и даже не догадываются что было за кулисами. Часто бывает так, что твой трек не удостаивается должного внимания среди куча другого музыкального контента и это очень обидно, ведь ты и твой напарник могут вкладывать десятки часов, чтобы добиться офигенного результата. Давайте в данном случае поддержим в первую очередь Кирилла он проделал титаническую работу и превратил трек в настоящий бэнгер 🔥 Под поддержкой я подразумеваю, чтобы вы послушали трек на любых из стриминговых платформ, поделились треком/моей статьей в соц сетях, чтобы трек услышали как можно больше людей, написали комментарий здесь, в личке о своих впечатлениях. Поддерживайте музыкантов прослушиваниями, вниманием, ведь это драйверы продолжать творить!

SoundCloud

YouTube

В скором времени здесь появятся ссылки на остальные стриминговые платформы. Как говорится stay tuned!

kolesa conf’23

Источник оригинала фото: Kolesa Group

07.10.2023 в Алмате состоялась ежегодная конференция Kolesa Conf’23. Kolesa Conf’23 — это масштабная конференция, объединяющая IT-сообщество Казахстана.

О Kolesa Group

Источник: Kolesa Group

Kolesa Group — казахстанская IT-компания, которая специализируется на создании сервисов по размещению частных и бизнес объявлений в сфере авто, недвижимости, товаров и услуг в Казахстане и Узбекистане.

Главными продуктами компании являются мобильное приложение kolesa.kz — торговая площадка для автомобилистов, сайт krisha.kz — размещение объявлений о недвижимости, market.kz — сайт бесплатных объявлений общей тематики. Продуктами компании ежемесячно пользуются 15 миллионов пользователей.

Компания была основана в 1996 году. Вначале своего пути компания занималась выпуском газетного издания «Колёса», где можно было разместить объявление о продаже своего авто с фотографиями и  техническими характеристиками.

Место проведения

Кинотеатр «Арман» на проспекте Достык. Источники: sovietarch.strelka, kino.kz, Kolesa Group

Кинотеатр «Арман» открылся для посетителей в 1968 году, здание было спроектировано в лучших традициях эпохи совесткого модернизма с барельефом на боковых фасадах, отражающий путь Казахстана. Внутри вас встречает закусочная и пространство для проведения развлекательных мероприятий. Сейчас кинотеатр насчитывает 4 кинозала два на первом этаже и два на втором.

Направления конференции

Количество направлений полностью совпадает с количеством залов кинотеатра «Арман».
WEB про Backend, Frontend, Security и QA
MANAGEMENT про запуск продукта, управление командой, изменение и управление процессами
MOBILE про iOS, Android разработку, QA, Security
DATA про ML, Product Analytics, Data Engineering

Больше всего докладов удалось послушать именно на направлении DATA. В качестве бонуса порекомендую по докладу с направления MANAGEMENT и MOBILE.

Многоступенчатое тестирование и зоопарк моделей в ClearML

Спикер: Андрей Шадриков, R&D Team Lead, Verigram
О докладе: Зачем делать много разных тестов ML-моделей и изменять их со временем? Этот подход помогает проверять модели на скрытые байесы, но добавляет проблемы в отслеживании зоопарка моделей. Как в Verigram решают проблему с отслеживанием зоопарка моделей, используя ClearML, как в связке с отчётами и GitLab снижается трение между командой разработки и бизнеса.
Основные тезисы доклада:
— В данных может быть много bias по разным причинам
— В ClearML можно разбивать тесты через параметры, можно искать по тегам, навешивать теги на модели, сохранять uncommited changes вместе с экспериментом
— ClearML проще расскатывается, чем MLFlow
— Если у вас уже готовая, настроенная инфраструктура, то переходить на ClearML не стоит
— ClearML — большой комбайн, может потреблять значительное кол-во ваших ресурсов

Эволюция подходов к персонализации в Авто.ру

Спикер: Вадим Кохтев, Руководитель ML-направления, Яндекс Вертикаль
О докладе: Путь Авто.ру в персональных рекомендациях, почему полезно строить платформенные решения и откуда у пользователя появилась особая роль
Основные тезисы доклада:
— Изначально на Авто.ру был атрибутивный поиск без рекомендаций и персонализации
— Решили внедрить бесконечную ленту как в VK, Instagram вместо главной страницы для повышения retention
— В рекомендациях начали показывать объявления из истории просмотренных, рекомендацию похожих
— Замешивание контента с помощью постов пользователей, статей про авто
— Персонализация с помощью определения намерений, что пользователь хочет делать на сервисе. В результате чего у посетителя появляется набор предсказаний и роль

Повышение качества данных с использованием Zero Bug Policy

Спикер: Олег Харатов, Technical unit lead, Авито
О докладе: Как системный подход по работе с проблемными данными помог в борьбе с ошибками в хранилище данных, какие метрики использовали для оценки этого подхода и как договаривались с владельцами данных
Основные тезисы доклада:
— В Avito Anchor modeling (6НФ), поэтому в детальном слое на проде крутятся несколько 10 тысяч таблиц
— Кол-во витрин растет очень быстро, а число ошибок растет еще быстрее
— Важно разделять витрины на несколько уровней важности: критичные, важные, стандартные, неважные
— Zero Bug Policy — это про то, что не стремишься решить все баги на проде, а лишь самые важные. Подход отвечает на вопросы какие, когда и кто
— Создали матрицу приоритетов в разрезе типа бага, важности витрин с SLA на исправление
— К большему числу багов необходимо подходить системно, трекать как быстро решаются проблемы с данными и оценивать метриками

Как правильно развивать продукт через исследования, поиск проблем и точек роста. Discovery в Kolesa Group

Спикер: Дмитрий Казаков, Директор по аналитике, Kolesa Group
О докладе: Как в Kolesa перешли к discovery-процессам, через какие сложности прошли и какие проблемы Discovery помогает решать. Доклад будет полезен командам, которые хотят поставить на поток поиск и внедрение фичей в продуктовых командах и которые сталкивались с неэффективностью в этих процессах.
Основные тезисы доклада:
— Discovery — поиск и работа с проблемами и точками роста
— Discovery нужно внедрять когда нехватка идей в продукте, есть искажения в принятии решений, есть фокус на project management, а не product management
— Double Diamond — основа Discovery в Kolesa. Спрашивайте у дизайнеров как строить продукт, они лучше понимают пользователей
— Команда Discovery состоит из Product Owner, аналитиков, дизайнеров, core команды сервиса, техлиды
— Систематизируйте хранение информации вокруг Discovery
— Инструменты Discovery должны быть такими, чтобы человеку со стороны было легко разобрать смысл написанного
— Выросло на 40% кол-во исследований и проверок идей в команде после внедрения Discovery
— Рост вовлеченности команды в продукт
— Начали работать от проблемы, а не от решений

Философия архитектуры

Спикер: Алексей Емелин, Руководитель группы разработки на Android, Yandex
О докладе: Основные трудозатраты программиста — это обдумывание кода, своего и чужого. А можно ли снизить эти трудозатраты? Как устроен процесс мышления? Есть ли методологии, помогающие лучше понять код? Поможет ли знание Канта и Гегеля глубже осознать логику MV* архитектуры и предположить, что будет после MVI? На эти и многие другие философские вопросы об архитектуре ПО Алексей постарался ответить в своем выступлении
Основные тезисы доклада:
— Цель архитектуры — уменьшить человеческие трудозатраты
— Понимание того как мы мыслим может приблизить к цели архитектуры
— Философия — наука о мышлении, дает методологию постижения истины
— Принцип историзма — при рассмотрении чего либо в окружающем мире нужно учитывать нормы того времени, то есть что было принято тогда, какие технологии были в то время, на какой стадии развития они находились
— «Все течет, все меняется», то есть все есть процесс. В процессе нет границ
— Противоречие или парадокс — двигатель прогресса по философии
— Рассматривая явления в движении в развитии, появляется возможность выявлять тенденции к изменениям и причина изменений строится в какой-то проблеме

Остальные активности и плюшки

При входе на конференцию нам раздавали welcome паки, где подарили следующие ништяки:

На втором этаже расположилась развлекательная часть конференции, было 7-8 стендов от самих Kolesa и их партнеров, где можно было побатлиться в игре по определению ЯП, пройти виртуальный квест, постоять на баланс-борде, поугадывать мемы на карте мемасов, выиграть призы, правильно ответив на IT-вопрос разной категории сложности и многое другое.

Источник: Kolesa Group

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

Источник: Kolesa Group

Полезные ссылки

Фото галерея конференции: Kolesa Group
Записи выступлений с направления DATA
Записи выступлений с направления MANAGEMENT
Записи выступлений с направления MOBILE
Записи выступлений с направления WEB

В качестве бонуса видеообзор конференции от команды Kolesa:

Python for Data Analysis Course

На днях презентовал внутри своей компании тренажер/курс по Python для анализа данных. Если вы когда-нибудь хотели начать программировать на Python или вам надоел Excel, и вы хотите попробовать что-то поинтереснее для аналитики или визуализации, то рекомендую начать с данного тренажера.

QR-Code на Github репо с тренажером

Для кого данный тренажер?

Тренажер отлично подойдет для:
— бизнес-экспертов, работающих с табличными данными
— дата-аналитиков
— людей, кто никогда не программировал на Python

Формат обучения

— Онлайн
— В своем темпе без каких-либо дедлайнов
— В среднем тренажер займет от 2 до 4 недель

Что нужно для тренажера?

— Доступ в Интернет
— Браузер Google Chrome (рекомендация)
— Аккаунт Google

Содержание тренажера

Тренажер состоит из 3-ех больших блоков, написанных на Jupyter Notebook:

  1. Введение в Python
  2. Основы Numpy и Pandas
  3. Визуализация данных

После прохождения тренажера вы будете уметь:

— Писать и читать простые программы на Python
— Загружать excel, csv в Jupyter, манипулировать данными с помощью библиотек pandas, numpy
— Визуализировать данные с помощью библиотек matplotlib и seaborn
— Сможете использовать Jupyter Notebook в своей повседневной работе

Обратная связь и помощь

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

О себе

My photo

Привет! 👋 Меня зовут Влад и я Data Engineer. Мне нравится делиться знаниями, структурировать информацию и подавать ее в более понятном виде. В свободное от работы время пишу электронную музыку в стилях техно и прогрессив под псевдонимом Slavlotski. Помимо этого я заядлый геймер и люблю поигрывать в «AAA» тайтлы на PS и PC.

Здесь веду блог, где пишу обучающие статьи по Data Engineering и смежным ему направлениям, также в блоге можно почитать про рейвы, музыкальный продакшн и около музыкальные темы.

Bardak x SHU[LAMA] 08.04.2023

Предисловие

Вот уже как три года как я не посещал техно-рейвы, последний был OTC (Open To Close) от Daniel Lesden в Москве и с переездом в Алматы здешние артисты не вызывали желание куда-нибудь выбраться порейвить, но тут вдруг пишет мне хороший знакомый следующее:

bokeh: Офигеть) В Алмате привоз Yanamaste

Первая реакция была такая, а кто такой Yanamaste? Погуглил, послушал что играет данный диджей, если честно не очень понравилось, но решил все же дать шанс и приобрел билет. И как вы уже поняли сегодня я расскажу вам о своих впечатлениях от данного мероприятия.

Instagram @shulama.event

Клуб Bardak spot

Интересный факт, что клуб Bardak spot, где проводился рейв, находится в одном из помещении музея вооруженных сил Республики Казахстан, для камерных техно-рейвов самое то, вместительность я думаю там человек на 100-150 максимум.

Военно-исторический музей вооруженных сил РК

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

На входе встречает как и полагается фейсконтроль, после тебя встречает девушка и ищет тебя по спискам тех кто купил билет. Важно еще отметить особенность, в Казахстане всяким ИПшкам (и не только) можно переводить деньги напрямую по номеру телефона через местный Kaspi Bank, то есть в данном случае не нужно было покупать билет через какого-нибудь посредника в виде билетного оператора, распечатывать билет или сохранять его электронно, все напрямую. Получилось так, что в списках меня не оказалось, благо у организатора схема приобретения билета/прохода предусмотревала, что после того как сделаешь перевод нужно отправить скриншот перевода в чат с организатором, так они и вносили всех в список, и вот спустя пары минут общения с девушкой я прошел и очутился внутри клуба.

Оказавшись внутри сразу же отметил для себя, что звук слабоват, у выхода с танцпола низкие частоты ощущались слабо, но в целом звук казался чистым, перегрузов не было. Танцпол представлял из себя такой вытянутый туннель, чем-то напомнил «Printworks» на минималках 😁

Знаменитный клуб Printworks в UK

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

Диджеи и музыка

Приехал я не к самому началу, а где-то за два часа до выступления хэдлайнера, на тот момент в диджейке стоял Cotton Pills.

Cotton Pills и его breaks 1

Весь сет Cotton Pills играл странный breaks, под который даже потанцевать не получалось.

Cotton Pills и его breaks 2

Спустя час сменил его уже другой диджей под псевдонимом NIKITA и тут уже пошла привычная техно бочка.

NIKITA INTRO
NIKITA 2
NIKITA 3

Близится 01:00 по Алмате и за диджейку встает хэдлайнер Yanamaste. К этому моменту я уже все ближе и ближе подхожу к сцене.....

Yanamaste 1

И людей стало прям впритык, начинаешь проникаться вайбом.

Yanamaste 2
Yanamaste 3

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

Yanamaste 4

Ближе к второму часу Yanamaste разогнался и пошло мясилово

Yanamaste 5
Yanamaste 6

Танцпол под конец его сета выглядил как-то так

Yanamaste 7

Yanamaste по сравнению с двумя предыдущими диджеями отличался профессиональным сведением и подборкой качественного материала, не зря все же его звали в Boiler Room

Как закончил играть Yanamaste я решил не оставаться и поехал домой, надеюсь оставшиеся два диджея не сильно расстроились :)

Тестирование беруш

Беруши те что справа

Летом 2022 года я приобрел себе специальные беруши для таких вот техно-рейвов, музыкальных концертов, но как вы могли прочитать выше звук на прошедшем мероприятии был не настолько громким, чтобы протестировать их пополной, в целом звук практически не искажается, разве что фильтром значительно приглушены очень вредные для ушей высокие частоты, но хэты, райды, перкусия все равно отчетлива читается в треках, что очень радует. Одним словом я бы рекомендовал вам их приобрести у компании 44 Sound, если вы в Москве, единственное каким вопросом я сейчас задаюсь — это удобно ли будет ими пользоваться, если сводить в них треки, кажется что будет не очень комфортно.

Итого

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

Unboxing Ableton Push 2

Всем привет! Сегодня хотелось бы вам рассказать про мой опыт покупки Ableton Push 2 на официальном сайте Ableton и доставку его из Германии в Казахстан, а также провести его unboxing.

Поиск и покупка Ableton Push

И так начнем. Сначала хотел купить Ableton Push где-нибудь в самом Казахстане, России, но в Казахстане абсолютно не было предложений либо я плохо искал, в России были версии только в комплекте с Ableton Live Suite 11, но так как Ableton Live я купил еще на черной пятнице в ноябре 2022 года, то такие предложения меня не устраивали. Единственным вариантом понял, что лучше будет заказать его на самом Ableton.

Invoice покупки

И да, зарегистрировавшись в Ableton, и применив код активации Ableton Live Suite 11, тебе сразу предлагают приобрести Ableton Push 2 со скидкой в размере 20%, что очень приятно, так без скидки Ableton Push 2 стоит 799 долларов. Помимо этого решил, что хочется его получить до наступления нового года, была доступна опция экспресс доставки за 60 долларов, и я был очень удивлен как его быстро доставили, учитывая, что покупка была осуществлена 21.12.2022 прям накануне католического рождества и зная как европейцы «работаю» в праздничные и выходные дни..... Но о процессе доставки поговорим далее.

Уведомление о покупке

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

Уведомление об успешности покупки

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

Информации о трекинге моего Ableton Push

К сожалению, какого-то письма о том покинул склад Германии мой Ableton Push, не покинул, ID для трекинга заказа я не получил, не знаю почему так, может рождественская суета и мне его забыли направить, но зато я нашел FAQ о доставке, где прописаны сроки получения заказа.

Среднее время доставки в зависимости от точки назначения

Факт, что обычная доставка для всего остального мира занимает от 2 недель и более, меня разочаровал, но были надежды, что экспресс доставка и рождественские чудеса сработают :)

Доставка и получение Ableton Push

И о чудо, 26.12.2022 мне позвонила девушка с компании UPS, которая сообщила, что мой Ableton Push 2 уже на таможне Казахстана, она мне направила письмо о том какие документы нужно предоставить для растаможки и сколько будет это стоить. Из документов необходимо было предоставить скан загран паспорта РФ, так как я все еще не резидент РК , ИИН (аналог российского ИНН) и заключить договор об оказании услуг доставки и растаможки. Стоимость их услуг составляла 3500 тенге, это около 500 рублей.

Личная информация для заключения договора с UPS

Помимо этого мне прислали ID номер для трекинга моего заказа и где можно отслеживать статус.

Прогресс доставки от начала до конца

После того как я заполнил анкету и прислал все сканы (классно, что все сканы я храню на Dropbox), девушка сообщила что в течение 2 рабочих дней заказ будет направлен из таможни в Алматы, где сейчас я и проживаю. Как можно заметить по скриншоту прогресса доставки уже 28.12.2022 ко мне приехал фургончик UPS, где лежал мой Ableton Push, я спокойно расплатился и радостно понес его домой :)

Unboxing Ableton Push 2

К сожалению, эта история не полностью состоит из одних чудес и радостей, после того как я принес запакованную коробку с моим Ableton Push, я обнаружил что коробка очень сырая, начал ее вскрывать и увидел, что она полностью промокла и, видимо, лежала под дождем продолжительное время, вы бы знали как я офигел, думал пиши пропало, мой Ableton Push утопили :(

Как выглядит коробка после того как она высохла

К счастью, заказ был упакован в еще одну коробку, которая приняла бОльший удар на себя, но все же капельки воды на полиэтилене, где лежал сам Ableton Push, я обнаружил, пошел быстро проверять, что он работает и что все хорошо. Все обошлось и пока тьфу-тьфу он работает штатно, конечно огромнейший дизлайк компании UPS, не знаю даже на каком этапе промокла вся посылка, видимо пока лежала на таможне или пока транспортировалась в Алматы, но такое отношение к товару — это ужас. Думаю, что стоит оставить негативный фидбэк компании, а то так дело совсем не пойдет. Но давайте перейдем к самому вкусному :)

Значит начнем мой unboxing и посмотрим еще на промокшую коробку от Ableton Push.

Промокшая коробка вид сбоку
И еще фото

Открыв коробку следующий удар на себя взял пенопласт со специальным дизайном от Ableton. Вот как он выглядит:

Серый пенопласт с логотипом Push

Открываем пенопласт и обнаруживаем там следующее, сам Ableton Push 2, который я уже вытащил (покажу позже), мануал использования Ableton Push, буклет с кодом активации, разные разъемы для розеток под каждый регион, блок питания.

Все содержимое коробки от Ableton Push

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

Без буклетов и всяких бумажек

В самом буклете еще положили наклейки с лого Ableton, лайк :)

Бумажки, наклейки, инструкции

Ниже все разъемы розеток, блок питания и, к моему удивлению, USB подключение Ableton Push к своему ноутбуку или PC, учитывая, что я чаще всего встречал, что Ableton Push большинство используют в связке с MacBook, могли второй провод с Type-C тоже положить.

Все остальное нужное добро

Ну и сам виновник всего торжества, Ableton Push 2 в полиэтилене, чехла никакого, к сожалению, нет, приходится его хранить в таком же виде.

Ableton Push 2 в полиэтилене
Ableton Push без полиэтилена.
Вид сбоку

Наверно, вам не терпится увидеть как он выглядит включенным, вот:

Ableton Push 2 в действии
Ableton Push 2 при наигрывании drum секции

На самом деле Ableton Push 2 достаточно тяжелый и чувствуется, что сделан из качественного материала, его приятно трогать, pad отзывчиво реагируют на нажатие, крутить cutoff используя ручки тоже приятно :D

Первые впечатления использования только положительные, очень круто что сами Ableton подготовили подробные tutorial по тому как освоить Ableton Push 2 в написании музыки и не только, но об этом как нибудь потом, могу только сказать, что это совсем иной workflow и mindset в написании треков.

Думаю, что в дальнейшем как освою инструмент напишу еще статейку чем крут Ableton Push 2 в использовании и возможно уже сможете заценить как изменится мой music production, а так напоследок оставлю вам мой текущий setup, скоро добавятся к нему мои Beyerdynamic DT 900 PRO X, которые уже третью неделю летят с Москвы. До скорых встреч :)

Мой текущий setup