Да, если поставить более быструю базу должно работать быстрее. Но, как я писал, в целом БД то отвечает за разумное время. Когда дашборд работает за 6-8 секунд, все запросы к базе отрабатывают в пределах 1 секунды. Из-за связанных фильтров вызов части запросов идет последовательно, поэтому время работы дашборда увеличивается.
Конечно если БД будет быстрее раз в 10-ть, то наверное скорость работы дашборда сократиться до 3-4 секунд. Но это все равно долго.
Самое интересное по этой теме, что я находил были GPU DB Kinetica и SQream. По их собственным заявлениям они быстрея и Exasol и HANA и даже ClickHouse, но внедрений то промышленных нет… А железо стоит ой как не дешево…

Спасибо! Мы проведем эксперимет и такой.
Но в HANA примерно такая же история. Там поколоночная БД. Если в запросе нет какого-то поля, то БД не будет брать эту колонку. Поэтому я не думаю, что это может как-то ускорить работу дашборда. Запросы из Tableau мы смотрели, они запрашивают только нужные поля, ну и база поднимает, только нужные колонки.

Старались делать максимально адекватным.
Никто не спорит, что Qlik хороший инструмент. Вопросы ключевые:
Каково соотношение цена (лицензии, стоимость разработки и поддержки, железо) / конечный результат / скорость внедрения у продукта?
Сколько примеров внедрения системы в розничных крупных сетях?

50 млн.транзакций в день у вас? Какая атрибутика этих транзакций? У нас около 1 млн.транзакций в день и около 20 млн.кликов на сайте в день. Все это нужно представлять в разрезе неаддитивных признаков. Если задача аддитивные показатели и разложить их по базовым признаками/атрибутам, я уверен, что такие задачи выполнит адекватно и Qlik, и Power BI и Tableau. Сложности возникают, когда добавляются те детали, о которых я писал в статье.
Да и в 10 секунд мы влези и в связки Tableau — HANA Live connect, задача влезть в 2/3 секунды

Спасибо!
Да мне тоже понравился Tableau в части набора инстремунтария в части визуализации. В части манипулации с данными, все не так однозначно.
А насчет объемов и агрегации, тут мешает Деталь 2. Неаддитивные показатели, не все можно сагрегировать.

Здравствуйте!
Про Qlik написал выше. Чтобы Qlik работал быстро ему нужно все выгружать к себе. И быстро у него работает, на сколько я знаю, когда все data-файлы хранятся в оперативной памяти. Степень сжатия данных не очень высокая, поэтому стоимость сервера на наш объем данных будет хорошая.

Спасибо!
У нас такого богатого опыта нет. Поэтому и написал сюда с просьбой дать советы)
300 млн.строк — это один год наших данных, а на этапе формирования дашборда нужно, как я писал, сравнивать данные с прошлым годом, считать кол-во строк. И сформировать около 20 рассчитанных показателей…
Мы сейчас сделали максимально материализованную витрину и с транспонированием показателей у нас получилось около 2,5 млрд.строк за год. По которым остается только сделать выборку и посчитать доли.
Но есть подозрение, что такой объем на экстракте работать нормально не будет. Тестим. Так же инкрементальный экстракт тоже вызывает вопросы

по п.2
Точно пробовали последние две вещи, но почему-то они не зашли, спрошу у ребят вернусь

по п.3 ровно в 2019.2. Посмотрим

по п.4 Вы имеете ввиду рисовать звездочку в самом Tableau? У нас с точки зрения Tableau схема выглядит как один источник. Даже справочники мы джойним на уровне БД сейчас

P.S. Если есть интерес детально взглянуть на наш кейс и помочь — пишите мне на почту, обсудим Aleksandr.Bezugly@mvideo.ru

И Вам спасибо!
Не уверен, что понял точно, что Вы имели ввиду.
Пока у нас следующая версия получилась.
Если один дашборд, который работает 6-7 секунд на любой клик. В нем есть только разрез по Магазину/Неделе, из него есть переход в дашборд который позволяет выбирать данные уже в разрезе товарной иерархии, который работает от 30 до 90 секунд в зависимости от выбранных фильтров.
Мы еще хотим протестить Tableau на полностью материализованные витрины в которых будут все наборы гранулярностей материализованы и как раз в зависимости от выбора развертки Tableau будет обращаться то к одной витрине, то к другой. Но пока не хватает экспертизы внутренней это реализовать в Tableau, работаем над этим. Само хранилище на таких витринах работает очень шустро.

Нет, не смотрели. Не видел его в квадрате Гартнера по BI.
HADOOP и наша цель делать выборки из таблиц в 2-3 млрд. строк за 0,1-0,5 секунды у меня друг с другом не вяжутся.
Опыт работы с HIVE и HBASE был, но это десятки секунд

Спасибо!
Я правильно понимаю, что имеется ввиду Tibco Spotfire?
А с какими объемами данных работаете? Над какими БД построена отчетность?

Спасибо! Подскажите, что значит публикуем?
Мы хотели построить в Tableau дашборды для self-service аналитики top и middle менеджмента компании.

В сторону qlik думали, конечно.
Основной критерии описал выше. Полный скоринг выглядел вот так:


