КУМБА! Эффективное внедрение BI-аналитики

почему-то, чаще всего это попадается в финансовой отчетности)

Всем привет! Сейчас интенсивно готовлюсь к вебинару, поэтому количество публикаций уменьшилось) Предлагаю вам написать вопросы под этим постом: что вам интересно узнать о Loginom? На что-то ответим прям тут, что-то может быть включено в программу этого и будущего вебинаров

А вот и результаты тестирования взаимодействия Loginom и Clickhouse в плане записи данных. Спасибо @vfrolov13 за поддержку) Тестовое табло на 2,7 млн строк, 33 поля. Половина полей - гуиды, есть пара жестких составных ключей из нескольких гуидов. Тестировали стандартный коннектор в Loginom vs выгрузить данные в TSV и загнать TSV в CH. Движок таблицы - MergeTree, для возможности обновлять ее частями после первичного экспорта. Запись велась с 2-х разных серверов на сервер с CH. Сервер №1 от @vfrolov13 показал результаты 1:33 - экспорт через Loginom, 1:13 - полный цикл с tsv (экспорт в файл, запись файла). При этом параллельных инсертов не делали. Сервер №2 (мой) показал результаты: 4:15 секунд - экспорт через Loginom, 2:59 - полный цикл с tsv. Что сразу навело на мысли о недостаточной широте канала между серверами) Однако, если активировать в настройках коннектора CH в Loginom опцию "Сжатие данных LZ4", то прямой экспорт сразу занимает 2:38, vs 4:15 без этой опции! И это по-прежнему без расширения канала, а также без параллельных инсертов. Главный вывод: Коннектор к Clickhouse в Loginom из коробки работает с хорошей производительностью, при наличии нормального канала между серверами. При этом, остается также достаточно возможностей ускорения записей/чтения за счет запараллеливания запросов, что в Loginom делается на раз-два. Также выяснилась проблемка при работе с TSV: при экспорте тип данных DateTime выгружается как дата, если время равно 00:00:00, и как таймстемп, если время не нулевое. Импорту CH такое не нравится, потому что он в одном поле ждет или только Date, или только Time, или только DateTime. Но на этот счет уже сейчас есть обходы.

На схеме - исходная структура данных, которую будем адаптировать в АХД. Программа примерно такая: День 1: Данные из ERP 1) Краткое описание единого стандарта для моделей данных. 2) Аудит стандартов библиотекой BI2BUSINESS 3) Формирование справочника мета-данных компонентами BI2BUSINESS 4) Работа с прямыми запросами к БД. Работа с большими данными, которые нельзя пересохранить в хранилище, как частью единого аналитического ландшафта. 5) Генерация прогноза продаж. Запараллеливание запросов к базе данных, параллельные итерации циклов. 6) Многовариантные справочники. Когда один справочник может подключаться по разным ключевым полям. 7) Создание единых ключей 8) Восстановление целостности связей; 9) Создание компонента для параметризированной загрузки напрямую из БД. 10) Сборка модели данных по рекомендациям из компонента BI2BUSINESS; 11) Демонстрация модели в Excel (чтобы была картинка без привязки к вендору) День 2: Данные из CRM 1) Сложная таблица фактов: когда в таблице несколько полей дат, которые надо показывать на одной оси, и считать показатели с условиями. 2) Разворачивание сводной таблицы в плоскую; 3) Интеграция данных между CRM и ERP; 4) Аудит целостности связей и обогащение связей с помощью компонентов BI2BUSINESS 5) Сборка модели данных, которая объединяет данные из CRM и ERP. Теперь можно в разрезе клиентов ERP посмотреть, например, действия по ним в CRM, 6) Визуализация модели в Excel. 7) Общение и обратная связь.

Всем привет! Я тут пишу о всяком прогрессе в инструментах бизнес-аналитики. Но наверняка вам хочется посмотреть на это вживую) Поэтому совместно с Loginom мы запланировали на 7 и 8 сентября вебинары по теме "Построение универсального аналитического хранилища". Цель универсального АХД - дать свободу визуализации данных в любых BI-системах, стандартизировать аналитическое самообслуживание, и упростить многопользовательское развитие аналитического ландшафта. https://loginom.ru/single-data-warehouse-form?utm_source=tg&utm_medium=post_cumba Я уже проводил несколько вебинаров с Loginom по схожей тематике: подготовка данных для BI-систем, их визуализация в разных BI. В чем отличие новых вебинаров? Предыдущие мероприятия скорее были чем-то вроде "proof of concept". Мы использовали максимально базовый функицонал систем, строили схему работы интуитивно. Важно было показать саму возможность строить аналитические системы. И доказать ее в том числе самому себе. Теперь, когда за плечами есть наработанные практики и выполненные проекты, я хочу показать вам процесс реального проектного производства с Loginom. В сферах создания аналитических хранилищ и внедрения самообслуживания. Мы не будем фокусироваться на базовых вещах. Считаем, что вы уже знаете что в Loginom можно джойнить таблички и создавать новые поля) И не будем делать утомляющих настроек в прямом эфире. Вместо этого мы вопросизведем процесс создания проекта с нуля. Так, как это происходит в жизни. Когда у нас нет заранее всей картины. Когда мы не знаем, как изменится структура данных с новым источником. Когда нужно минимизировать риски при передаче развития проекта в другие руки. Эта серия вебинаров будет про ETL, подготовку данных, и сборку моделей. Она послужит открывающей частью к следующей серии: визуализация данных в каждом значимом BI-инструменте на российском IT-ландшафте.

