Хранение данных *

Успешные тестирование производительности и нагрузочные испытания – важнейшие условия для выбора аналитической системы массивной обработки больших данных. В этой публикации я хочу поделиться подходами к тестированию, которые используются нашей командой как в проектной работе, так и при разработке Lakehouse-платформы данных Data Ocean Nova, и познакомить вас с результатами сравнения различных движков и систем. Вы узнаете, как правильно ставить цели, выбирать методику и из каких сценариев ее нужно составлять, как протоколировать результаты и делать выводы. И самое главное – получите ответ на вопросы: кто быстрее: заяц Trino или антилопа Impala?

Хабр, привет! На связи Алексей Зотов из К2Тех. Поиск надежных альтернатив западным системам хранения по-прежнему актуален для нас и наших клиентов. Не так давно в инфраструктурную лабораторию К2Тех приехало железо от ведущего российского разработчика и производителя YADRO, которому я решил посвятить небольшой цикл статей. В первой части я рассказывал об универсальной СХД начального уровня TATLIN.FLEX. А сегодня, как и обещал, поделюсь результатами тестов специализированной СХД для резервного копирования с поддержкой глобальной дедупликации — TATLIN.BACKUP. Эта система позиционируется как отечественная альтернатива популярным решениям Dell DataDomain и HPE StoreOnce.

Мы проверили ее производительность, отказоустойчивость и эффективность оптимизации данных. Уделили внимание сравнению с западными аналогами и тестированию новой версии 1.1 с поддержкой T-Boost. Давайте узнаем, насколько эффективна TATLIN.BACKUP в реальных условиях.

В начале декабря мы выпустили новую версию нашего гиперконвергентного решения Кибер Инфраструктура. В этом релизе перед нами стояли две большие задачи: повышение эффективности системы в целом и объектного хранилища S3 в частности. Кроме того, версия 6.5 стала первым релизом продукта, подготовленным в рамках процесса безопасной разработки.

Вот-вот выйдет релиз OpenZFS 2.3.0 с новой функцией Fast Dedup. Это огромный шаг вперёд по сравнению со старой дедупликацией и отличный фундамент для будущих доработок.

Контрибьютор OpenZFS @gmelikov и команда VK Cloud совместно перевели статью об этом релизе, в которой новая функция сравнивается со старой дедупликацией и описывается максимально подробно с практическими примерами. В 2023–2024 коллеги из Klara много работали над этой функцией, и мы согласны с ними, что она весьма хороша! 

После релиза Fast dedup на многих ресурсах в обсуждениях продолжили писать, что «новый дедуп всё так же плох, он требует столько же ОЗУ и также убивает производительность». Но эта информация лишь отчасти близка к правде и повторяет всё тот же мотив, который когда-то кто-то озвучивал на форумах.

Винить в этом никого не хочется. И не стоит, так как дедупликация в OpenZFS и правда была очень требовательной к правильному применению. Найти качественные гайды тоже не просто, ответ по умолчанию — «не используйте её» — был и (в целом) остаётся правильным. Но, по прошествии почти 20 лет жизни дедупа в OpenZFS, настало время вернуться к этому вопросу.

Посмотрим на свежую информацию об имплементации дедупа в OpenZFS, как он работал до улучшений, в чём была его проблема, что поменяли в fast dedup, и почему же это всё ещё не дефолт.

Рост любой компании сопровождается ростом ИТ-инфраструктуры. А если ты — облачный провайдер, то инфраструктуры очень много. И нагрузка на неё тоже высокая. Когда нам стало тесно в границах используемых ЦОД, мы решили построить собственный — под рабочим названием DC4Y.1-Марфино. Сегодня хотим рассказать, как началось строительство собственного дата-центра Cloud4Y и каким он должен стать.

Привет, Хабр! На связи Александр Чебанов, product owner Modus. 

Ранее мы обсуждали различные способы интеграции 1С с КХД в статье. Теперь давайте подробнее разберем, как получить доступ к справочникам, документам и другим данным, используя стандартные HTTP-запросы через REST-интерфейс и протокол OData 3.0.

Хабр, привет! Я работаю в департаменте бизнес‑аналитики ППР — компании, которая создаёт экосистему сервисов для автопарка. Зимой 2024 года нам пришлось в короткий срок мигрировать на новый для нас BI‑сервис DataLens: подготовить инфраструктуру, развернуть три новых инструмента и мигрировать 100+ витрин и дашбордов.

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

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

Привет, Хабр! У многих хостинг-провайдеров, предоставляющих услуги по аренде виртуалок, возможно самостоятельно сконфигурировать тариф под себя, выбрав необходимые параметры и их объём (тип процессора, тип диска, количество IP и т. д). Мне давно было интересно сравнить производительность SSD и NVMe в рамках одного хостинг-провайдера, чтобы понять, есть ли смысл переплачивать за более быстрый диск, а также их производительность между провайдерами. И вот наконец-то у меня появилось немного времени на подобный эксперимент — спешу поделиться результатами! И да, в этот раз со сравнительной итоговой табличкой :)

