Простота — это великое благо, но для её достижения необходим усердный труд, а для понимания — хорошее образование. Чего не скажешь про сложность, которая продаётся намного легче». — Эдсгер Дейкстра

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

Естественно, это происходит ненамеренно. Никто не строит коварных планов в духе «А давай сделаем так, чтобы повышение получали только те, кто всё усложняет.» Но такое нередко происходит, когда в компании неверно оценивают проделанную сотрудниками работу.

Когда я впервые услышал о Data Warehouse (DWH), мне казалось, что это просто большая база данных. Однако, углубившись в тему, я понял, что настоящее хранилище данных должно отвечать множеству требований. Например, оно должно обеспечивать гетерогенность — возможность принимать данные из множества различных и несвязанных систем, что отличает его от классических реляционных или транзакционных баз данных. Оно должно обладать гибкостью и расширяемостью, позволяя добавлять новые источники данных без нарушения работы системы. Также важна историчность — способность хранить изменяющиеся атрибуты, такие как смена фамилии сотрудника. Хранилище должно быть способно обрабатывать огромные объемы данных и при этом обеспечивать высокую скорость обновления, позволяя создавать отчеты на основе актуальной информации.

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

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

В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных.

Data Vault 2.0 остаётся одним из самых популярных методов моделирования данных. Его выбирают за гибкость, масштабируемость и устойчивость к изменениям. Этот разработанный Дэном Линстедом подход помогает организациям быстро адаптироваться к новым бизнес-требованиям, легко интегрировать новые источники данных и надёжно хранить исторические данные.

Эта статья будет полезна дата-инженерам, аналитикам данных, архитекторам данных и бизнес-аналитикам. Она поможет усовершенствовать умения в моделировании данных. Мы рассмотрим ключевые принципы Data Vault 2.0 и на практическом примере покажем, как разложить сырые данные по Data Vault 2.0.

В работе мы с коллегами часто видим как компании сталкиваются с проблемой управления данными – когда таблиц и запросов становится сильно много и управлять всем этим очень сложно. В таких ситуациях мы рекомендуем моделировать данные. Чтобы разобраться, что это такое – я перевела статью-обзор про моделирование данных от Towards Data Science, в которой кроме основных терминов и понятий можно найти наглядный пример использования моделирования данных в ритейле. Вперед под кат!

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.

У коллег весной вышла резонансная статья про особенности выбора жестких дисков для систем поиска аномалий в сетевом трафике на примере PT NAD. Я подумал, что тоже могу добавить что-нибудь в эту копилку. Тем более, что еще в 2018-м году в рамках какого-то закрытого SOC Day для заказчиков я рассказывал про особенности организации хранилищ для событий безопасности в центрах мониторинга безопасности. Пришло время сдуть пыль с архивов, дополнить их свежей кровью и выложить на суд общественности.

Итак, если коллеги рассказывали про хранение данных для систем поиска сетевых аномалий, то я буду рассуждать про решения класса SIEM (Security Information and Event Management), которые собирают и хранят огромные объемы событий безопасности и для которых правильный выбор накопителей и архитектуры хранилища (а вот про это коллеги не рассказывали, сфокусировавшись только на накопителях) критически влияет на скорость записи событий, быстроту поиска, масштабируемость и надежность всей системы мониторинга. Я попробую рассмотреть ключевые факторы, влияющие на этот выбор, – от интенсивности записи и индексации до уровней хранения и облачных решений, а также проанализирую плюсы и минусы различных вариантов, давая рекомендации под разные сценарии. И хотя в заголовке статьи упоминается только SIEM, описанные рекомендации подойдут для многих средств защиты, активно пишущих, хранящих и обрабатывающих события ИБ.

Для запуска и эксплуатации высоконагруженных ИТ-решений с петабайтами данных в активе, нужно проработанное решение, позволяющее гибко управлять ресурсами. Одним из критичных аспектов этого решения, является разделение Compute & Storage — разделение ресурсов инфраструктуры под вычисление и хранение соответственно. Если не реализовать такое разделение в крупном проекте, инфраструктура рискует превратиться в «чемодан без ручки» — эффективность использования ресурсов будет низкой, а сложность управления ресурсами и средами будет высока. На примере команды SberData и их корпоративной аналитической платформы я расскажу, когда требуется разделение Compute & Storage и как это реализовать максимально нативно.