Тем временем, мой подопечный в челлендже "BI-архитектор с нуля за 2 месяца" продолжает ассимилировать структуру данных, которая была создана до него. Синие точки - таблицы, интегрированные в АХД его силами. Т.е. 7 из 15 таблиц здесь уже делал не я. Но они совместимы со всеми предыдущими наработками. Конечно, лозунг "BI-архитектор за 2 месяца" выглядит шапкозакидательским, и существует еще огромное количество знаний, которые нужно впитать, чтобы стать действительно мощным специалистом. Но на мой взгляд, это очень хорошая демонстрация того, как можно организовать рабочий процесс и систему разработки, которые позволяют сотруднику сразу начать применять подходы, на наработку которых в обычных условиях требуется не один год. При том с минимальным контролем и стоянием над душой. Ну а если весь справочник функций системы пока не отскакивает от зубов - всегда есть мануалы, сообщества и наставники.

Кликхаус выбрал по двум причинам: 1) Бесплатно 2) Колоночный формат БД оптимизирует место, занимаемое данными (смотрел тут, одна таблица в LGD занимает 350 мегабайт, а в MS SQL - 2,5 гигабайт. Для аналитических таблиц оптимизированное хранение критично, т.к. они таблицы сильно денормализованные. В Кликхаусе пока эту таблицу на взвешивал, но принцип должен быть тот же.) 3) НЕТ ОГРАНИЧЕНИЯ НА ДЛИНУ ТЕКСТОВОЙ СТРОКИ!!! Как я устал при сохранении таблицы задавать длину текстового поля. А потом пересоздавать его, потому что внезапно составной ключ стал длиннее и теперь не влезает в прежние габариты. Что касается СУБД, если вам прям тяжко курить мануалы или аутсорсить, то тут можно очень легко развернуть ее в Яндекс.Облаке. Этот процесс я даже уже показывал в вебинаре с Loginom+Yandex Datalens. А что касается менеджмента таблиц. В Loginom можно создать таблицу при первичном экспорте - задать поля, типы данных. Но если вам потребуется изменить состав полей изменяемой таблицы - тут только идти в клиент СУБД, и писать там ALTER TABLE... Ну или сносить таблицу и пересоздавать с нуля. Я поставил себе задачу довести работу с экспортом в БД по удобству до уровня экспорта в файл, и это вполне удалось. Был создан компонент, который при поступлении в него мета-данных из другого компонента, выполняет следующее: 1. Создает таблицу, если такой таблицы нет в БД; 2. Опционально, удаляет поля, которых нет в мета-данных, но есть в таблице БД; 3. Добавляет новые поля в БД, если они появились в выгрузке; 4. Меняет типы данных у полей, если мета-данные не совпадают с БД. Таким образом, в БД всегда таблица, готовая к приему актуальных данных из Loginom, и не надо скакать между Loginom и клиентом СУБД. Ну и самое главное. Хранение в БД данных, синхронизированных с мета-данными, открывает путь к самой главной автоматизации - генерации моделей данных. Тех самых, которые УМБА в слове КУМБА)

Сегодня закрыл один из главных головняков последних дней - удобное формирование аналитического хранилища на базе Loginom + Clickhouse. В чем был затык? Раньше как базовый вариант аналитического хранилища в Loginom полагался на LGD-файлы. Это примерно то же самое, что и QVD в Qlik - хранение таблицы в одном файле в оптимизированном формате для сокращения занимаемого места. И с быстрой загрузкой в Loginom. Плюсы файлов - простота и удобство. Файл удобно перезаписывать: если добавляются/убираются поля, меняются типы данных (а это частенько происходит во время разработки). Минусы файлов: - данные из файла загружаются всегда целиком, для партиционной загрузки нужно дробить таблицу на множество файлов. - при дроблении таблицы на множество файлов теряется простота управления - нужно поддерживать одинаковый набор полей во всех файлах - данные из LGD-файлов доступны только внутри Loginom Очевидно, данные нужно выгружать в БД, но и тут есть нюансы: Плюсы: - единая структура таблицы - возможность фрагментарной перезаписи файлов - возможность ограничения загружаемых данных через where Минусы: - Нужно поднять СУБД - Менеджмент таблиц сложнее.

