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

Весна 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-системах. Вам нужно это знать, даже если в вашей компании работает три человека

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

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

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

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

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

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

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

Сравниваем Ansible с другими инструментами для автоматизации управления инфраструктурой: Puppet, Chef, SaltStack.

Дана функция чтения и записи EEPROM dword.

Запись и стирание возможно только по выровненному адресу и пословно.

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

Простыми словами надо состыковать Dword API с Byte API.

В этом тексте я представил простой наивный алгоритм решения данной задачи.

Привет! Меня зовут Андрей Дорожкин, и я руковожу командой администрации баз данных в Hybrid. В этом материале я поделюсь опытом работы с ClickHouse — колоночной БД, разработанной специально для аналитических запросов, которая позволяет получать результаты в разы быстрее традиционных решений. Также я подсвечу, как устроен этот продукт, чем он отличается от реляционных баз данных, и в каких сценариях его использование может дать бизнесу реальное преимущество.

Пара слов о компании Hybrid. Мы — независимая AdTech-экосистема с собственным стеком технологий и решений для любых рекламных целей. Развиваем собственные технологии благодаря in-house отделу разработки, который каждый день работает над их улучшением. ClickHouse — инструмент, который мы выбираем для хранения данных за высокую скорость обработки запросов, эффективное сжатие данных и масштабируемость.

Выбор облачного хранилища данных — задача не из простых: десятки решений, каждая со своими плюсами и подводными камнями. В этой статье — результаты масштабного практического исследования, в ходе которого команда Agritask сравнила производительность, масштабируемость, стоимость и совместимость SQL ведущих платформ: от ClickHouse и BigQuery до Druid и Firebolt. Без маркетинговых обещаний — только реальные тесты, живые выводы и нюансы, которые неочевидны до момента внедрения.