Привет, Хабр! Мы — команда DATA ОАТС в билайн. В этой статье расскажем о кейсе, когда стандартный Spark JDBC не справился с параллельным чтением огромной таблицы из ClickHouse, и мы написали свой «мини-движок». Под катом — разбор ограничений, схема с пулом потоков на экзекуторах и опыт, который может пригодиться не только для ClickHouse.
Привет, Хабр. В этой статье делюсь опытом повышения качества клиентских данных в онлайн-обучении и выводами, к которым я пришел по итогам.
В гонке за следующей волной «умных» систем большие языковые модели (LLM) берут на себя неожиданные роли. Одна из самых интересных — использовать такие модели как «судей» для оценки других моделей. Подход уже экономит командам массу ручной работы, но остаются вопросы: способен ли LLM уловить каждую тонкую ошибку? Что происходит в ситуациях, где критичны человеческая интуиция или глубокая предметная экспертиза?
Реальность такова: человеческие ревьюеры по-прежнему обеспечивают уровень контекстного понимания, которому ИИ пока не соответствует. Поэтому вместо того чтобы противопоставлять методы, многие в индустрии приходят к связке «LLM-судья + человеческая оценка» как к наиболее эффективной комбинации. В этой статье разберём, что такое LLM-судья, как он соотносится с человеческой оценкой и почему гибридный подход имеет наибольший смысл.
Обработка и анализ временных последовательностей (временных рядов) достаточно часто встречающаяся задача. Обычно она решается с помощью идентичных подходов и методов. Однако когда анализ временного ряда предполагает выражение каждого последующего элемента через предыдущие, возникают проблемы с эффективностью реализации такого анализа. Это особенно актуально в контексте больших данных.
В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.
Привет! Меня зовут Влад, я DWH-инженер в Циан. Занимаюсь проектированием витрин и пайплайнов для доставки данных в корпоративное хранилище. В этой статье хочу поделиться опытом применения методологии Data Vault на Greenplum.
Data Vault часто упоминают рядом с Kimball и Inmon, но практических материалов по его внедрению заметно меньше. Для инженеров, которые только начинают строить DWH или думают о переходе на Data Vault, я собрал практический разбор: на каких задачах методология действительно помогает, с какими трудностями можно столкнуться и как это выглядит в реальном проекте.
Вас просили заменить пустые значения нулями в отчетах? Возможно, стоит дважды подумать, прежде чем это делать!
Создаем песочницу для безопасного выполнения non-trusted DSQL-кода и возвращаем из него by design безопасный результат в высокопривилегированное кольцо
В мире Data Science и Data Engineering ценится не только теория, но и практический опыт: умение работать с реальными данными, строить модели и доводить решения до результата. Однако получить такой опыт непросто: рабочие проекты часто закрыты NDA, а учебные кейсы не отражают сложность реальных задач.
Именно поэтому платформа Kaggle заняла особое место в индустрии. Это крупнейшее мировое сообщество специалистов по данным:
Привет, Хабр!
Всем хорош Data Vault, однако схватиться с ним «врукопашную», используя только SQL, захочет не каждый. Останавливает большой объем ручных операций, а также большой объем деталей реализации. Большое количество join, за которые критикуют Data Vault, не является определяющим моментом, так как уже сейчас базы данных способны их эффективно обрабатывать, а с течением времени мощность серверов только возрастает.
Но творческая мысль не дремлет, постепенно появляются инструменты для автоматизации построения Data Vault. Например, это пакет AutomateDV для dbt, графическая надстройка над ним Datapulse, построение модели DV в BI.Qube.
Data Vault меня заинтересовал — уж много плюшек он сулит, и для его изучения я занимаюсь проектом asapBI — low‑code IDE для моделирования DWH. Требования к создаваемой системе я описал на сайте asapbi.ru. Их достаточно много, поэтому не буду их тут перечислять.
Сегодня я хотел поделиться графическим интерфейсом для создания хабов, линков и стеллитов.
Южная Корея запускает KISTI-6 — самый мощный суперкомпьютер в стране. В качестве подрядчика Корейский институт научной и технической информации (KISTI) выбрал Hewlett Packard Enterprise (HPE).
Компания возьмет на себя строительство шестого по счёту кластера KISTI, получившего название KISTI-6. Он станет самым мощным суперкомпьютером в Южной Корее с передовой системой безвентиляторного прямого жидкостного охлаждения.
Применение данной технологии обеспечит плотность размещения, эффективность и устойчивость системы на новом уровне.
В июле 2023 года Gartner представил отчет «Hype Cycle for Storage and Data Protection Technologies», предсказывая, что к 2026 году объем неструктурированных данных в локальных, периферийных и публичных облаках крупных предприятий вырастет в три раза!
Оптический бюджет в ВОЛС: Невидимая грань между работоспособностью и отказом. Как не оступиться в эпоху 100G+ и плотных ЦОД?
Представьте: вы спроектировали идеальную магистраль, выбрали "качественные" компоненты, смонтировали... И линк не поднимается. Или работает, но с ошибками. Или стабилен сегодня, но "падает" при нагреве летом. Часто корень зла кроется в нарушении оптического бюджета мощности (Optical Power Budget - OPB). Это не абстрактная цифра из даташита – это фундаментальный закон сохранения энергии в мире оптики. Игнорируете его – гарантируете себе головную боль. Сегодня, с ростом скоростей (100G, 400G, 800G) и плотности в ЦОД, понимание и точный расчет OPB критичны как никогда. Давайте разберемся, что это, из чего складывается, где поджидают ловушки и как избежать фатальных ошибок.
1. Суть Оптического Бюджета: Проще, Чем Кажется (На Словах)
По сути, OPB – это разница между мощностью, которую передатчик (Tx) излучает в волокно, и минимальной мощностью, необходимой приемнику (Rx) для корректной работы (чувствительностью) с учетом требуемого запаса (System Margin).
Упрощенная формула:OPB = P_Tx_min - P_Rx_min - System_Margin
Где:
Цифровая трансформация давно перестала быть громким лозунгом — сегодня это рабочий инструмент, от которого зависит выживание и рост компании. В «Росгосстрахе» я отвечаю за управление отчетностью, и наша задача — не просто автоматизировать процессы, а перестроить архитектуру принятия решений. В этом тексте — о том, как мы измеряем цифровую зрелость, зачем это делать и как использовать метрику как компас в непростом ландшафте изменений. Материал будет полезен тем, кто работает с данными, внедряет новые технологии, управляет трансформацией или просто ищет устойчивые опоры в эпоху цифрового сдвига.
Цифровая трансформация — это не про тренды, а про выживаемость. Но прежде чем менять процессы, важно понять: где мы находимся сейчас и куда действительно стоит двигаться. В этом смысле цифровая зрелость — не модное словосочетание, а инструмент навигации. Я расскажу о нашем подходе: какие шаги мы предпринимаем, какие метрики считаем значимыми и как используем их не ради отчётов, а ради движения вперёд.
По сути, мы решаем одну из самых сложных задач — пытаемся измерить сам процесс перехода, его глубину и устойчивость. Это непросто: цифры упрямы, а перемены часто текут не по линейной шкале. Но без этих измерений всё превращается в хаотичную трату ресурсов. Чтобы что-то улучшить, нужно сначала научиться видеть — не просто глазами, а данными.
Что такое цифровая зрелость и зачем её измерять?
Цифровая зрелость — это не абстрактный рейтинг, а срез состояния компании в моменте: насколько глубоко технологии проникают в процессы, насколько органично они встроены в стратегию, управленческие практики и ежедневные решения. Это не про количество IT-систем, а про то, как устроена ткань бизнеса — от культуры до архитектуры данных.
Федеративное обучение (Federated Learning, FL) становится всё более заметным элементом технологической повестки в условиях ужесточающихся требований к конфиденциальности данных и законодательных ограничений на их передачу. На прошлой неделе при поддержке канала @noml_community мы поговорили с коллегами (Дмитрий Маслов, Михаил Фатюхин, Денис Афанасьев, Евгений Попов, Роман Постников, Павел Снурницын) о Federated Learning. Получилось неожиданно интересно и полезно. Много говорили о кейсах, чуть меньше - о практических аспектах реализации, особенностях работы с данными и о специфике конфиденциальных вычислений. С большим удовольствием пообщались с коллегами по цеху и основными экспертами этой отрасли.
https://www.youtube.com/watch?v=JpApLfde38I&list=WL&index=1&t=12s
Мой вывод - FL как технология и как предмет сделали большой шаг вперед к тому, что бы технологии и потребности рынка “пересеклись” в точки эффективности и кажется что такой момент уже близко.
Централизованная аналитика — это фундамент эффективного принятия решений в компании. Чтобы данные действительно работали на бизнес, они должны пройти путь от извлечения до представления в понятной форме. Один из наиболее известных и проверенных временем подходов — архитектура, построенная на четырех ключевых модулях: интеграция, обработка, представление и управление. В этой статье мы познакомимся с каждым из них, а также рассмотрим один из рабочих вариантов реализации (DQ, BI, метаданные и др.).
Я убеждён в том, что аналитикам данных критически-важно иметь доступ без боли, искажений и рисков к наиболее детализированным данным проекта для исполнения своих обязанностей..
Нет данных - нет мультиков аналитики. Работа только с агрегированными и преобразованными по непрозрачной логике данными приводит к ошибкам и отсутствию доверия от бизнеса.
Статья может быть полезна к изучению при принятии решений о развитии аналитики с 0 в проекте.
К сожалению, вопросу получения данных часто не уделяется хоть какое-то внимание.
Бизнесу интересно не получение данных, а инсайты и рекомендации. Принято отдавать этот вопрос на откуп аналитикам и взаимодействию аналитиков и IT. Только у аналитиков редко есть опыт и понимание лучших практик по работе с данными и для IT задача использования данных аналитиками может быть чем-то чужеродным.
Тем не менее, как-то они договариваются. Не сталкивался с примерами, когда совсем не договорились и никакой аналитики нет.
Сталкивался с разными вариантами урона от реализации.
Казалось бы, преимущества найма специалистов по данным сегодня очевидны — нанимай и принимай качественно лучшие решения. Однако на практике многие компании сталкиваются с трудностями. Предлагаю разобраться
Подбор персонала — это поиск иголки в стоге сена, с одной оговоркой: иголка должна хотеть работать именно у вас. Когда на входе — сотни резюме с hh.ru, а на выходе нужно выбрать топ-5 кандидатов, без автоматизации не обойтись. Но как научить алгоритм отличать будущего топ-менеджера от человека, который в графе «Опыт работы» указал «10 лет в Minecraft»?
> Данная статья -- результат моего выступления на конференции AMITA. И первый шаг в создании диссертации. Тема еще требует проработки, но кажется мне перспективной. Поэтому этой статьей я хочу призвать силу хабрасообщества -- для критики, обсуждения или поддержки (как пойдет).
Проектирование хранилища «от интерфейсов» (когда сначала прорабатывается интерфейс дашборда, а потом определяются необходимые для его работы данные и алгоритмы их обработки), по моему мнению, при внедрении в масштабах всего предприятия становится излишне сложным, так как вместе с количеством пользователей возрастает и количество интерфейсов.
Последовательный же перебор всех стейкхолдеров приводит к появлению фактически разных метрик под одним и тем же названием, а так же к формированию интерфейсов «из того, что есть», а не из тех данных, которые действительно требуются. Нередко в таком случае дизайн интерфейса выходит на первое место относительно полноты и реальной необходимости представляемых им данных.
RFM анализ это
Общий алгоритм обсчета
1 Построить из исходного датасета таблицу пользователей, определив для каждого количество транзакций, общую сумму платежей и дату первой и последней операции.
2 Вычислить дополнительные показатели
3 Определить границы RFM рангов и присвоить их каждому пользователю
4 Построить RFM таблицу, сгруппировав пользователей по рангам.
5 На основе RFM таблицы построить тепловую карту