Привет, Хабр! На связи Алексей Парфентьев, я в «СёрчИнформ» заведую инновациями и аналитикой. Каждый год мы изучаем, чем и как защищают данные российские компании (кстати, недавно делились первыми результатами этого года). Увидели, что доля внедрения DCAP‑решений с 2021 года выросла почти в 10 раз (с 2,5% до 21%). Эта цифра меня зацепила — и вот я тут.

Вот в чем дело. DCAP — не новичок на рынке, первые полноценные российские решения появились пять лет назад, зарубежные гранды вроде Varonis известны и того дольше. На сегодня, на волне спроса почти каждый отечественный вендор DLP выпустил или начал разрабатывать собственную DCAP‑систему. И при этом ни у заказчиков, ни у вендоров пока нет консенсуса, что DCAP точно должны уметь!

На практике это значит, что системы на рынке часто сходятся только в заявленных задачах: это аудит, классификация и защита данных в корпоративных хранилищах (Data‑Centric Audit and Protection — см. классификацию по Gartner). А решают их все по‑своему. Я решил разобраться, от чего это зависит, какие преимущества и риски у разных подходов и какой вариант — оптимальный.

Привет! Я Николай, аналитик во ВкусВилле, я запустил и поддерживаю проект по каталогу данных в ВВ. 

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

Сделали каталог своими руками, как подошли к этому вопросу и что получили в итоге —расскажу в этом материале. 

Всем привет! Меня зовут Михаил, я руковожу разработкой хранилища данных «Магнит OMNI». Хочу рассказать, как мы решали проблемы его создания: разделение ресурсов хранилища между несколькими большими равнозначными заказчиками; переиспользование кода для оптимизации рутинных задач; развитие платформы DWH в условиях активно растущего бизнеса; навигация в сотнях витрин и соблюдение единообразия расчёта метрик.

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

Никогда не пытайтесь сделать домашний интернет своей опорной инфраструктурой.

Сколько раз вы слышали совет: "Укажи GitHub в резюме для поиска работы"?

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

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

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

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

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

Так же, как и Spark, Table API использует свой диалект SQL, который можно использовать над таблицами. Таблицу мы можем зарегистрировать в каталоге Table API и обращаться к ней с помощью SQL, используя команду Execute SQL. Все преобразования можно делать как обращаясь к таблице напрямую, через метод, так и при помощи SQL, то есть при помощи Select можно создать новую таблицу. Может запускаться как приложение, так и интерактивно SQL-запросами. То есть если у вас развернут Flink-кластер, то можно к нему подключиться при помощи Flink SQL, вбивать команды, создавать каталоги, подключаться к каталогам и проворачивать, например, батчевые SQL-запросы, которые перетягивать данные.

Главная фишка: источники и приемники могут создаваться и конфигурироваться при помощи DDL SQL.

Меня зовут Сергей Гребенюк, я лидер разработки Sidec (Росреестр). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams (kafka docs) и RocksDB (github). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) (confluent docs), смогли снизить требования к ресурсам в несколько раз.

На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй. 

Привет!
Кажется, первая статья нашла своего благодарного читателя.Снова мысли от CDO трудящегося вместе с одной небольшой компанией ру-сегмента.
Продолжу о том, что "наболело".

Эта статья может быть Вам полезна, если консалтинг/интегратор/CTO/CIO/сын маминой подруги настойчиво хочет решить все Ваши "проблемы" в аналитике классным корпоративным хранилищем, далее - DWH.

Привет! Меня зовут Александр Булатов, я старший инженер данных в Блоке Данных билайна. В этой серии статей я расскажу, как выглядит создание Source и Sink для Table API & SQL и как Table API взаимодействует с DataStream API.

Я работаю на проекте Radcom, в котором мы получаем данные о детализации звонков. И есть источник потоковых данных, которые мы получаем с Kafka. Таких потоков у нас внутри Radcom одиннадцать штук, и данные от них идут в формате csv. Формат не самый удобный для обработки, потому что он не имеет в себе схему — нам присылают просто голые строки csv, без какой-либо схемы, и нам нужно парсить эти строки относительно ее. 

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

Так вот, мы принимаем данные в csv и должны их сохранять в Hive в колоночных форматах, чтобы впоследствии аналитики и Data Scientists могли пользоваться этими данными. У нас принято использовать либо ORC, либо Parquet. Мы попробовали оба формата, пришли к Parquet. 

Всем привет! На связи Виктор Стародуб — технический лидер команды S3, один из авторов и создателей объектного СХД в Cloud.ru. Недавно вышла статья, в которой мой коллега Сергей Лысанов @LysanovSergey рассказал, как мы сделали собственный Software-Defined Storage для дисков виртуальных машин в публичном облаке Cloud.ru Evolution. А в этой статье я расскажу о том, как мы написали свое объектное хранение, имея отказоустойчивое блочное хранилище в качестве базового слоя, с какими сложностями столкнулись, как их решили и какие сделали выводы.

Миф о чистых данных: почему ваш аналитик похож на сапёра.

Как бороться с самым частым убеждением при работе с данными.