Отличный способ закрепления навыков - работа по чек-листам. Очень поднимает предсказуемость финального результата, а также автономность подопечных. Кроме того, это отличный способ сохранения накопленного опыта. К какой структуре чек-листов я пришел: 1. Отдельно делаем глоссарий основных понятий. Например, термин Аналитическое хранилище Qlik содержит описание что это такое, где находится, как подключиться и т.д. И мы не повторяем это в пунктах чек-листа, добиваясь краткости; 2. В начале каждого чек-листа кратко пишем, зачем он нужен. Иначе сами не вспомните через пару недель; 3. Чек-лист содержит ссылки на термины и развернутые инструкции, там, где это необходимо. Кстати, таки путем можно использовать один набор чек-листов для множества проектов ;); 4. Чек-лист должен помещаться на один лист А4. Ничего не сравнится в удобстве с распечатанным листом, на котором еще и можно что-то черкать. Если не помещается - разбиваем на "суб-процедуры", чтобы помещалось. Будет хорошо, если результатом "суб-процедуры" будет полноценно выполненный этап, а не просто перенос действий на следующий лист; Составляете чек-листы для себя или других сотрудников? Поделитесь вашим опытом в комментариях.

Интересный факт. Сейчас занимаюсь разработкой библиотеки компонентов для ETL и формирования аналитического хранилища на Loginom. И честно говоря, за счет работы с этой Low-code платформой я улучшил понимание программирования намного лучше, чем за годы написания скриптов под Qlik. Очень сильно прокачивается правильное построение архитектуры решений, прежде всего. Потому что со сценарием в стиле "спагетти-кодинг" работать в визуальном проектировании просто невозможно :) Честно говоря, всем кто хочет связать свою жизнь с работой с анализом данных, рекомендую начинать свой путь с Loginom. Потому что: 1) Быстрее выйдете на практический результат; 2) Быстрее сформируете представление о эффективной организации сложных систем со множеством модулей. 3) Пропитаетесь философией переиспользования. Что сэкономит много времени в проектах и вам, и вашим заказчикам.

Жизненно Опасные Проекты Аналитики №3: расчет фин. показателей на стороне BI-системы. Иногда BI-разработчиков посещает грандиозная идей: а не сделать и нам расчет валовой прибыли на стороне ETL-инструмента? Ведь что может пойти не так при портировании отчета, который формируется запросом на 4 экрана в 1С? Буду краток в этот раз. Просто не тратьте время. В лучшем случае, получите отчет такой же как в источнике. И бесплатный бонус - необходимость админить логику формирования показателя на своей стороне. В худшем случае, данные не сойдутся. И вы получите недели поиска ошибок/виноватых/истины... Но поможет ли это компании работать лучше? Далеко не факт. В конце концов, если есть сомнения в правильности логики работы отчета в условном 1С, нужно разбирать этот отчет на стороне 1С, а не воссоздавать с нуля в других инструментах. Если в источнике есть сложно рассчитываемые показатели, найдите способ получать их в готовом виде. Да хоть бы в файловых выгрузках. Лучше иметь простую загрузку из набора файлов. Чем получать данные из БД через написание сверх-сложного запроса. P.s. Под напором опыта Иванова Петра @blackskif добавлю уточнение. Важно понимать, что пересборка логики на стороне BI запросто выливается в отдельный проект. И что заказчик хочет от вас именно этого. А не, например, видеть то что он видит в 1с + другие источники.

Важнейшей функцией ETL-инструмента является возможность создания мета-данных. Если кто не знает, мета-данные - это таблицы с описанием данных. Когда таблиц в аналитическом хранилище становится слишком много, полагаться на ручную документацию и построение схем становится бесполезно. У меня как-то повелось, что генерацию мета-данных я пишу сам, используя встроенные возможности аналитических платформ. Совершенствовать сбор меты можно бесконечно, поэтому опишу основу, которую формирую в обязательном порядке: - Наименование таблицы - Описание таблицы - Наименование поля - Описание поля - Роль поля (мера/измерение/ключ) - Превью значений поля (иногда проще посмотреть что хранится в поле без загрузки данных. Отлично дополняет описания) - Первичный ключ таблицы Можете посмотреть расширенный пример в приложенном файле. С помощью мета-данных можно: 1. Построит интерактивную документацию и схему данных (дашборд про данные); 2. Контролировать соблюдение стандартов подготовки данных; 3. Автоматизировать работу с данными аналитического хранилища (построение моделей, ad-hoc запросы) Как вы формируете мета-данные в своих проектах, и формируете ли вообще? Что интересного вы делали с мета-данными?

