[Инструменты Data Lake]

Привет, друзья! Ранее мы обсудили, что такое Data Lake и почему он так популярен. Сегодня расскажу о том, какие инструменты мы используем для управления нашим Data Lake и как они помогают нам справляться с повседневными задачами.

Основные инструменты для управления Data Lake:

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

Apache Spark:
Spark — это мощный инструмент для обработки больших данных в режиме реального времени. Он поддерживает разнообразные аналитические задачи, включая машинное обучение, обработку потоков данных и SQL-запросы. Благодаря своей скорости и гибкости Spark стал незаменимым инструментом для анализа данных в Data Lake.

Apache NiFi:
NiFi — это мощный инструмент для автоматизации потоков данных. Он позволяет легко собирать, передавать и преобразовывать данные из различных источников в режиме реального времени. Мы используем NiFi для интеграции и управления потоками данных.

Apache Hive:
Hive — это инструмент для выполнения SQL-запросов на больших объемах данных, хранящихся в Hadoop. Он предоставляет интерфейс, похожий на SQL, что облегчает работу с данными для аналитиков и разработчиков. Hive позволяет выполнять сложные аналитические задачи и преобразования данных.

Trino (ранее PrestoSQL):
Trino — это распределенный SQL-движок, который позволяет выполнять высокопроизводительные аналитические запросы на больших объемах данных. Он поддерживает работу с различными источниками данных, включая Hadoop и S3. Trino обеспечивает быструю и эффективную обработку данных, что делает его незаменимым инструментом для нашего Data Lake.

Apache Airflow:
Airflow — это платформа для автоматизации и оркестрации рабочих процессов. Мы используем Airflow для планирования и мониторинга задач импорта/экспорта и обработки данных, что позволяет нам эффективно управлять интеграциями.

———
Далее я подробнее расскажу об экосистеме для работы с большими данными Hadoop. Оставайтесь на связи!

#BigData #DataLake #ApacheHadoop #ApacheSpark #ApacheNiFi #Hive #Trino #ApacheAirflow #IT

Всем доброго утра и хорошей продуктивной недели!💪💪💪

[Что такое Hadoop и из каких компонентов он состоит?]

Привет, друзья! В предыдущих постах мы обсудили Data Lake и инструменты для его управления. Сегодня хочу рассказать о Hadoop — одной из ключевых технологий, на которой базируется большинство современных решений для работы с большими данными.

Что такое Hadoop?
Hadoop — это масштабируемая и отказоустойчивая платформа с открытым исходным кодом для хранения и обработки больших объёмов данных. Она позволяет распределять данные и задачи обработки между множеством узлов в кластере, что делает её идеальным решением для работы с данными в промышленном масштабе.

Основные компоненты Hadoop:

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

MapReduce:
MapReduce — это модель программирования, которая позволяет обрабатывать большие объёмы данных параллельно на кластере. В MapReduce задачи делятся на две основные фазы:

Map-фаза: Обработка данных и их преобразование в пары ключ-значение.
Reduce-фаза: Сводка результатов и получение итогового ответа. MapReduce позволяет эффективно анализировать данные, распределённые по множеству узлов.

YARN (Yet Another Resource Negotiator):
YARN — это система управления ресурсами в Hadoop. Она позволяет разным приложениям и фреймворкам использовать ресурсы кластера (процессорное время, память и др.).

Основные компоненты YARN:
Resource Manager: Управляет ресурсами кластера.
Node Manager: Контролирует ресурсы на каждом узле кластера.
Application Master: Обрабатывает задачи конкретного приложения.

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

———
В следующем посте я расскажу о других проектах Apache, связанных с Hadoop.

#BigData #Hadoop #HDFS #MapReduce #YARN #IT

[Алгоритм Питерсона*: Обеспечение взаимного исключения в многопоточности]

Привет, друзья! Помните пост "Важность контроля доступа к разделяемым объектам", где была продемонстрирована проблема при работе с параллельными потоками? Сегодня расскажу об интересном алгоритме для обеспечения взаимного исключения — алгоритме Питерсона. Это простое, но важное решение, которое позволяет двум потокам безопасно разделять ресурсы.

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