Как видно, Tableau почти по всем направлениям, в важных для нас критериях оказывался предпочтителен.
Что касается кэширования в инструменте визуализации. Промежуточные слои есть везде. И в Power BI, SAP SAC, Qlik.
В Qlik, что смущало:
1. Qlik Sense достаточно молод. А Qlik View устарел и не пригоден был для наших потребностей по визуализации.
2. Qlik рисует свою модель данных, если же ее менять, то все преимущества qlik теряеются, и вы несете доп.косты. На текущий момент у нас есть большая модель данных для всей компании, рисовать такую же модель данных в еще одном инструменте не очень хочется, это если говорить про долгосрочные планы. Т.е. у нас была идея Tableau подключить к текущей моделе данных в HANA, с Qlik это было бы не возможно, так требуется модель делать в Qlik.
3. Qlik достаточно ресурсоемкий продукт, т.е. требовалась бы хорошие инвестиции в оборудование. В Tableau же, даже экстракт хранится на диске, а не в оперативке

Здравствуйте. Рассматривали. У нас был конкурс, с формированием простого пилотного дашборда. Основной упор на этапе пилота делали на возможности по визуализации. Их у Tableau оказалось больше.
Так же в Power BI смущало следующее:
1. Большая развитость облачного решения, чем on-premise. А мы по ряду причин больше склоняемся к on premise
2. Отсутствие на российском рынке внедрений Power BI на масшатабах всей компании и внедрений в Рознице. Пообщавшись с многими, пришли к выводу, что большие объемы Power BI, точно будет обрабатывать хуже, чем Tableau

Здравствуйте, много) Мы рассчитывали на меньшее.
Суммарно мы потратили на все изыскания 2,5 месяца.
Подготовка, т.е. формирование макета и согласование с бизнесом заняло 3 недели.
Потом за две недели мы нарисовали первую версию, которая работала ОООчень долго. Ну и еще 6 недель у нас ушло на все работы которые я описал выше.
у нас был:
1 Архитектор по визуализации (Эксперт Tableau)
1 Архитектор по хранилищу
2 Разраба Tableau
1 Разраб по HANA/BW
По Tableau у нас был подрядчик, и основная часть работ проводилась удаленно. Поэтому, думаю, если этот «разрыв» убрать, то все эти работы можно было на 3,4 недели точно сократить.

Доброго времени суток.
Понятно, что ORACLE не обладал такой RAM но сам комплекс компании обходился не многим дешевле чем комплекс HANA. В ORACLE нужно примерно в 10 раз больше СХД, нужны агрегаты, индексы, данные не сжаты поколоночно.
Естественно я говорю про старые версии ORACLE и те ограничения что есть в SAP BW on Oracle

Вы правы, наш опыт показывает, чем нод меньше, тем с системой проще "разбираться" и использование памяти более оптимально. Обратная сторона это CPU, хоть SAP и сертифицирует только оборудование, которое выдаёт определённый коэффициент Gb RAM/CPU, обычно на более "толстых" узлах количество CPU ниже. Если у Вас профиль нагрузки в основном упирается в CPU, то лучше больше маленьких нод с большим количеством CPU.
Если говорит, про нашу ситуацию, то мы жили в рамках нашей инфраструктуры, комплекс покупался в 2014-ом, на тот момент 2Тб — было максимум

Про параметры в БД возможно напишу отдельный пост. Если интересно

Добрый день!
Это интересный вопрос.
Текущее состояние в системе отчетности и в материализации/предрасчете результатов отчетов это некий баланс между следующими аспектами:
1. гибкость модели данных, мы стараемся придерживаться концепции LSA++, у нас очень часто бизнес меняет какие-либо алгоритмы расчета показателей, или же атрибутику и иерархии, которые должны ретроспективно отразится на всем периоде данных анализируем регулярно (а это три года, а данных много);
2. доступность системы отчетности для разработки со стороны бизнес подразделений. Так сейчас в компании есть центры компетенций и отдельные аналитики создающие свои собственные отчеты в на базе Univers'а в SAP BO. Сейчас никто не ограничивает бизнес делать любую отчетность над всей глубиной данных в любой детализации. В случае предрасчитанных материализованных VIEW, они были бы ограничены рамками этих VIEW. И добавление аналитики в это VIEW потребовало подключение ИТ;
3. Производительностью системы. И вот здесь мы обнаружили ряд кейсов, про которые я рассказал выше, ряд которые не описывал применяя которые мы существенно сократили время работы и нагрузку на систему HANA со стороны BO. А если еще регулярно проводить мониторинг разработки со стороны бизнеса, то HANA позволяет достаточно оперативно обрабатывать даже такие где-то не оптимальные с точки зрения объема данных запросы

При этом есть ряд базовых показателей и атрибутик, которые ранее у нас так же всегда считались на лету, но мы обсудив с бизнесов поняли, что алгоритмы расчета этих аналитик жестко фиксированные и такие объекты мы «приземлили» в хранилище и считаем на уровне ETL, чтобы снять регулярную нагрузку
В общем как-то так, каждый ищет для себя золотую середину, она у нас пока в виртуальное моделе финальных данных для КХД

Это небольшая неточность. 5 Пб — это размер всех систем компании. Используемого места примерно 60%. Из этого на SAP системе приходится около 25%, все остальное не SAP.