Завершаем пятницу на триумфальной ноте) Мой подопечный выполнил первую по-настоящем архитектурную задачу: уложил новый массив данных в единую схемы данных по КУМБА А значит, все вычисления по новым данным будут совместимы со всеми отчетами, которые разрабатывались за 2 года до него. И всеми будущими отчетами, о которых мы еще даже не знаем.

Пятничная мысль. Считаю очень важным навыком для ИТ-специалиста, и бизнес-аналитика в частности, избегать ситуаций в стиле "сэкономил сто тысяч, а получил проблем на миллион". Эта мысль - не про специализированные ИТ-компании, а про торгово-производственные бизнесы. Прежде всего она относится, конечно, к самопальным разработкам функционала, который можно приобрести на рынке. При этом, у любителя самопальщины возникает четкое убеждение, что напрогать самому или заказать у фрилансера - это проще и надежнее, чем взять решение, которое разрабатывала команда на протяжении нескольких лет, и обкатала в десятках проектов. Мое глубокое убеждение - каждый раз, когда ИТшник укатывается в самописный кастом вместо готового решения - это поражение. Поражение для бизнеса, потому что он получает инфраструктуру, которую может поддерживать целый 1 специалист в мире (ее автор). И поражение для ИТшника, который вместо адаптации процессов под готовые инструменты, привлечение лучшей отраслевой экспертизы и управления финансовыми потоками, занимается копошением в коде. Кстати, на чем больше всего горят такие внутренние разработки - невозможность адекватно спрогнозировать ресурсы на поддержку решения. Откуда-то появляется ощущение, что "я напишу 1 раз, и оно будет работать всегда, и никогда не сломается". Конечно же сломается. Из-за ошибок в коде. Из-за ошибок в API систем-источников. Из-за не протестированных сценариев использования. Итого: Если вы ИТ-спец/аналитик в СМБ компании, стремитесь максимум аутсорсить и интегрировать решения, а также координировать команды. Это поможет вам повысить профессионализм, и улучшит карьерные перспективы. Если вы бизнес-заказчик и хотите купить классную функциональность, но ваш ИТ-шник шепчет на ухо: "не покупай, я сам напрогаю, работы на неделю", не верьте ему :)

Жизненно Опасные Проекты Аналитики. Часть 2. Дикие калькуляторы. У большинства компаний есть различные калькуляторы в таблицах. Это финмодели, расчеты заказов на закупки, прогнозы, ну и всякое другое. Отличительной особенностью таких калькуляторов являются 3 вещи: 1) Они требуют объемного ввода данных с ручными корректировками; 2) Часто, они дорабатываются пользователем прямо на ходу под каждую итерацию моделирования; 3) Внутри заложено множество неочевидных костылей, о которых никто сразу не вспоминает. Видя, как BI-системы выводят картины по сложным моделям данных, заказчику приходит в голову гениальная идея - портировать калькулятор на BI. Разработчик тоже может поддаться этому порыву, ведь на его стороне - мощные скрипты, low-code программирование и все такое. Как жаль, что такой проект может запросто зайти в тупик. ❌ У вас может не получиться дать пользователю удобное обновление результатов расчетов - придется запускать ETL-процесс каждый раз, вместо обновления данных на лету; ❌ Пока вы делаете то, на что договорились, заказчик перепилил механику расчетов, и ваше решение больше не актуально; ❌ Приключение "на 20 минут, вошел и вышел", превращается в эпопею на часы и дни, потому что заказчик достает ранее неозвученные особенности функционала, как шулер достает тузы из рукава.=; ❌ Теперь все изменения в этот механизм нужно вносить вам, т.к. заказчик в BI-разработке не разбирается; Как быть, когда вам предлагают сделать что-то подобное? Чтобы не попасть в капкан и не обмануть ожидания заказчика, следуйте правилу: Если речь идет не о разработке инструмента с нуля, браться за проект не надо. Если же что-то делается с нуля, то убедитесь, что заказчику будет нормально работать в условиях, когда данные обновляются не мгновенно. Если вас просят перенести расчетную часть уже имеющихся калькуляторов в BI, то есть смысл отказаться от такой работы (и отметить, что пора бы уже настроить несчастный автозаказ в 1С). Но чтобы не отказывать заказчику и не оставлять его ни с чем, вы можете предложить: ✅ Сделать на стороне BI предподготовку данных для калькулятора. Чтобы заказчик выгружал одно готовое полотно данных для калькулятора, а не ВПРил 10 таблиц; ✅ Освоить low-code аналитическую систему вроде Loginom, и самостоятельно модернизировать свой калькулятор; ✅ Визуализировать данные из калькулятора в BI в единой модели данных. Пишите в комментариях, на какие калькуляторные грабли вы наступали)