Как это работает?
Алгоритм Питерсона позволяет двум потокам координировать доступ к общим ресурсам. В нашем примере используется класс PetersonLock, который реализует этот алгоритм. Два потока (производитель и потребитель) используют блокировки для безопасной записи и чтения данных из общего буфера.

class PetersonLock:
    def __init__(self):
        self.flag: List[bool, bool] = [False, False]
        self.favored_thread: int = 0

    def lock(self, thread_id):
        other_thread = 1 - thread_id
        self.flag[thread_id] = True
        self.favored_thread = thread_id

        while self.flag[other_thread] and self.favored_thread == thread_id:
            pass

    def unlock(self, thread_id):
        self.flag[thread_id] = False

В этом коде два потока устанавливают свои флаги и координируют доступ к ресурсу через переменную favored_thread, обеспечивая таким образом взаимное исключение.

Зачем это нужно?
Хотя алгоритм Питерсона редко используется на практике в современных системах, он остаётся важным учебным примером, который помогает понять основные концепции синхронизации и взаимного исключения. Его простота делает его отличным инструментом для изучения основ многопоточного программирования.

Кто такой Питерсон?

Гарри Питерсон — американский учёный, который внёс значительный вклад в области информатики, особенно в разработку методов синхронизации и управления параллельными процессами. Его алгоритм стал основой для многих учебных курсов и учебников по операционным системам.

———
Далее я покажу другой алгоритм взаимного исключения для N-потоков - алгоритм Лэмпорта.

*В других русскоязычных источниках фамилию пишут через "е" - Петерсон.

Полный пример кода по ссылке: https://github.com/avagners/algorithms_and_data_structures/blob/main/algorithms/asynchronous_concurrent_execution/peterson_lock/peterson_lock_2.py

#Python #Concurrency #PetersonsAlgorithm #Многопоточность #Синхронизация #IT

[Москва. IT-фестиваль.]

Всем привет. Я в Москве.

Вчера был на внутрибанковском IT-фестивале. Для меня это первое такое мероприятие.
Было очень-очень круто. Отдохнул всей душой.

Онлайн никогда не заменит живое общение.

Был очень рад всех видеть.

Сейчас в парке Зарядье на II Фестивале юношеских оркестров мира.

[Другие проекты Apache, связанные с Hadoop]

Hadoop не существует в одиночку. Он окружён целым рядом проектов Apache, которые расширяют его возможности и предоставляют дополнительные инструменты для работы с большими данными.

Apache Hive:
Hive — это инструмент для выполнения SQL-запросов на данных, хранящихся в Hadoop. Он был разработан для того, чтобы аналитики и разработчики могли использовать привычный им язык SQL для работы с большими объёмами данных, хранящихся в HDFS. Hive отлично подходит для анализа структурированных данных и выполнения сложных запросов.

Apache HBase:
HBase — это распределённая, масштабируемая база данных NoSQL, которая работает поверх HDFS. Она предназначена для работы с большими объёмами данных в режиме реального времени и поддерживает как чтение, так и запись данных. HBase используется для хранения данных, требующих быстрой записи и доступа.

Apache Ambari:
Ambari — это инструмент для управления и мониторинга кластеров Hadoop. Он предоставляет простой и удобный веб-интерфейс для установки, настройки и управления кластерами Hadoop. С помощью Ambari можно отслеживать производительность системы, управлять конфигурациями и автоматизировать задачи администрирования.

Apache Tez:
Tez — это фреймворк, который оптимизирует выполнение заданий в Hadoop. Он был разработан как замена для MapReduce и позволяет выполнять сложные цепочки задач более эффективно и с меньшими задержками. Tez поддерживает выполнение DAG (Directed Acyclic Graph) задач, что делает его более гибким и производительным для различных аналитических приложений.

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

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

