Кто вы в мире данных — аналитик, BI-разработчик или Data Engineer? 🔍 Разбираем реальные роли и показываем, чем они отличаются на практике.
Внешние факторы меняются быстрее, чем успевают перестроиться планы компаний. Колебания валют, сбои в цепочках поставок и неожиданные регуляторные запреты напрямую влияют на выручку и оборачиваемость запасов — от сырья до готовой продукции.
Система бизнес-аналитики объединяет данные из разных источников, чтобы руководители видели причинно-следственные связи и принимали обоснованные решения. В этой статье разберём, почему BI — главный инструмент в кризис и как выстроить real-time аналитику.
Представьте: у вас 17 предприятий, на каждом работают сотни операторов, слесарей, аппаратчиков. Каждый должен знать свое оборудование, уметь его обслуживать и — главное — работать безопасно. А еще каждый завод ведет учет по-своему: кто в Excel, кто на бумаге, кто как придумал.
Такой разнобой плохо сказывается на всём бизнесе: сложно понять, какие компетенции реально закрыты, кто готов к аттестации, где есть риски для безопасности. Масштабировать процессы на всю компанию при такой «лоскутной системе» невозможно.
Именно с этой задачей к нам в ИТ пришли коллеги из бизнеса. Вопрос звучал не как «сделайте нам новую систему», а как «нам сложно управлять компетенциями в текущем виде, помогите». Это важный момент: мы в СИБУРе не создаем продукты ради самой разработки. Производство приходит к нам с проблемой или потребностью, а ИТ подключается как партнёр, который превращает методологию и практики бизнеса в работающий цифровой сервис.
Так появился проект «Инженерный стандарт» — разработка на стыке бизнеса и ИТ, цель которой была не просто автоматизировать Excel, а выстроить единый, масштабируемый и прозрачный процесс управления компетенциями.
Привет, Хабр! В прошлой статье я рассказывал о гибридных RFID метках и том, как мы решали проблему маркировки оборудования в локомотивном депо. Сегодня история побольше — как за 40 лет два поколения инженеров прошли путь от полного отсутствия диагностики электровозов до создания системы цифрового двойники и удаленного управления диагностическим оборудованием.
Самым популярным методом ограничения доступа к данным в отчете Power BI остается Row-level Security (RLS), с помощью которого у каждого пользователя есть доступ к набору данных согласно его учетной записи или роли. В этом случае пользователь видит все страницы и объекты отчета, которые отражают результаты согласно ограничениям, наложенным на датасет.
Но зачастую этого становится недостаточно и появляется необходимость в ограничении доступа не только к строкам датасета, по которым будет построен отчет, но и к страницам целиком и даже к отдельным объектам видимых страниц.
Вопрос реализации RLS подробно освещён, поэтому останавливаться на деталях не буду. Вместо этого сконцентрируюсь на двух других способах: ограничении доступа к страницам и объектам.
В 2019 году центральная BI-команда нашей компании столкнулась с типичной задачей: как небольшой командой разработчиков обеспечить качественную аналитику для тысяч сотрудников в условиях быстро растущего бизнеса и высокой самостоятельности подразделений?
Мы сделали ставку на модель self-service BI: инструмент передали бизнес-пользователям, чтобы они могли сами строить отчёты. Идея «демократизации данных» поначалу казалась удачной. Но без чётких правил, стандартов и контроля всё быстро превратилось в BI-хаос: тысячи разрозненных отчётов, низкая производительность, противоречивые метрики и перегруженная инфраструктура на Premium P3. Пользователи жаловались, доверие к BI падало, а управлять этим потоком становилось всё сложнее.
В этой статье мы — Ринат Хабибрахманов, руководитель практики BI в Лемана Тех, и Лариса Фернандес, ведущий разработчик аналитических систем, — делимся опытом нашей команды. Расскажем, как мы шаг за шагом внедряли процесс ревью Power BI-отчётов, чтобы вернуть контроль, улучшить качество аналитики и восстановить доверие пользователей к BI-системе.
Ключевым шагом стало внедрение процесса ревью. Ниже подробно разберём, зачем он понадобился, какие цели мы ставили и как его организовали.
Если в вашей компании есть BI и дашборды, то скорее всего, вы сталкивались с процессом постоянной разработки и чистки. Такой процесс похож на игру на аккордеоне – вы то сжимаете вашу отчетность до единичных дашбордов с ключевыми метриками, то раздуваете ее до десятков, а то и сотни отчетов, которые должны покрывать все запросы бизнеса, остается лишь найти нужную кнопку.
Эта статья о разработке средства визуализации импортов внутри проекта на python, основное назначение которого построить полный граф связи скриптов между собой и с внешними библиотеками, основываясь только на статическом анализе AST дерева. Код не будет выполняться, а доступность библиотек — проверятся. Цель показать, что было задумано, а не как это будет работать в текущем окружении.
Привет, Хабр! Одной из важных функций-модификаторов в DAX является REMOVEFILTERS, он позволяет, например, убрать фильтр для расчета знаменателя в доле. Однако логика REMOVEFILTERS для столбцов может выглядеть неочевидной, например, REMOVEFILTERS только для одного поля, по которому есть условие в FILTER, не влияет на результат DAX запроса. Так, REMOVEFILTERS(customer[customer_id]) не влияет на FILTER в SUMMARIZECOLUMNS вида FILTER(customer, customer[customer_id] > 2) и для сброса фильтра нужен REMOVEFILTERS(customer) по всей таблице. В связи с этим удобно представить принципы работы REMOVEFILTERS более формально, например, в виде ER диаграммы с подписанными связями. Для построения ER диаграммы был выбран Mermaid и генерация кода диаграммы реализована на C#. Интересующимся особенностями REMOVEFILTERS — добро пожаловать под кат :)
Команда Python for Devs подготовила перевод статьи о шести библиотеках Python для визуализации данных. Matplotlib, seaborn, Plotly, Altair, Pygal и Bokeh — у каждой свои сильные и слабые стороны: от академических статичных графиков до интерактивных дашбордов для бизнеса. Выбираем самую подходящую для различных кейсов.
Еще вчера фотография была «доказательством» того, что событие произошло. Сегодня любой школьник может сгенерировать или изменить изображение до неузнаваемости с помощью ИИ. Индустрия цифровой-криминалистики пытается угнаться за технологиями, разрабатывая все новые детекторы фальсификаций. Но что, если подойти к проблеме с другой стороны? Не искать следы конкретного алгоритма генерации, а задать более фундаментальный вопрос: насколько естественны статистические свойства этого изображения?
В этой статье мы не предложим вам волшебную таблетку для детекции фейковых картинок. Это интеллектуальный эксперимент. Возьмем известный математический закон — закон Бенфорда — и попробуем применить его для анализа изображений. Мы реализуем этот метод на чистом JavaScript, чтобы любой желающий мог поэкспериментировать в собственном браузере, и обсудим результаты, философские вопросы и технические подводные камни, которые ждут нас на этом пути.
Допустим существует площадка, где некими специалистами выполняются конкретные операции и вам как руководителю данного процесса хочется оптимизировать расходы. Для помощи в подобных вопросах создана информационная система $metr (Сметр), которая основывается на трех вещах:
Каждый день на нефтегазохимических заводах СИБУРа работают тысячи единиц оборудования. Компрессоры, насосы, турбины — все они крутятся, нагреваются, изнашиваются. И рано или поздно ломаются.
Если выходит из строя ключевой агрегат, завод теряет миллионы рублей в день. Один простой может остановить весь цех, сдвинуть график отгрузок, повлиять на работу нескольких производств.
Раньше мы узнавали о проблемах так: загорается красная лампочка, срабатывает сигнализация, агрегат останавливается. Оператор видит на мониторе: температура подшипника 120 градусов — критично! Производство встает. Вызываем ремонтную бригаду, ищем запчасти, теряем время и деньги.
Что если узнавать о проблемах раньше? Не когда температура подшипника уже 120 градусов, а когда она поднялась с обычных 65 до 75? Тогда можно спланировать ремонт, заказать запчасти, остановить производство согласно плану.
Лучше потратить деньги на год разработки, чем терять гораздо больше на каждой поломке. Особенно если при этом снижается нагрузка на персонал, исчезает аврал, и работа становится предсказуемой.
На imcdb.org энтузиасты уже два десятка лет отмечают автомобили в фильмах: кадры, марки, модели. Верифицируют находки на форуме, спорят о деталях. В итоге появилась крупнейшая база «машин‑актёров» в кино: 1,75 млн страниц с кадрами и описаниями транспорта из фильмов разных стран. Я собрал всё это в один датасет.
За один клик из сводного дашборда — на «дочерний» с уже выставленными фильтрами. Разберём, как в Apache Superset прокидывать выбранные значения через URL-параметр native_filters в формате Rison и собирать ссылку Jinja-макросами.
Всем привет! Я, как и многие здесь, не только разработчик, но и человек, увлеченный циклическими видами спорта. Я обожаю копаться в данных своих тренировок из Strava: анализировать мощность, пульсовые зоны, темп. Но мне всегда не хватало одной вещи — единой, понятной и, главное, прозрачной метрики, которая бы отвечала на простой вопрос: "А насколько я сейчас в хорошей форме?".
В этой статье я расскажу, как устроен этот механизм "под капотом". Мы погрузимся в логику на Python, посмотрим, как она интегрируется в общий анализатор активностей и как результат подается пользователю в простом и понятном виде.
Важный дисклеймер: Весь проект, от идеи до кода, я делаю один в свободное от основной работы время. Он далек от идеала, и я буду очень благодарен за конструктивную критику и свежий взгляд.
Данные для ритейла жизненно необходимы: продажи, промо, возвраты, остатки, оборачиваемость. Классическая схема работы такова: бизнес-подразделение формулирует вопрос → аналитики превращают его в задачу → инженеры делают выгрузки → кто-то собирает отчет → отчет попадает на стол к ответственному лицу → через время появляется ответ.
Проблема в том, что скорость бизнеса и скорость проведения анализа не совпадают.
Руководителю дивизиона, директору магазина или маркетологу часто нужен ответ в моменте, а не через неделю. Но BI-процессы инерционны. Поэтому сегодня нужны другие инструменты, позволяющие получить свежие данные, проанализировать, задать вопрос – и получить не просто диаграмму, но выводы, рекомендации или даже конкретное выполненное действие.
Конструкторы отчетов устарели. В век GPT пользователь хочет общаться с данными.
Что с этим делать?
Закупки в строительстве — это тысячи заявок, десятки поставщиков и миллионы в сметах, что делает их уязвимым процессом для коррупции. Воруют не только на стройплощадке, но и гораздо раньше — на этапе тендеров, выбора и согласования счетов.
Мы в «Синтеке» решили посмотреть на эту проблему через BI-аналитику. Рассказываем, как данные помогают находить узкие места в закупках и почему без прозрачности здесь не обойтись.
Интересным является вопрос о погружении арифметики в n+1-значные логики Лукасевича Łn+1. Какая часть арифметики может быть погружена в Łn+1? Для функции φ(х) = m рассматривается обратная к ней, определяемая соотношением φ –1(m) = {n, φ(n) = m}, где φ(х) – функция Эйлера.
Пример, если φ(n) = 4, то это уравнение имеет ровно четыре решения φ –1(4) = {5, 8, 10, 12}. Гольдбахом (1690 –1764) поставлена проблема о разложении четных чисел ≥ 4 на сумму двух простых. Если это верно, то для каждого числа m найдутся простые числа р и q такие, что φ(р) + φ(q) = 2m.
Эдмунд Ландау в 1912 г. на международном конгрессе математиков в Кембридже заявил, что проблема Гольдбаха недоступна для современного состояния науки. Недоступна она и сейчас. Верифицируемость предположения Гольдбаха установлена до 4∙1014.
Делались попытки найти формулу, с помощью которой вычислялись бы (или порождались) все простые числа. Наилучший результат принадлежит Ю.В. Матиясевичу (1977), который нашел полином из 10 переменных. Асимптотическое распределение простых чисел в НРЧ, доказываемое аналитическими методами, приводится в книге К. Прахара (1967). О первых 50 млн простых чисел статья Д. Цагера (1984).
Можно считать, что впервые на проблему решения подобных уравнений обратил внимание Э. Люка (1842 – 1891). Об этом сказано в книге И.В. Арнольда (1939) «… следуя Люка, сгруппированы числа n с одним и тем же значением функции φ(n) в пределах от 1 до 100, т.е. дана таблица функции обратной по отношению φ(n).
В книге Серпинского (1968) задача №245 «Найти все натуральные числа n≤ 30, для которых φ(n) = d(n), где φ(n) – функция Эйлера, а число d(n) – число натуральных делителей числа n». Рассмотрим только случай n = 30. Делителями числа 30 являются числа 1, 2, 3, 5, 6, 10, 15 и 30, т.е. d(n = 30) = 8. Значит надо решить уравнение φ(30) = 8, где n≤ 30. Или, по-другому, найти значения для обратной функции Эйлера φ –1(8), т.е. определить множество {n, φ (n) = 8} для n≤ 30. Это множество образовано числами {15, 16, 20, 24, 30}. Более того, ни для каких других n >30 φ (n) ≠ 8.
Множество значений φ –1(m) = Ø пусто для всех нечетных значений и многих четных значений m > 1. В первой сотне числа 14, 26, 34, 38, 50, 62, 68, 74, 76, 86, 90, 94 и 98 не являются значениями φ (n).
Человеку свойственно быть в группе, мы более социальные, чем даже можем себе это представить.
Сегодня не нужно ходить по домам и подавать объявления в газеты — достаточно найти чат и написать «Кто тусить?».
Но так ли всё однозначно? Что скрывают эти чаты, какие опасности они несут?
Я исследовал телеграм-сообщества, где можно найти единомышленников, найти друзей и подруг, а может, и любовь. Простые ли это чаты «тус» или нечто большее?
