Хранилища данных *

У меня как и, наверное, у любого айтишника есть какое-то огромное количество файлов, которое надо бэкапить. И у меня уже есть NAS с обычными HDD дисками для моих бэкапов. Но для себя я решил, что NAS c HDD хорошо подходит для хранения чего-то к чему не очень то и часто обращается. А вот если нужно хранить что-то что иногда нужно скачать или закачать, то значительно приятнее работать с NAS на NVME дисках.

Таких девайсов на самом деле не так уж и много. Есть некоторые модели на 4 диска. А вот на 8 дисков я даже и конкурентов не знаю. Поэтому сегодня будет обзор на уникальную по-своему штуковину - NAS на 8 быстрых NVME дисков. Да еще и с 10 гигабитным ethernet портом.

Почему, по данным экспертов GlowByte, целых 80% проектов внедрения систем бизнес-аналитики выходят за рамки изначально запланированного бюджета? Ответ парадоксально прост и сложен одновременно: компании систематически недооценивают реальную совокупную стоимость владения BI-системами. Наши наблюдения показывают, что большинство заказчиков концентрируются исключительно на очевидных статьях расходов, игнорируя множество "скрытых" факторов, которые неизбежно проявляются по мере развития проекта.

За годы работы с десятками проектов внедрения аналитических систем мы в GlowByte выявили закономерность — даже опытные ИТ-директора порой не учитывают до 40% реальных затрат при планировании бюджета на BI-инициативы. В этой статье я поделюсь инсайтами о наиболее типичных "финансовых ловушках", которые подстерегают компании на этом пути.

Привет! Меня зовут Алексей Баранов, я руковожу направлением Data Storage Systems в облаке MWS. Мы начинаем серию статей, в которой расскажем, как устроены наши системы хранения, почему мы их делаем так и почему именно такие.

В этой статье расскажу, как мы подошли к выбору технологий для object storage новой облачной платформы. Обсудим плюсы и минусы популярных на рынке решений вроде Ceph RGW, какие требования мы предъявляли к системе, и какая архитектура в итоге получилась.

Для анализа и обработки больших объёмов данных применяются специальные системы — OLAP (Online Analytical Processing). Мы разберём основные принципы их работы, преимущества и примеры использования.

Определение OLAP-систем

OLAP-системы — это инструменты для анализа данных, которые позволяют быстро и эффективно находить ответы на сложные вопросы. 

Они находят применение в разных сферах, таких как финансы, производство, розничная торговля и другие.

Пример использования OLAP-технологии

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

Спойлер: ни одна из описанных ниже концепций не является фантастикой. Все они — логическое продолжение уже происходящих процессов.

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

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

Весна 2025 года — отличное время, чтобы оживить мой проект Econet, который посвящён проблемам цифрового мусора, современным подходам к работе с данными и инфраструктуре информационных систем.

В данной статье приводится решение проблемы построения витрин данных в реальном времени с помощью Apache Flink. Рассказывается 2 часть подробной реализации решения этой задачи. В данной части рассмотрена проблема учета сообщений на удаление и частично операций update , в связи с чем достигается полная консистентность данных СИ с СП при условии гарантии, что ключ join условия не обновляется.

Привет! Меня зовут Кирилл Львов, я fullstack-разработчик в компании СберАналитика. В этой статье хочу рассказать про мощный инструмент трансформации данных — DBT (Data Build Tool).

Сегодня любой средний и крупный бизнес хранит множество данных в разрозненных источниках (CRM, ERP, HRM, базы данных, файловые хранилища и т.д.). Каждая из этих систем самодостаточна и закрывает определённую боль бизнеса, но собрав данные из таких источников и стандартизировав их, нам открывается возможность анализировать данные, строить модели машинного обучения и принимать на основе этих данных управленческие решения. Для того чтобы реализовать такой подход строятся ELT (или ETL) процессы. ELT (Extract, Load, Transform) — это процесс, состоящий из трех этапов:

Всем привет! Меня зовут Диана Бутько, я студентка 3 курса, изучаю информационные системы и программирование. В InfoWatch я пришла на практику, и одной из моих задач стал сравнительный анализ различных методов поиска похожих векторов. Это один из ключевых аспектов машинного обучения и анализа данных, используемых в рекомендательных системах, кластеризации, семантическом поиске и других областях. Но чем больше объем данных, тем важнее становится выбор инструментов: полный перебор векторов требует больших вычислительных ресурсов, а в других алгоритмах порой необходимо балансировать между точностью и скоростью поиска.

В этой статье я сравниваю пять методов поиска похожих векторов:
— полный перебор по евклидову расстоянию с реализацией в Python;
— FAISS с индексами IndexFlatL2 (полный перебор, евклидово расстояние) и IndexIVFFlat (сегментирование по ячейкам, евклидово расстояние);
— векторный поиск в ClickHouse с индексом HNSW и метриками расстояния L2Distance (евклидово расстояние) и cosineDistance (косинусное сходство).