Apache Sqoop:
Sqoop — это инструмент для передачи данных между Hadoop и реляционными базами данных. Он позволяет импортировать и экспортировать данные между HDFS и базами данных, такими как MySQL, PostgreSQL и другие.

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

#BigData #Hadoop #HDFS #MapReduce #YARN #Hive #HBase #Ambari #Tez #Spark #ZooKeeper #Sqoop #IT

Начинаю знакомство с Java)

Мои итоги 2024 года 🎄🌲

Если прошлый год был годом открытий, то этот год - годом потрясений.
Тоже своего рода год открытий. Просто с другим оттенком).

———
Всех с праздниками! 🍾🥂

https://telegra.ph/Itogi-2024-goda-12-31-7

Завершил чтение книги Аниче Маурисио "Простое объектно-ориентированное проектирование: чистый и гибкий код." — СПб.: Питер, 2025. — 224 с.

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

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

Книгу легко читать. Рекомендую.

———
#coder #coding #programmer #stepbystep #шагзашагом #учусьпрограммировать #учусь #book

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

= "От математики к обобщенному программированию" Александр А. Степанов, Дэниэл Э. Роуз (2015)

OSI (The Open Systems Interconnection model)

Сетевая модель OSI (The Open Systems Interconnection model) — сетевая модель стека (магазина) сетевых протоколов OSI/ISO. Посредством данной модели различные сетевые устройства могут взаимодействовать друг с другом. Модель определяет различные уровни взаимодействия систем. Каждый уровень выполняет определённые функции при таком взаимодействии.

OSI состоит из двух основных частей:
- абстрактная модель сетевого взаимодействия (семиуровневая модель);
- набор специализированных протоколов взаимодействия;

Концепция семиуровневой модели была описана в работе Чарльза Бахмана. Данная модель подразделяет коммуникационную систему на уровни абстракции (англ. "abstraction layers"). В модели OSI средства взаимодействия делятся на семь уровней: прикладной, представления, сеансовый, транспортный, сетевой, канальный и физический.

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

[Тренажерный зал]

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

Последние пол года посещаю зал практически ежедневно. Вечером, после работы.

Первые пол года ходил с тренером. Учился. Последние 7 месяцев хожу сам.

Хожу в зал просто так. Без каких-либо глобальных целей.
Сначала стремился толкнуть 100 кг в жиме лежа. Сейчас спокойно подхожу к штанге 110 кг. Для моих физических данных (рост - 190см, вес - 83кг, возраст - 32 года) считаю довольно достойным результатом.

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

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

Благодаря залу стал лучше прислушиваться к организму. Стал лучше спать.
В зале организм сразу дает понять, если ты что-то сделал неправильно накануне. 

___
Как у вас обстоят дела со спортом? Делитесь своими результатами/достижениями?

[Знакомство с DDD]

Начал проходить обучение по DDD (Domain Driven Design).
Крайне интересная тема.

Ниже прикладываю ссылку на статью как можно реализовать Value Object в Python.

https://dddinpython.hashnode.dev/value-objects-in-python

[Entity и Value Object в DDD]

Привет! В DDD сразу встречаешь два ключевых понятия — Entity и Value Object. Оба вроде как про данные, но ведут себя по-разному.

Что такое `Entity`?
Entity — это объект, который имеет уникальный идентификатор и жизненный цикл. Его идентичность важна, и она сохраняется на протяжении всего времени существования объекта. Например, пользователь в системе (User) — это Entity, потому что у него есть уникальный ID, и даже если его имя или email изменятся, это все равно будет тот же самый пользователь.

from dataclasses import dataclass, field
import uuid

@dataclass
class User:
    name: str
    email: str
    id: uuid.UUID = field(default_factory=uuid.uuid4, init=False)

    def __eq__(self, other):
        if isinstance(other, User):
            return self.id == other.id
        return False

# Пример использования:
user1 = User("Иван", "ivan@example.com")
user2 = User("Иван", "ivan@example.com")

print(user1)  # User(name='Иван', email='ivan@example.com', id=...)
print(user2)  # User(name='Иван', email='ivan@example.com', id=...)
print(user1 == user2)  # False, потому что ID разные