Статья подготовлена по мотивам доклада на VK Data Meetup «Как разделить Compute & Storage в Hadoop и не утонуть в лавине миграций».

Чем контейнеры отличаются от виртуальных машин, почему Docker настолько популярен, что такое Kubernetes и в чём его преимущества и недостатки. В интервью АйТиБороде СТО «Слёрма» Марсель Ибраев и старший инженер Southbridge Николай Месропян рассказали о контейнеризации понятным языком. Мы перевели интервью в текст для тех, кому лень смотреть.
Мне не лень смотреть, мне лень читать

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

Будут затронуты следующие темы:

• Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
• Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
• Как диагностировать проблемы на production-кластере ClickHouse.

В работе с публичными облаками много плюсов, но с точки зрения ИБ — есть свои риски по сравнению с on‑premises. Минимизировать их помогает выделенный Security Operation Center (SOC). При этом создать его у себя не так просто: для эффективной работы SOC в Yandex Cloud понадобилось несколько лет разработки, а также технологии и мощности Яндекса, которые развивались годами.

Поскольку у клиентов облака не всегда есть ресурсы и экспертиза, чтобы создать подобный SOC у себя, мы не только строили свой центр, но и параллельно делали на его основе управляемый сервис Yandex Cloud Detection & Response (YCDR). В процессе разработки мы должны были позаботиться о том, чтобы даже привилегированные учётные записи не могли обойти семь слоёв облачной безопасности, — и в итоге многие компоненты написали самостоятельно.

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

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

• возникла задача “сделать быстро хоть что-то, а потом посмотрим”;
• появился бурно развивающийся проект, с подключением новых источников и переделкой бизнес-модели минимум раз в неделю;
• появился заказчик, который не представляет как система должна выглядеть и какие функции выполнять в конечном итоге, но готов к экспериментам и последовательному уточнению желаемого результата с последовательным же приближением к нему;
• заглянул менеджер проектов с радостной вестью: “А теперь у нас аджайл!”.

B-дерево — это структура, помогающая выполнять поиск в больших объёмах данных. Она была изобретена более сорока лет назад, однако по-прежнему используется в большинстве современных баз данных. Хотя существуют и более новые структуры индексов, например, LSM-деревья, B-дерево пока никто не победил в обработке большинства запросов баз данных.

После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.

Документ «deducing this», принятый в последний стандарт C++, вводит новый, третий тип методов классов, сочетающий в себе свойства двух уже существующих: нестатических и статических, открывающий перед нами новые горизонты:

1. Дедупликация большого количества кода.

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

3. Рекурсивные лямбды.

И другое.

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

Даже сложная и продуманная технологическая система не застрахована от инцидентов — это касается любых инфраструктур, от железнодорожных и коммунальных до IT. Поэтому инженерам, которые обеспечивают надёжность систем, важно не только предотвращать проблемы, но и минимизировать их влияние за счёт хорошего антикризисного (или DR) плана.

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

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

— что важно знать о том, как ломаются большие системы, на наших примерах;

— как мы проанализировали все наши инциденты за последний год и что сделали, чтобы предотвратить появление проблем на инфраструктуре;

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

В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают Load Balancer как сервис. Но что делать, если инструменты не справляются с ростом масштабов и необходимо автоматизируемое cloud-native-решение?

Я Дмитрий Самохвалов, архитектор в K2 Cloud. В этой статье поделюсь, как мы из-за ограничений старых систем для динамической конфигурации перешли с работающих решений nginx и HAProxy на модный Envoy. Расскажу, почему сочли это решение подходящим, какие возможности есть у Envoy, каким был опыт внедрения и оставлю рекомендации для эффективного перехода. Будет полезно разработчикам cloud-native-приложений и инфраструктуры, а также всем, кто хочет создать единое платформенное решение для взаимодействия сервисов и инфраструктуры.

1. Модули и краткая история C++.
2. Операция «космический корабль».
3. Концепты.
4. Ranges.
5. Корутины.
6. Другие фичи ядра и стандартной библиотеки. Заключение.