Делюсь личным опытом превращения старенького ноутбука ASUS X552CL (Intel i5-5200U, 12 ГБ RAM, SSD + HDD), выпущенный 12 лет назад, в полноценный домашний сервер под Linux Ubuntu Server 24.04.5 LTS.

Получилось что-то вроде мини-датацентра на дому — он хранит файлы на жёстком диске с бэкапом в облаке, Docker-контейнеры крутит для дата-аналитики и даже имеет легковесный интерфейс XFCE, при этом есть потенциал к росту до терминала для управления умным домом. Расскажу, почему было решено отказаться от WSL на рабочем ноутбуке Huawei, как настроить удалённый доступ через xRDP (чтобы не было чёрного экрана), запустить там Docker, сборку Superset и JupyterLab с Anaconda (с разными версиями Python), прикрутить Samba-шару для домашнего использования и организовать бэкап в облачном хранилище. В этой статье будет немного технических деталей, щепотка шуток и парочка мемов с советскими плакатами.

Всех приветствую, читатели Хабра!

В сегодняшней статье я поделюсь примерами кракинга зашифрованных паролями pdf-файлов и файлов архивов. Я покажу примеры работы с такими программами как pdfcrack, rarcrack, John the Ripper. Естественно данные программы работают в линукс (в моем случае Kali Linux), но под Windows я думаю есть аналоги данных программ. И да, в этой статье я затрону примеры связанные с john, хоть возможно на Хабре и имеются статьи связанные с данной программой (а в русскоязычном сегменте интернет точно есть описания как с ней работать), но в рамках данной статьи мои примеры будут уместны и необходимы. Это своего рода онлайн-шпаргалка по использованию данных утилит

Примечание

Правовая информация:

Данная статья создана исключительно в ознакомительных/образовательных/развивающих целях.
Автор статьи не несет ответственности за ваши действия.
Автор статьи ни к чему не призывает, более того напоминаю о существовании некоторых статей в уголовном кодексе РФ, их никто не отменял:
УК РФ Статья 272. Неправомерный доступ к компьютерной информации
УК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ
УК РФ Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей

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

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

Всех приветствую! Зовут меня Павел, работаю в Datapulse. Создаем различные решения для автоматизации DWH.

Мы живем в переходном периоде, когда на смену традиционным инструментам и подходам в data-engineer приходят новые. То, что еще вчера казалось стандартом де-факто, сегодня все чаще воспринимается как анахронизм. Пример тому - война GUI («гуевых») ETL инструментов со скриптовыми закончилась безоговорочной победой последних. Скрипты взяли верх благодаря своей масштабируемости, возможности применения Git и лучшей интеграции в процессы CI/CD.

А что же с BI? Мы привыкли к мастодонтам: PowerBI, Tableau, Qlik. Либо open-source: Superset, Metabase. Они в свое время стали стандартом, захватив большую часть рынка, а sales manager получали очень неплохие премии за их внедрение. И, казалось, время молочных рек и кисельных берегов не закончится никогда. Компании продолжат тратить кучу денег на красивенькие графики, которыми не пользуются, а в сообществе аналитиков будут лишь рассуждать о том, как доказать упертому менеджеру, что дашборд-вундервафля в PowerBI гораздо удобнее старого доброго Excel (шутка).

А времена эти, если и не прошли, то близятся к закату. Старые короли чахнут и умирают. Приветствуем новых!

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

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

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

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

При импорте данных в Manticore вы можете гибко их обрабатывать:

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

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

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

Современные потребности в Центрах Обработки Данных достигли невероятных масштабов, превратив их проектирование и строительство в практически рутинный процесс. Каждый заказчик стремится получить больше, чем просто стандартное решение: им нужны ЦОД, которые соответствуют принципу «Больше, выше сильнее». Больше машзалов, выше потолки, мощнее охлаждение. Иногда эти запросы доходят до экзотических решений, таких как размещение ЦОД в регионах с холодным климатом, например, в Скандинавии, где естественная вечная мерзлота используется для охлаждения серверов, или даже подводные дата-центры, которые погружаются на дно океана для снижения затрат на охлаждение.

Однако, несмотря на такие необычные подходы, большинство проектов ЦОД остаются довольно типичными. Тем не менее, каждый из них имеет свои уникальные особенности и нюансы, которые возникают из-за классической дилеммы: «Быстрее, лучше, дешевле — выбери только два». При разработке проекта часто приходится выбирать между тем или иным решением, обосновывая свою позицию экономией средств или большей надежностью. Эта проблема становится ключевой при разработке любого проекта, заставляя инженеров и архитекторов постоянно искать компромиссы. Например, приходится выбирать между более дорогим, но надежным оборудованием и бюджетными решениями, которые могут сэкономить средства, но потребуют дополнительных усилий для обеспечения стабильной работы. Каждый выбор требует тщательного обоснования, будь то экономия ресурсов или повышение надежности инфраструктуры.

Аналитика по скидке: когда клиенты готовы платить только впечатлениями

Если данные новая нефть, то почему за нее не готовы платить?

Как измерить ценность внедрения аналитики?