Что такое `Value Object`?
Value Object, в отличие от Entity, не имеет идентичности. Он определяется своими атрибутами, и если все атрибуты одинаковы, то два Value Object считаются равными. Value Object обычно неизменяемы (immutable), что делает их более предсказуемыми и безопасными в использовании.

from dataclasses import dataclass
import re

@dataclass(frozen=True)
class EmailAddress:
    value: str

    def __post_init__(self):
        if not self._is_valid_email(self.value):
            raise ValueError(f"Некорректный email: {self.value}")

    @staticmethod
    def _is_valid_email(email: str) -> bool:
        pattern = r"^[\w\.-]+@[\w\.-]+\.\w+$"
        return re.match(pattern, email) is not None

# Пример использования:
try:
    email1 = EmailAddress("valid.email@example.com")
    print(email1)  # EmailAddress(value='valid.email@example.com')

    email2 = EmailAddress("invalid-email")  # Ошибка валидации!
except ValueError as e:
    print(e)

Когда что использовать?
- Если объект уникален сам по себе — это Entity.
- Если важны только его значения — это Value Object.

Фишка DDD:
Хорошая практика — делать Value Objects иммутабельными и использовать их для инкапсуляции логики. Например, не просто string для email, а EmailAddress, который сразу валидирует значение.

Entity и Value Object — это мощные концепции, которые помогают структурировать код и делать его более предсказуемым. В Python их реализация может быть элегантной с использованием dataclasses.

#DDD #Python #Entity #ValueObject #Программирование

[Агрегаты в DDD: Организация сложности через границы]

В Domain-Driven Design (DDD) работа с сложными доменными моделями требует четкой структуры, чтобы избежать хаоса.
Агрегат (Aggregate) — один из ключевых паттернов DDD, который помогает управлять целостностью данных и упрощает взаимодействие с моделью.

Что такое Aggregate?

Агрегат — это кластер связанных объектов, рассматриваемых как единое целое.

Он объединяет:
1) Корень агрегата (Aggregate Root) — единственная точка входа для внешних взаимодействий.

2) Внутренние сущности (Entity) и value-объекты (ValueObject) — элементы, которые могут изменяться только через корень.

По своей сути агрегат - это тоже Entity.

Зачем нужны агрегаты?

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

- Границы транзакций
Изменения в рамках одного агрегата обычно выполняются в одной транзакции. Это упрощает управление конкурентным доступом.

- Сокрытие сложности
Внешние системы не знают о внутренней структуре агрегата — они работают только с корнем.

Ключевые принципы проектирования:

- Единый корень
Все внешние запросы идут через корень. Если нужно изменить дочерний объект — делайте это через методы корня.

- Инварианты внутри границ
Правила целостности (например, «максимум 10 товаров в заказе») должны соблюдаться внутри агрегата.

- Ссылки только на корни других агрегатов
Агрегаты не должны хранить ссылки на внутренние объекты чужих агрегатов — только на их корни (через идентификаторы).

Пример:
Агрегат Заказ (корень) включает элементы заказа (OrderItem), адрес доставки и методы для добавления/удаления товаров. Внешние системы обращаются только к Order, а не к OrderItem напрямую.

Ошибки при работе с агрегатами:

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

- Нарушение инкапсуляции
Прямое изменение дочерних объектов в обход корня ломает целостность.
Решение: Скрывайте внутренние структуры (private поля, методы только для корня).

Как определить границы агрегата?
- Ищите транзакционные границы — что должно изменяться атомарно?
- Анализируйте бизнес-инварианты — какие правила связывают объекты?
- Избегайте «анаемичных» агрегатов — они должны содержать логику, а не быть просто набором данных.

———
Итого

Агрегаты в DDD — это не просто группировка классов, а способ защитить целостность домена и управлять сложностью.

Правильно выбранные границы агрегатов делают код:
- Более понятным,
- Устойчивым к ошибкам,
- Легким для масштабирования.

