Привет, Хабр! Меня зовут Иван Вахмянин, я один из сооснователей компании «Визиология».
Мы развиваем и развиваем одноименную аналитическую платформу и теперь поделимся с вами своим опытом, открытиями и интересными историями.
Это наш первый пост, и начнем мы с откровенного рассказа о том, как мы создавали компанию и саму корпоративную BI-платформу Visiology — без сокращений, со взлетами и падениями.
Если вас интересуют реалии пути от стартапа до зрелой софтверной компании или тема Business Intelligence в целом, добро пожаловать под кат! 
Далее следует долгая история, полная личных впечатлений.
Но для тех, кто раздумывает, подписываться ли на наш блог – небольшой дисклеймер: в корпоративном блоге мы будем писать о том, в чем разбираемся: о технологиях анализа данных, о наших разработках и проектах, о том, как мы работаем с партнерами, и в общие сведения о бизнесе российской компании-разработчика программного обеспечения.
Теперь вернемся к истории.
Все началось еще в 2014 году.
Я тогда был руководителем центра разработки в системном интеграторе Polymedia, у нас была сильная R&D команда из 23 человек.
Мы только что завершили несколько серьезных проектов, и нам нужно было решить, куда двигаться дальше.
Самым простым и понятным путем разработки могла бы быть стандартная модель внедрения сервиса (смотрим проблему заказчика, выбираем готовые платформы, создаем решение), но проблема была в том, что это именно то, чего мы не хотели делать.
Хоть мы и были частью интегратора, у команды уже был хороший опыт разработки продуктов.
К тому времени мы уже запустили два продукта: Flipbox — оболочку для больших интерактивных дисплеев в переговорных комнатах и Polywall — программное обеспечение для управления видеостенами в диспетчерских и ситуационных центрах.
Эти продукты были действительно высокого качества.
Например, Polywall до сих пор продается по всему миру и является одним из лучших в своей небольшой нише.
Но у созданных решений был и недостаток – они быстро достигали потолка в своих специализированных нишах.
Поэтому следующим шагом, который мы хотели запустить, было что-то действительно масштабное.
С другой стороны, мы уже выполнили ряд проектов по внедрению аналитики, поэтому опыт работы в BI (особенно в ситуационных центрах региональных органов власти) у нас тоже был.
Итак, пазл сам собой встал на свои места, и мы решили, что будем разрабатывать собственную BI-платформу.
Так начался путь новой компании — Visiology, которая изначально создавалась как чисто продуктовая компания, то есть поставщик программного обеспечения.
2015 – Прототипирование и принятие архитектурных решений
Первый работающий прототип мы собрали очень быстро, буквально за три месяца.Конечно, это было что-то вроде Франкенштейна, но мы тестировали на нем наши архитектурные решения, и в нем действительно были интересные подходы.
В качестве основного технологического стека мы выбрали C# .
NET, поскольку наша команда уже имела серьезный опыт разработки на этой платформе.
Здесь нам, конечно, очень повезло, что позже появился .
NET Core, с помощью которого мы быстро портировали платформу на Linux, когда это стало необходимо.
Для ядра OLAP мы взяли (как и подавляющее большинство тех, кто начинает разрабатывать собственную BI-платформу) открытое решение Pentaho Mondrian, а данные сохранили в PostgreSQL. Простое, очевидное и, как показал впоследствии опыт, совершенно неправильное решение.
Поучительная история оказалась с библиотекой визуальных компонентов Syncfusion, которую мы взяли для визуализации данных и некоторых UI-компонентов, таких как таблицы, Property Grid и т.д. Реализовали мы ее довольно быстро (к нашей чести, техническая поддержка у них высокая).
-качество).
Но потом все пошло не так — переговоры по лицензированию пошли где-то совсем не так, также возникло большое количество технических проблем, и мы решили отказаться от Syncfusion. Однако оказалось, что на этом этапе вырезать его из изделия гораздо сложнее, и это потребует больше усилий, чем добавление.
В результате мы удалили последнюю зависимость от Syncfusion спустя почти два года, и все это время нам приходилось платить за лицензию.
С тех пор мы очень внимательно относимся ко всем зависимостям, которые добавляем в продукт, как платные, так и с открытым исходным кодом.
Самым нестандартным решением с нашей стороны стало использование языка R для скриптов и расширение бизнес-логики системы.
Идея заключалась в том, что R по своей сути очень хорош в обработке данных, а с такими расширениями, как dplyr, он также показывает хорошую производительность.
Предполагалось, что преобразования данных аналитик будет писать на R, и поэтому первая версия дизайнера дашборда представляла собой что-то вроде гибрида собственно инструмента верстки и IDE для R. Технически мы развили ядро R и добавили к нему интерфейсы через который платформа могла отправлять на исполнение код скрипта (благо у нас были и C++-разработчики).
Мне как человеку немного жаль, что нам пришлось в итоге отказаться от этого и выбросить многое из того, что мы сделали, но со временем нам пришлось реализовать многие функции преобразования данных непосредственно в системе, поэтому что аналитику приходилось писать как можно меньше кода, а для случаев, когда скрипты все равно были необходимы, Python оказался гораздо более востребованным.
Так или иначе, в июле 2015 года мы показали первый прототип (и он даже заработал).
Вдохновленные успехом, мы утвердили архитектурные решения и двинулись дальше.
Но тогда мы понятия не имели, насколько недооценён тот путь, который нам ещё предстояло пройти.
2016 – Первая версия, первые внедрения, первые разочарования
В марте 2016 года мы официально представили первую версию платформы и сразу же приступили к предпродажной подготовке и внедрению.Понятно, что нашими клиентами в то время были компании, которых не очень интересовали характеристики Визиологии как инструмента; для них был важен конечный результат — информационные панели, которые они могли использовать для улучшения своих процессов.
Поэтому работу над платформой в основном проводили наши коллеги из группы внедрения Polymedia; они же взяли на себя основную тяжесть проблем, связанных с «сыростью» продукта.
В конце спринтов температура на внутренних демках иногда поднималась настолько высоко, что проектор выключался из-за перегрева.
Реализаторы справедливо жаловались на неудобные моменты и неприятные баги, и мы смогли эффективно устранить лишь малую часть их замечаний, ведь в архитектуре продукта уже назревали масштабные проблемы.
- Производительность и OLAP в памяти
Как я уже говорил, ядром системы был движок Mondrian ROLAP. Если совсем упростить вопрос, то это был транслятор многомерных OLAP-запросов в обычные SQL-запросы, которые можно выполнять на любой СУБД (при условии, что данные в ней помещены в определенный формат — так называемую звездную схему).
Проблема заключалась в том, что как только объем данных в таблице фактов достигал хотя бы миллионов строк, аналитические запросы начинали выполняться обычными СУБД с дисковым хранилищем строк и было совсем не весело (минуты на обновление дашборда с таргетом метрика – менее 5 секунд).
Пока мы задавались вопросом, что с этим делать, один из наших ведущих разработчиков C++ предложил создать прототип своего механизма In-Memory на основе столбцов.
И даже этот прототип, подготовленный за пару недель, на синтетических тестах дал прирост скорости более чем на порядок по сравнению с тем, чего нам удалось добиться от комбинации Mondrian + PostgreSQL. Мы оказались перед трудным выбором.
С одной стороны, было ясно, что инвестиции в развитие нашего In-Memory движка будут значительными.
С другой стороны, на рынке просто не было открытых вариантов или решений с доступным лицензированием.
Мы посмотрели и даже протестировали ClickHouse, выпущенный Яндексом ровно в тот же период времени — он был максимально близок к тому, что нужно, но все равно не подходил (почему тема достойна отдельной статьи).
Поэтому с болью в сердце мы все же решили написать свой движок, который назвали ViQube. Кстати, именно он сейчас дает нам серьезное конкурентное преимущество.
Кстати, с ClickHouse мы тоже интегрировались, но уже в 2020 году, и наши клиенты теперь могут использовать его совместно с ViQube в проектах, где объем сырых данных измеряется терабайтами.
Как мы и думали, разработка ViQube была непростой прогулкой — ни технически (где нам пришлось уходить чуть ли не в ассемблер, чтобы правильно использовать векторные регистры ЦП), ни организационно.
В какой-то момент главный разработчик ViQube решил эмигрировать в Новую Зеландию, и нам пришлось по сути воссоздавать бэкенд-команду.
А это, прямо скажем, рискованное предприятие.
К счастью, мы заранее обсудили с ним эту возможность, и у нас было время подготовиться, поэтому реорганизация прошла успешно.
- Формы ввода
Мы столкнулись с тем, что подавляющее большинство клиентов не имеют 100% хорошо оцифрованных данных, которые можно вытащить из учетной системы и проанализировать.
Одна часть всегда живет в файлах Excel разной степени повреждения, а другая полностью отсутствует. Опыт показал, что автоматизация загрузки файлов Excel, заполненных вручную, всегда заканчивается плохо.
Решение этой проблемы во многих BI-платформах реализовано через модуль веб-форм для автоматизации ввода данных.
В нем можно создать модель данных и формы, с помощью которых пользователи будут вводить данные в систему по некоторым регламентам.
Но это для сильного упрощения темы.
На самом деле модули корпоративных веб-форм — это, по сути, BPM-платформы, позволяющие автоматизировать довольно сложные процессы, например, планирование и составление бюджета.
Наиболее известные примеры — IBM Cognos TM1, Oracle Hyperion и Anaplan. 
Некоторое время мы пытались найти партнерское решение, которое можно было бы легко интегрировать и удовлетворить потребности.
Но ни среди российской, ни среди импортной продукции мы не нашли такого решения с разумной схемой лицензирования.
Но так как в большинстве наших проектов без модуля ввода данных делать было просто нечего, мы решили запустить собственную разработку.
Было очевидно, что такой модуль — это продукт в продукте, и для него нужна отдельная команда.
Где я могу получить это? Тут помог случай, и к нам обратились люди из Университета Иннополис с предложением открыть подразделение в новом городе Иннополисе (Республика Татарстан, если кто не знает).
На тот момент в Иннополисе был построен лишь университет и несколько жилых домов, а между ними было огромное море грязи.
Не могу сказать, что это было экономически и стратегически обоснованное решение, но мы решили попробовать.
Мы, наверное, считали, что сильный ИТ-вуз может стать источником сильных кадров.
После быстрого сбора команды началась разработка.
В общем, тема открытия и развития офиса в Иннополисе тоже достойна отдельного поста, и мы к ней вернемся позже.
Но короче, я очень рад, что мы тогда приняли такое решение.
Прежде всего потому, что в этой конторе удалось собрать по-настоящему суперпрофессиональную команду разработчиков.
Что ж, сам город с тех пор преобразился, и мне нравится проводить там часть своего времени, хотя в последний год мне удавалось выбираться туда и работать реже, чем хотелось бы.
- ETL (Extract-Transform-Load), инструменты загрузки данных
Для нас таким трудным решением стал отказ от разработки собственного ETL-инструмента (Extract-Transform-Load, загрузка и преобразование данных).
На тот момент мы уже четко понимали, что нам не хватает ресурсов на действительно качественный крутой ETL, и решили, что нет лучше плохого.
Конечно, мы включили в платформу базовые инструменты для загрузки из CSV, файлов Excel и различных СУБД через JDBC (SQL), но для всех сложных преобразований мы рекомендуем использовать сторонние инструменты, такие как Apache Airflow, Pentaho Data Integration или Loginom. Сейчас, спустя более 3 лет, я абсолютно уверен в правильности этого решения, а также в том, что для развития бизнеса и продукта отказ от чего-то (функций, идей, партнеров и даже клиентов) играет важную роль.
решающая роль.
На мой взгляд, в этом фокус, в этом стратегия.
Правда, недавно мы выпустили ViXtract, бесплатный ETL-инструмент с открытым исходным кодом, основанный на Python и Jupyter, но это совсем другая история, да и время тогда было другое.
2017 – Система продаж, отдел Data Science.
Параллельно с решением технических задач мы активно строили систему продаж.Трудно сказать, что из этого было сложнее.
B2B-продажи выглядят великолепно только снаружи — большие бюджеты, масштабные задачи, возможность личного общения с теми, кто принимает решения.
Это все так, но B2B-продажи также подразумевают циклы транзакций от 6 месяцев и более (и от 1 года, если стоимость решения требует включения его в годовой бюджет), политику и что тут скрывать, не всегда мотивированные пользователи .
Самая важная история, которую мы узнали о продажах B2B, заключается в том, что вы продаете не компаниям, а людям.
А на решение совершить покупку в B2B влияют несколько (а иногда и несколько десятков) человек.
Поэтому ваш продукт должен иметь не просто ценностное предложение, а несколько предложений — по одному для каждой группы заинтересованных людей в компании.
В нашем случае таких групп три:
- Представители бизнеса (высшее руководство, руководители, иногда акционеры).
Для этих людей важны выгоды, которые их бизнес получит от внедрения – снижение затрат, увеличение выручки, повышение стоимости компании в глазах инвесторов.
И, по сути, им не важно, на каком инструменте это будет сделано, если только это не потребует сверхожиданных затрат.
- Аналитики (те, кто непосредственно работает с BI, исследует данные, готовит дашборды и отчеты).
Для аналитиков самое главное — удобство и функциональность инструмента — насколько он экономит их силы и время.
Аналитику важно работать с продуктом, чтобы он чувствовал себя уверенно и был убежден, что сможет эффективно обрабатывать бизнес-запросы в вашей системе.
- ИТ (CIO, ИТ-специалисты).
Для ИТ важны две основные метрики — надежность решения (ведь за непрерывную работу сервисов платят деньги), а также низкий уровень нагрузки на службу поддержки и внутреннюю команду автоматизации.
Идеальный BI для ИТ – в котором аналитики могут полностью выполнять всю свою работу самостоятельно, привлекая ИТ только для развертывания инфраструктуры и текущего обслуживания системы.
Осознав свою ошибку, мы расширили метод persona, который раньше использовали только для работы с требованиями.
Когда в маркетинге и продажах появились персоны, нам стало намного проще вести переговоры с нашими клиентами, ведь мы теперь говорили на их языке.
- Услуги по обработке и анализу данных
Но я уверен, что нельзя просто пойти дальше и «сделать инновацию».
Любая новая идея — это большой риск, и чисто статистически она скорее потерпит неудачу, чем улетит. Поэтому лучше построить процесс, где параллельно с основным бизнесом вы пробуете новые идеи в надежде, что рано или поздно найдете ту, которая запустит новый виток развития.
Одной из новых идей стал запуск команды Data Science. По первоначальному плану мы должны были предоставлять нашим клиентам услуги по разработке сложных математических моделей, в том числе с использованием машинного обучения.
Мы надеялись, что на таких услугах можно будет хорошо заработать, ведь на тот момент конкуренция в этой сфере была еще не так велика.
Также ожидалось, что услуги Data Science помогут продать саму платформу Visiology. 
Но этот путь оказался трудным.
Первая проблема не заставила себя долго ждать — как нанять компетентного Data Scientist, если у вас нет компетенций, чтобы провести с ним собеседование? Нанимать через кадровое агентство? По знакомству? Я не думаю, что это хорошая идея даже сейчас, а тем более тогда.
Пришлось смахнуть пыль со своего университетского математического образования (К-28 МИФИ, привет!) и самому углубиться в тему, одновременно в очередной раз испытывая гнев и депрессию, сравнивая российские и зарубежные учебники по математической статистике и линейной алгебре.
Суперспециалистом в Data Science я, конечно, не стал, но смог разработать процесс отбора кандидатов на позиции Data Science, который не дал ни одного сбоя.
Ключевым критерием было реальное понимание математических основ, а не просто заучивание поверхностных определений и опыт настройки гиперпараметров в скачанных библиотеках.
Созданная команда реализовала ряд проектов, самый крупный из них — для «Сибура».
Там ребята оптимизировали процесс синтеза оксида этилена: разработали сложнейшую модель, сочетающую методы машинного обучения с физическим и химическим моделированием.
Этот подход сейчас в принципе стал основным в задачах продвинутой аналитики в промышленности, а тогда нам пришлось его изобретать с нуля, но мы это сделали! Однако после ряда непростых задач мы оглянулись и поняли, что эта тема не для нас.
Во-первых, сама история оказалась абсолютно не масштабируемой; найти в нем возможность для разработки продукта было крайне сложно.
Во-вторых, каждый раз мы делали чуть ли не исследовательскую работу — а заказчик обычно не очень-то готов брать на себя высокие риски.
В-третьих, большинство крупных компаний пошли по пути создания собственных отделов Data Science, после чего сразу потеряли интерес к работе с внешними подрядчиками.
В целом я не хочу сказать, что услуги заказной разработки математических моделей вообще не востребованы, но мы решили отказаться от этого направления.
Я бы сказал, что такой профиль лучше подходит для расширения портфеля услуг консалтинговой компании.
После закрытия направления усилия команды Data Science, которая не только сработала вместе, но и накопила большой опыт, были направлены на разработку продукта.
Результатом этих усилий после серии экспериментов стал ViTalk — виртуальный аналитик, понимающий запросы на естественном языке (например, «покажите мне три самые прибыльные категории продуктов на прошлой неделе»).
Сейчас оно успешно развивается (например, ViTalk недавно перешел в Telegram и научился сам подбирать подходящие визуализации).
Кстати, с ним можно свободно общаться по адресу общедоступная демо-версия .
Крупные клиенты и макеты без продаж
К 2018 году у Visiology уже был стабильный продукт и серьезные проекты.Мы серьезно отнеслись к маркетингу и приобрели опыт работы с крупными компаниями и государственными заказчиками.
Самый главный урок, который мы усвоили: не каждая предпродажа с макетом приближает нас к продаже (но каждая предпродажа съедает ресурсы).
Иногда, к сожалению, человеку в компании модель нужна просто для того, чтобы показать какую-то свою деятельность.
Мы не раз на этом обжигались, проводя предпродажи для компаний совершенно разного размера.
В результате стало понятно, что делать макет имеет смысл только тогда, когда клиент тоже готов в него вложиться – временем своих специалистов, вниманием руководства и, конечно же, деньгами.
В крупных компаниях такое прототипирование/апробация — это, по сути, небольшой проект с функциональным и нагрузочным тестированием.
Участие в таком тестировании требует ресурсов и ничего не гарантирует, но без этого невозможно продать крупной компании.
Рисунок 1. Пример отчета о тестировании в крупной компании
2018 – Импортозамещение, переход на Linux
Прошло время, и импортозамещение стало новой реальностью.Серверную часть мы полностью перенесли на Docker и Linux, причем сделать это нам удалось относительно безболезненно, благодаря использованию .
NET Core. Хотя сказать, что это вообще не требовало никаких усилий, тоже нельзя.
На момент перехода .
NET Core находился еще в довольно незрелом состоянии, и не все библиотеки сразу полностью поддерживались в нем.
Некоторые из них пришлось изменить из-за отсутствия поддержки, а для некоторых мы сами написали исправления и отправили пиар разработчикам.
Были проблемы и внутри самого .
NET, например, один и тот же сериализатор/десериализатор в .
NET Full и .
NET Core работал по-разному в сложных случаях, что нарушало совместимость между нашим десктопным приложением на .
NET Full и сервером на .
NET Core. Мне пришлось очень быстро повышать свою компетенцию в Linux, Docker и Nginx, потому что весь мой опыт раньше был больше связан с IIS. В целом разработка шла достаточно бодро, но в то же время росло понимание, что нужно на чем-то сосредоточиться.
Было очевидно, что конкурировать с BI-продуктами из топовых рейтингов Gartner по всей BI-сфере с нашими ресурсами просто нереально.
Мы начали рассматривать разные варианты, выбирать специализацию, максимально используя тот опыт и продукт, который у нас уже был.
В топ вариантов входило выход на зарубежный рынок с готовым решением для конкретной отрасли и разработка «отечественного ПО» в тренде.
Тема преференций для российского программного обеспечения возникла еще в 2015 году после подписания постановления Правительства РФ № 1236 «Об установлении запрета на допуск программного обеспечения иностранного происхождения для целей закупок для государственных и муниципальных нужд».
выглядело очень заманчиво – «и никакого твоего итальянского сыра не будет!» (С)Веселый Молочник.
" На самом деле все эти законодательные ограничения носили скорее мягкий рекомендательный характер (по крайней мере в нашей отрасли) и до конца 2018 года мы их вообще не ощущали.
Да и сейчас, по сути, если госкомпания очень хочет закупить западное ПО, у нее есть возможность это сделать.
Однако после подписания Директивы Силуанова В конце 2018 года крупные компании были готовы, как минимум, обратить свой взор в сторону российских BI-решений, и на это повлияло не только «закручивание гаек импортозамещения», но и вполне прагматичные причины:
- Постепенный уход всех западных вендоров в облако и подписку без возможности установки сервера внутри периметра компании с покупкой бессрочной лицензии — в России (да и не только, на самом деле) это мало кому нравится;
- Возможность иметь вендора «под рукой» и реально влиять на дорожную карту продукта;
- Снижение совокупной стоимости владения за счет использования Linux-серверов и лицензирования в рублях;
- Регуляторные риски: для некоторых компаний существует вполне реальный риск попасть под санкции и потерять возможность продлить уже приобретенные импортные лицензии.
Было понятно, что это тоже будет непросто, ведь на тот момент на нем уже были российские конкуренты.
Местных BI-разработчиков оказалось на удивление много, а новые продолжают появляться и сейчас, хотя лишь некоторых из них мы считаем серьезными конкурентами для себя.
Я не отрицаю множество проблем, которые окружают всю тему импортозамещения, но этот процесс, безусловно, открывает возможности для российских девелоперских компаний.
Конечно, не стоит ожидать, что как только вы внесете свое ПО в Реестр отечественного ПО Минсвязи, на него посыплются заказы, но стоит присмотреться к открывающимся возможностям.
В этом нам очень помогло членство в Ассоциации отечественных разработчиков программного обеспечения (АРПП), в которую входят такие авторитетные компании, как InfoWatch, 1С, ЦРТ, ABBYY, Лаборатория Касперского и другие.
2019 – Развитие партнёрской сети, крупные внедрения Enterprise
Развитие партнерского канала – отдельная история.Мы четко понимали, что хотя наш якорный интегратор Polymedia и внес свой вклад в развитие Visiology, он не сможет помочь нам охватить весь рынок.
Нам нужны были партнёры – реселлеры, интеграторы, дистрибьюторы.
Для девелоперской компании идея продаж через партнеров вполне логична и лежит на поверхности — вы разрабатываете, они продают и внедряют. Проблема в том, что многие разработчики почему-то думают, что как только они сделают продукт, все партнеры бросятся его продвигать и продавать.
В действительности это, конечно, не так.
Цель любой компании – зарабатывать деньги, а не продвигать чужие товары.
Партнерам нужны продукты, которые легко продать (в идеале клиент должен прийти за ними), легко внедрить (в идеале вообще ничего не делая и не обучая специалистов) и на которых можно хорошо зарабатывать, без каких-либо затрат на поддержку.
Это означает, что продукт должен достичь очень серьезного уровня зрелости и признания на рынке, чтобы заинтересовать партнерский канал.
Я говорю все это потому, что мы добились большого успеха в реализации партнерской программы для других продуктов.
А в случае с аналитической платформой мы уже никуда не торопились.
Однако в 2019 году партнеры сами стали приходить с запросами, это был знак – пора! Мы быстро запустили партнёрскую программу и создали всю необходимую экосистему — и это не только (и не столько) продукт, а материалы поддержки продаж, понятная документация, видео, обучающие программы и многое другое.
Было вложено много сил, но результат впечатлял - за год мы полностью запустили партнерскую сеть, начали работать практически со всеми крупными российскими ИТ-интеграторами, подписали соглашение с двумя дистрибьюторами и даже заключили ряд очень интересных технологических партнерств - с Arenadata, Loginom и Vertica. 
Работа с партнерами и тестирование в крупных компаниях дали нам огромное количество отзывов, и не всегда положительных.
Основной проблемой стал проигрыш по сравнению с системами, которые обычно используются для подобных задач (Qlik, Oracle BI/Hyperion, IBM Cognos, SAP BI) с точки зрения «корпоративных» требований.
Эти нюансы незаметны для пользователя, но без них ни один уважающий себя CIO не запустит систему в продакшн — предсказуемая производительность, масштабируемость, поддержка сред dev-test-prod, мониторинг, детальное логирование, SSO и многое другое.
Мы начали с оптимизации производительности и для этого в том же году наконец-то внедрили автоматизированное нагрузочное тестирование (а как ещё можно оптимизировать то, что нельзя измерить?).
Для этого мы даже наняли стороннюю компанию, специалиста по автотестам, который написал нам JMeter-скрипты и пользовательские скрипты.
Это сэкономило нам много времени, но тогда нам всё равно пришлось самим глубоко вникать в скрипты и даже переписывать некоторые из них самим — погрузить подрядчика во все нюансы системы оказалось слишком сложной задачей.
Рисунок 2. Пример сценария нагрузочного тестирования Нагрузочное тестирование BI-платформы само по себе очень сложная и интересная задача, достойная отдельной статьи.
Основная сложность этого процесса заключается в том, что производительность очень сильно зависит от характера загружаемых данных (модель и связи, мощность и типы полей в таблицах и многое другое) и от сценариев использования (одновременное редактирование модели, ввод и перезагрузка данных, просмотр информационных панелей и т.п.
).
При этом данные должны быть максимально приближены к реальным.
В настоящее время мы используем как тесты на основе TPC-H, так и клоны клиентских реализаций, очищенные от конфиденциальных данных.
Это позволяет нам быть уверенными, что у нас нет иллюзий, связанных с синтетическими тестами, отличающимися от реальной жизни.
Рисунок 3. Пример выдержки из отчета о нагрузочном тестировании В каждой крупной компании, с которой мы встречались
Теги: #Разработка стартапов #ИТ-компании #ИТ-компании #Визуализация данных #аналитика данных #визуализация #бизнес-аналитика #бизнес-аналитика
-
Анонимный Клуб Devops
19 Oct, 24 -
Огни Были Выключены. Что Делать?
19 Oct, 24 -
Htc Hero, Неделя С Официальным Android 2.1
19 Oct, 24 -
В Японии Начали Бесплатно Раздавать Айфоны
19 Oct, 24