Главное правило:
Если сомневаетесь — делайте агрегаты меньше. Четкие границы спасут в долгосрочной перспективе!

P.s.
Полезная ссылка про агрегаты: https://dddinpython.hashnode.dev/mastering-aggregates-in-domain-driven-design

#DDD #Python #Aggregate #Entity #ValueObject #Программирование

[Domain Services в DDD: Логика, которая не принадлежит агрегатам]
(Когда и зачем использовать доменные сервисы?)

Продолжаю знакомиться с DDD. Следующий паттерн Domain Services.

Domain Service - это класс, который реализует бизнес-правила, выходящие за рамки одного агрегата.

В Domain-Driven Design (DDD) не вся бизнес-логика уместна внутри агрегатов или сущностей.
Иногда операции:
- Затрагивают несколько агрегатов,
- Зависят от внешних систем (например, проверка кредитного рейтинга),
- Не имеют естественного места в какой-то одной сущности.

Для такой логики создают Domain Services (доменные сервисы).

Отличия от других сервисов в DDD
Domain Service — содержит только бизнес-логику, не зависит от инфраструктуры.
Application Service — оркестрирует вызовы Domain-сервисов и инфраструктуры (например, «создать заказ → сохранить в БД → отправить уведомление»).
Infrastructure Service — технические детали (отправка почты, запросы к API).

Когда использовать Domain Service?
✅ Логика требует нескольких агрегатов.
✅ Зависит от доменных правил, но не принадлежит ни одной сущности (например, проверка сложных условий).
✅ Чистая бизнес-логика без инфраструктурных деталей.

❌ Не используйте, если:
- Логика относится к одному агрегату (лучше поместить в агрегат).
- Нужен доступ к БД, API и т.д. (это Application/Infrastructure Service).

✔️ Плюсы:
- Четкое разделение ответственности.
- Удобство тестирования (чистая логика без побочных эффектов).

❌ Минусы:
- Риск превращения в "God Object" (если сервис делает слишком много).

Domain Services — это мост между агрегатами для сложной доменной логики.

P.s.
Полезная ссылка по теме:
https://enterprisecraftsmanship.com/posts/domain-vs-application-services/

#DDD #DomainServices #CleanArchitecture

✅ 120 кг в жиме лёжа;
(мой вес 82,5 кг)

Недели 3 назад сделал несколько безуспешных попыток. Далее сказал себе, что не подойду к этому весу пока не буду уверенно работать со штангой 110 кг.

И вот позавчера (31 марта) впервые взял этот вес.

Получил много эмоций от достижения очередного результата)

#gym #life

[Памятка: как делать правильные тесты]

Раньше я писал юнит-тесты как будто "на автомате" — просто покрывал методы, проверял, что возвращается нужное значение, и считал, что всё ок.

Но это не совсем правильно. Тестировать методы ради покрытия — выглядит логично, но часто оказывается поверхностным и ненадёжным.

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

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

А свойства — это живое описание инвариантов кода. И это крайне важно.

Правильный подход — тестировать свойства поведения фичи, которые должны сохраняться независимо от реализации.

Вот что я теперь делаю:

1) Останавливаюсь и думаю: что вообще значит "правильно работает"?
Не метод за методом, а вся фича в целом.

2) Формулирую свойства корректности:
Например, "если policy создана — она должна быть доступна", "удаление policy делает её недоступной", и т.д.

3) Для каждого свойства выбираю способ тестирования:
Если можно покрыть юнит-тестами — пишу их. Если нужно — делаю фаззинг или просто руками проверяю.

4) Пишу тесты, которые проверяют именно эти свойства, а не случайные детали реализации.

Что изменилось?

- Тесты стало проще поддерживать: они не ломаются из-за мелких рефакторингов.
- Я лучше понимаю, зачем вообще эта фича нужна, а не просто "чтобы метод не падал".
- Реже ловлю баги в проде — потому что я реально проверяю смысл, а не поведение "по случайке".

#unittests #python #testdesign #tests