Comments 41
Подскажите, сколько времени заняли все тесты с табло (написание бизнес-логики, описание процессов в конфлюенс(вики), знакомство с инструментарием, материализация данных на стороне бд итп), в человеко-часах, от первой таски в жире на испытание табло до конца r&d с результатами о принятии решения «идти ли в табло»?
Здравствуйте, много) Мы рассчитывали на меньшее.
Суммарно мы потратили на все изыскания 2,5 месяца.
Подготовка, т.е. формирование макета и согласование с бизнесом заняло 3 недели.
Потом за две недели мы нарисовали первую версию, которая работала ОООчень долго. Ну и еще 6 недель у нас ушло на все работы которые я описал выше.
у нас был:
1 Архитектор по визуализации (Эксперт Tableau)
1 Архитектор по хранилищу
2 Разраба Tableau
1 Разраб по HANA/BW
По Tableau у нас был подрядчик, и основная часть работ проводилась удаленно. Поэтому, думаю, если этот «разрыв» убрать, то все эти работы можно было на 3,4 недели точно сократить.
Суммарно мы потратили на все изыскания 2,5 месяца.
Подготовка, т.е. формирование макета и согласование с бизнесом заняло 3 недели.
Потом за две недели мы нарисовали первую версию, которая работала ОООчень долго. Ну и еще 6 недель у нас ушло на все работы которые я описал выше.
у нас был:
1 Архитектор по визуализации (Эксперт Tableau)
1 Архитектор по хранилищу
2 Разраба Tableau
1 Разраб по HANA/BW
По Tableau у нас был подрядчик, и основная часть работ проводилась удаленно. Поэтому, думаю, если этот «разрыв» убрать, то все эти работы можно было на 3,4 недели точно сократить.
Power BI не рассматривали?
Здравствуйте. Рассматривали. У нас был конкурс, с формированием простого пилотного дашборда. Основной упор на этапе пилота делали на возможности по визуализации. Их у Tableau оказалось больше.
Так же в Power BI смущало следующее:
1. Большая развитость облачного решения, чем on-premise. А мы по ряду причин больше склоняемся к on premise
2. Отсутствие на российском рынке внедрений Power BI на масшатабах всей компании и внедрений в Рознице. Пообщавшись с многими, пришли к выводу, что большие объемы Power BI, точно будет обрабатывать хуже, чем Tableau
Так же в Power BI смущало следующее:
1. Большая развитость облачного решения, чем on-premise. А мы по ряду причин больше склоняемся к on premise
2. Отсутствие на российском рынке внедрений Power BI на масшатабах всей компании и внедрений в Рознице. Пообщавшись с многими, пришли к выводу, что большие объемы Power BI, точно будет обрабатывать хуже, чем Tableau
Пользуясь случаем, как обычно, приглашаю всех заинтересованых присоединиться к нам в Russian Chat — Power BI в Telegram.
А в сторону qlik sense не думали? Почему выбрали именно табло и по каким критериям? В клике можно выгрузить все данные в промежуточный слой и догружать только новые данные из хранилища, а нужные данные будут хранится в оперативнее и агрегироваться на лету
В сторону 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, SAP SAC, Qlik.
В Qlik, что смущало:
1. Qlik Sense достаточно молод. А Qlik View устарел и не пригоден был для наших потребностей по визуализации.
2. Qlik рисует свою модель данных, если же ее менять, то все преимущества qlik теряеются, и вы несете доп.косты. На текущий момент у нас есть большая модель данных для всей компании, рисовать такую же модель данных в еще одном инструменте не очень хочется, это если говорить про долгосрочные планы. Т.е. у нас была идея Tableau подключить к текущей моделе данных в HANA, с Qlik это было бы не возможно, так требуется модель делать в Qlik.
3. Qlik достаточно ресурсоемкий продукт, т.е. требовалась бы хорошие инвестиции в оборудование. В Tableau же, даже экстракт хранится на диске, а не в оперативке
Странный у вас бенч. Мы на Qlik объединяем данные транснациональной корпорации из 20+ систем в единый финансово-аналитический портал, имеем более 50 млн транзакций и система прекрасно себя показывает на «тяжелейших» табах до 10 секунд при десятке конкурентных пользователей. И это на адекватных мощностях.
Старались делать максимально адекватным.
Никто не спорит, что Qlik хороший инструмент. Вопросы ключевые:
Каково соотношение цена (лицензии, стоимость разработки и поддержки, железо) / конечный результат / скорость внедрения у продукта?
Сколько примеров внедрения системы в розничных крупных сетях?
50 млн.транзакций в день у вас? Какая атрибутика этих транзакций? У нас около 1 млн.транзакций в день и около 20 млн.кликов на сайте в день. Все это нужно представлять в разрезе неаддитивных признаков. Если задача аддитивные показатели и разложить их по базовым признаками/атрибутам, я уверен, что такие задачи выполнит адекватно и Qlik, и Power BI и Tableau. Сложности возникают, когда добавляются те детали, о которых я писал в статье.
Да и в 10 секунд мы влези и в связки Tableau — HANA Live connect, задача влезть в 2/3 секунды
Никто не спорит, что Qlik хороший инструмент. Вопросы ключевые:
Каково соотношение цена (лицензии, стоимость разработки и поддержки, железо) / конечный результат / скорость внедрения у продукта?
Сколько примеров внедрения системы в розничных крупных сетях?
50 млн.транзакций в день у вас? Какая атрибутика этих транзакций? У нас около 1 млн.транзакций в день и около 20 млн.кликов на сайте в день. Все это нужно представлять в разрезе неаддитивных признаков. Если задача аддитивные показатели и разложить их по базовым признаками/атрибутам, я уверен, что такие задачи выполнит адекватно и Qlik, и Power BI и Tableau. Сложности возникают, когда добавляются те детали, о которых я писал в статье.
Да и в 10 секунд мы влези и в связки Tableau — HANA Live connect, задача влезть в 2/3 секунды
Табло — мощь. Обработка, аналитика и визуализация данных — все прекрасно.
Только дорого для небольших компаний, если хочется доступы к данным давать сотрудникам, а не только в узком кругу анализировать. Поэтому анализируем в табло, а публикуем в других системах.
Только дорого для небольших компаний, если хочется доступы к данным давать сотрудникам, а не только в узком кругу анализировать. Поэтому анализируем в табло, а публикуем в других системах.
Спасибо! Подскажите, что значит публикуем?
Мы хотели построить в Tableau дашборды для self-service аналитики top и middle менеджмента компании.
Мы хотели построить в Tableau дашборды для self-service аналитики top и middle менеджмента компании.
Для меня самая полезная часть табло — это Prep. Возможность собрать разные данные из разных источников и собрать из них таблички, которые потом визуализировать можно уже где угодно — хоть в Google Data Studio, хоть в Power BI. Лично я использую Metabase.
У нас скриптом данные, сформированные в Prep загружаются на MySQL сервер, и с этими данными уже работа в команде ведется через Metabase. Есть еще Redash — оба инструмента бесплатные, но требуют установки на сервер. Есть нужно совсем просто, то Data Studio самое то.
У нас скриптом данные, сформированные в Prep загружаются на MySQL сервер, и с этими данными уже работа в команде ведется через Metabase. Есть еще Redash — оба инструмента бесплатные, но требуют установки на сервер. Есть нужно совсем просто, то Data Studio самое то.
Вам хватает Metabase?
У меня первая реакция была wow, а потом смотрю, графики на почту не умеет, параметры в sql-запросы иногда странно передаются и пользователю выскакивают непонятные красные сообщения, от которых они пугаются. Иногда соответствие между столбцами из запроса слетала с визуализацией. И вот как-то весь вау-эффект иссяк.
У меня первая реакция была wow, а потом смотрю, графики на почту не умеет, параметры в sql-запросы иногда странно передаются и пользователю выскакивают непонятные красные сообщения, от которых они пугаются. Иногда соответствие между столбцами из запроса слетала с визуализацией. И вот как-то весь вау-эффект иссяк.
Работаю с Tableau 9 лет, с выводами согласен и нет )
п.1 Сильно зависит от сложности вычислений, там много факторов влияет. Для экстракта можно достичь нормальной скорости на объемах до 300 млн. строк, если вычисления оптимизированы, дальше уже нужно с внешними БД работать.
По п.2 — на самом деле фильтры передавать можно. 3 варианта навскидку
1. Использовать blending — тогда можно одно поле для фильтрации нескольких источников, на каждом строить свой дашборд, можно даже в рамках одной книги.
2. С помощью Filter Action в лашборде можно передавать значения из одного источника в другой
3. Можно фильтровать дашборды в другой с помощью URL Action
п.3 Не знаю, в какой версии вы работаете, но с версии 2019.2 можно динамические передавать в параметр значения из любого графика с помощью Parameter action.
п.4 С кубами у Табло вообще сложные отношения ) В идеале надо строить звезду с нужным набором показателей, она лучше всего работает с т.з. скорости.
п.1 Сильно зависит от сложности вычислений, там много факторов влияет. Для экстракта можно достичь нормальной скорости на объемах до 300 млн. строк, если вычисления оптимизированы, дальше уже нужно с внешними БД работать.
По п.2 — на самом деле фильтры передавать можно. 3 варианта навскидку
1. Использовать blending — тогда можно одно поле для фильтрации нескольких источников, на каждом строить свой дашборд, можно даже в рамках одной книги.
2. С помощью Filter Action в лашборде можно передавать значения из одного источника в другой
3. Можно фильтровать дашборды в другой с помощью URL Action
п.3 Не знаю, в какой версии вы работаете, но с версии 2019.2 можно динамические передавать в параметр значения из любого графика с помощью Parameter action.
п.4 С кубами у Табло вообще сложные отношения ) В идеале надо строить звезду с нужным набором показателей, она лучше всего работает с т.з. скорости.
Спасибо!
У нас такого богатого опыта нет. Поэтому и написал сюда с просьбой дать советы)
300 млн.строк — это один год наших данных, а на этапе формирования дашборда нужно, как я писал, сравнивать данные с прошлым годом, считать кол-во строк. И сформировать около 20 рассчитанных показателей…
Мы сейчас сделали максимально материализованную витрину и с транспонированием показателей у нас получилось около 2,5 млрд.строк за год. По которым остается только сделать выборку и посчитать доли.
Но есть подозрение, что такой объем на экстракте работать нормально не будет. Тестим. Так же инкрементальный экстракт тоже вызывает вопросы
по п.2
Точно пробовали последние две вещи, но почему-то они не зашли, спрошу у ребят вернусь
по п.3 ровно в 2019.2. Посмотрим
по п.4 Вы имеете ввиду рисовать звездочку в самом Tableau? У нас с точки зрения Tableau схема выглядит как один источник. Даже справочники мы джойним на уровне БД сейчас
P.S. Если есть интерес детально взглянуть на наш кейс и помочь — пишите мне на почту, обсудим Aleksandr.Bezugly@mvideo.ru
У нас такого богатого опыта нет. Поэтому и написал сюда с просьбой дать советы)
300 млн.строк — это один год наших данных, а на этапе формирования дашборда нужно, как я писал, сравнивать данные с прошлым годом, считать кол-во строк. И сформировать около 20 рассчитанных показателей…
Мы сейчас сделали максимально материализованную витрину и с транспонированием показателей у нас получилось около 2,5 млрд.строк за год. По которым остается только сделать выборку и посчитать доли.
Но есть подозрение, что такой объем на экстракте работать нормально не будет. Тестим. Так же инкрементальный экстракт тоже вызывает вопросы
по п.2
Точно пробовали последние две вещи, но почему-то они не зашли, спрошу у ребят вернусь
по п.3 ровно в 2019.2. Посмотрим
по п.4 Вы имеете ввиду рисовать звездочку в самом Tableau? У нас с точки зрения Tableau схема выглядит как один источник. Даже справочники мы джойним на уровне БД сейчас
P.S. Если есть интерес детально взглянуть на наш кейс и помочь — пишите мне на почту, обсудим Aleksandr.Bezugly@mvideo.ru
Если джоины прописывать в самом Tableau, то он будет их учитывать при построении запроса к базе данных.
К примеру вы считаете показатель на уровне чека и джойните его к items. Так вот, если на sheet'e нету полей с уровня items, Tableau обратится только к таблице чека и на ней посчитает вашу агрегацию. (при экстракте он все равно джоины материализует)
Генерация кода все равно останется.
К примеру вы считаете показатель на уровне чека и джойните его к items. Так вот, если на sheet'e нету полей с уровня items, Tableau обратится только к таблице чека и на ней посчитает вашу агрегацию. (при экстракте он все равно джоины материализует)
Генерация кода все равно останется.
Спасибо! Мы проведем эксперимет и такой.
Но в HANA примерно такая же история. Там поколоночная БД. Если в запросе нет какого-то поля, то БД не будет брать эту колонку. Поэтому я не думаю, что это может как-то ускорить работу дашборда. Запросы из Tableau мы смотрели, они запрашивают только нужные поля, ну и база поднимает, только нужные колонки.
Но в HANA примерно такая же история. Там поколоночная БД. Если в запросе нет какого-то поля, то БД не будет брать эту колонку. Поэтому я не думаю, что это может как-то ускорить работу дашборда. Запросы из Tableau мы смотрели, они запрашивают только нужные поля, ну и база поднимает, только нужные колонки.
Мы на Tibco ставим, по мощности хорош
Спасибо!
Я правильно понимаю, что имеется ввиду Tibco Spotfire?
А с какими объемами данных работаете? Над какими БД построена отчетность?
Я правильно понимаю, что имеется ввиду Tibco Spotfire?
А с какими объемами данных работаете? Над какими БД построена отчетность?
Да, правильно. Объемы пока небольшие, самые большие таблицы с исходными данными где-то на пару-тройку миллионов ячеек, плюс нужные трансформации и калькуляционные столбцы. Всяческих дашиков и аналитических визуалок более десятка. Hana у нас пока нет, старенький blueprint. Сейчас собираем data hub, где будем собирать все из разных дата баз для доступа, очень разрозненные и чуждые системы.
Про БД — пока тянем с SQL
Ещё есть желание до визуалок на java дойти, как время будет. Меня лично работа с R packages в spotfire больше интересует
В сторону комплексов SAS не смотрели? Как вариант SAS Visual Analytics на платформе 9.4, либо на новой Viya. Используется также in-memory технология + возможность прикрутить Hadoop, либо использовать встроенный (но функционально урезанный) для хранения данных и быстрой загрузки в память.
Единственное не дешёвое удовольствие по лицензиям.
Единственное не дешёвое удовольствие по лицензиям.
Нет, не смотрели. Не видел его в квадрате Гартнера по BI.
HADOOP и наша цель делать выборки из таблиц в 2-3 млрд. строк за 0,1-0,5 секунды у меня друг с другом не вяжутся.
Опыт работы с HIVE и HBASE был, но это десятки секунд
HADOOP и наша цель делать выборки из таблиц в 2-3 млрд. строк за 0,1-0,5 секунды у меня друг с другом не вяжутся.
Опыт работы с HIVE и HBASE был, но это десятки секунд
На самом деле Hadoop там используется только для хранения данных на диске, можно сказать что-то вроде бэкапа т.к в RAM данные не бэкапятся и их в случае чего можно оперативно в in-memory из hadoop опять загрузить в память.
Вся работа и с данными (обработка, расчёты и.т.п) выполняются непосредственно в памяти, поэтому там отклики довольно шустрые.
Короче рекомендую обратиться в SAS (русское представительство есть в мск). Они могут под ваши нужны сделать пилот, либо продемонстрировать презентацию и показать как всё это будет работать. Это не реклама, сами используем в работе и все довольны. После внедрения у нас разработкой витрин и отчётности для топов уже не занимается IT, а всю работу на себя забрали аналитики (из вашей статьи это Middle-менеджмент). Это ещё и сократило время разработки новых отчётов и показателей и практически нет зависимости от IT у аналитиков.
Также там есть сразу в поставке мобильная версия для планшетов и смартфонов.
И кстати если ориентироваться на вашу идею, то комплекс вполне подходит:
<<Наша идея заключалась в том, чтобы покрыть потребности всех пользователей и дать им единый удобный инструмент. >>
Там используется единая платформа и полно инструментов. Пользователи могут сами получать доступ к внешним источникам данных (базы данных, данные из интернета и.т.п) и исследовать данные и строить витрины, ad-hoc запросы. Даже обычные юзеры с помощью конструктора могут составить запрос и получить данные.
А продвинутые могут с помощью языка SAS Base.
Вся работа и с данными (обработка, расчёты и.т.п) выполняются непосредственно в памяти, поэтому там отклики довольно шустрые.
Короче рекомендую обратиться в SAS (русское представительство есть в мск). Они могут под ваши нужны сделать пилот, либо продемонстрировать презентацию и показать как всё это будет работать. Это не реклама, сами используем в работе и все довольны. После внедрения у нас разработкой витрин и отчётности для топов уже не занимается IT, а всю работу на себя забрали аналитики (из вашей статьи это Middle-менеджмент). Это ещё и сократило время разработки новых отчётов и показателей и практически нет зависимости от IT у аналитиков.
Также там есть сразу в поставке мобильная версия для планшетов и смартфонов.
И кстати если ориентироваться на вашу идею, то комплекс вполне подходит:
<<Наша идея заключалась в том, чтобы покрыть потребности всех пользователей и дать им единый удобный инструмент. >>
Там используется единая платформа и полно инструментов. Пользователи могут сами получать доступ к внешним источникам данных (базы данных, данные из интернета и.т.п) и исследовать данные и строить витрины, ad-hoc запросы. Даже обычные юзеры с помощью конструктора могут составить запрос и получить данные.
А продвинутые могут с помощью языка SAS Base.
Спасибо, интересное чтиво! Напоминает проблему расчета пресловутой АКБ в FMCG.
Не попробовали разделить информацию на разные источники (по гранулярности Report period и организовать подмену визуализаций через выбор гранулярности через параметр), или передачу фильтров в другой дэшборд (из общего в более детальный) через URL-action? Что то этому мешало?
Не попробовали разделить информацию на разные источники (по гранулярности Report period и организовать подмену визуализаций через выбор гранулярности через параметр), или передачу фильтров в другой дэшборд (из общего в более детальный) через URL-action? Что то этому мешало?
И Вам спасибо!
Не уверен, что понял точно, что Вы имели ввиду.
Пока у нас следующая версия получилась.
Если один дашборд, который работает 6-7 секунд на любой клик. В нем есть только разрез по Магазину/Неделе, из него есть переход в дашборд который позволяет выбирать данные уже в разрезе товарной иерархии, который работает от 30 до 90 секунд в зависимости от выбранных фильтров.
Мы еще хотим протестить Tableau на полностью материализованные витрины в которых будут все наборы гранулярностей материализованы и как раз в зависимости от выбора развертки Tableau будет обращаться то к одной витрине, то к другой. Но пока не хватает экспертизы внутренней это реализовать в Tableau, работаем над этим. Само хранилище на таких витринах работает очень шустро.
Не уверен, что понял точно, что Вы имели ввиду.
Пока у нас следующая версия получилась.
Если один дашборд, который работает 6-7 секунд на любой клик. В нем есть только разрез по Магазину/Неделе, из него есть переход в дашборд который позволяет выбирать данные уже в разрезе товарной иерархии, который работает от 30 до 90 секунд в зависимости от выбранных фильтров.
Мы еще хотим протестить Tableau на полностью материализованные витрины в которых будут все наборы гранулярностей материализованы и как раз в зависимости от выбора развертки Tableau будет обращаться то к одной витрине, то к другой. Но пока не хватает экспертизы внутренней это реализовать в Tableau, работаем над этим. Само хранилище на таких витринах работает очень шустро.
Очень глубокий анализ. Спасибо.
А что в итоге тестируете? Было бы круто посмотреть на результаты следующего конкурента.
Было бы интересно услышать какие критерии вы бы вложили в это определение.
По поводу скорости:
— Очень хорошую прибавку к скорости дают контекстные фильтры, которые отсекают большие объемы данных с самого начала и которые исполняются последовательно на остаточных данных. Просто по фильтру правой кнопкой мыши кликаете и добавляете в контекст
— На больших объемах надо избегать LOD калькуляций и переносить все это дело на базу. Если у вас там хоть один такой есть — он затормозит всю визуализацию.
— Лучше всего делать именно монолитные графики. Т.е. снижать количество sheets и точек данных на этих sheets. Он когда рендерит — рендерит их по отдельности, так что если на вашем макете на дашборде все это выглядит монолитным, а на бэкенде это 20 шитов (или 1 карта с кучей точек) то производительность просядет
Итоговый результат тоже тестировали на экстракте? Разницы нет?
Ваш финальный результат хорош и на среднем дашборде (средний объем данных и средняя сложность расчетов) я бы сказал что такую производительность и стоит ожидать. Но на пре-агрегированных данных должно быть чуть лучше.
А что в итоге тестируете? Было бы круто посмотреть на результаты следующего конкурента.
инструмент, способный строить промышленные дашборды и средство, с помощью которого можно заменить и диджиализировать все систему корпортативной отчетности компании
Было бы интересно услышать какие критерии вы бы вложили в это определение.
По поводу скорости:
— Очень хорошую прибавку к скорости дают контекстные фильтры, которые отсекают большие объемы данных с самого начала и которые исполняются последовательно на остаточных данных. Просто по фильтру правой кнопкой мыши кликаете и добавляете в контекст
— На больших объемах надо избегать LOD калькуляций и переносить все это дело на базу. Если у вас там хоть один такой есть — он затормозит всю визуализацию.
— Лучше всего делать именно монолитные графики. Т.е. снижать количество sheets и точек данных на этих sheets. Он когда рендерит — рендерит их по отдельности, так что если на вашем макете на дашборде все это выглядит монолитным, а на бэкенде это 20 шитов (или 1 карта с кучей точек) то производительность просядет
Итоговый результат тоже тестировали на экстракте? Разницы нет?
Ваш финальный результат хорош и на среднем дашборде (средний объем данных и средняя сложность расчетов) я бы сказал что такую производительность и стоит ожидать. Но на пре-агрегированных данных должно быть чуть лучше.
А вы пробовали QlikSense? Работает по быстрее чем Tableau и при этом нет требований на большой перечень инфраструктуры как у Power BI.
Здравствуйте!
Про Qlik написал выше. Чтобы Qlik работал быстро ему нужно все выгружать к себе. И быстро у него работает, на сколько я знаю, когда все data-файлы хранятся в оперативной памяти. Степень сжатия данных не очень высокая, поэтому стоимость сервера на наш объем данных будет хорошая.
Про Qlik написал выше. Чтобы Qlik работал быстро ему нужно все выгружать к себе. И быстро у него работает, на сколько я знаю, когда все data-файлы хранятся в оперативной памяти. Степень сжатия данных не очень высокая, поэтому стоимость сервера на наш объем данных будет хорошая.
QlikSense работает с приложениями которые хранят в себе набор данных. Причем хранятся только уникальные значения. К примеру xlsx 26 мб полностью загруженный в QlikSense занимает 6.5 Мб. Это с описанием визуализации.
Так же вы можете использовать On Demaind generation. То есть у вас одно больше приложение с агрегированными данными, а по требованию из источников загружаете детальную информацию в приложение шаблон. Тем более в новых версиях это возможно без шаблона, прямо встраивать в виде отдельных элементов визуализации в приложение с агрегированными данными. Вариаций много, это первое что пришло на ум.
Так же вы можете использовать On Demaind generation. То есть у вас одно больше приложение с агрегированными данными, а по требованию из источников загружаете детальную информацию в приложение шаблон. Тем более в новых версиях это возможно без шаблона, прямо встраивать в виде отдельных элементов визуализации в приложение с агрегированными данными. Вариаций много, это первое что пришло на ум.
Вполне понятны проблемы с которыми вы столкнулись, но!
Табло не без основательно одна из лучших BI системе, как и PBI. В нашей компании используется табло, сейчас протестил построение дашбордов 3 секунды, как и их обновление. Но у нас данных на порядок меньше (миллионы строк), вам же остаётся как-то агрегировать данные.
Табло не без основательно одна из лучших BI системе, как и PBI. В нашей компании используется табло, сейчас протестил построение дашбордов 3 секунды, как и их обновление. Но у нас данных на порядок меньше (миллионы строк), вам же остаётся как-то агрегировать данные.
Спасибо за статью, очень полезный материал. Exasol или Kinetica в качестве движка для Tableau, говорят, можно использовать.
Да, если поставить более быструю базу должно работать быстрее. Но, как я писал, в целом БД то отвечает за разумное время. Когда дашборд работает за 6-8 секунд, все запросы к базе отрабатывают в пределах 1 секунды. Из-за связанных фильтров вызов части запросов идет последовательно, поэтому время работы дашборда увеличивается.
Конечно если БД будет быстрее раз в 10-ть, то наверное скорость работы дашборда сократиться до 3-4 секунд. Но это все равно долго.
Самое интересное по этой теме, что я находил были GPU DB Kinetica и SQream. По их собственным заявлениям они быстрея и Exasol и HANA и даже ClickHouse, но внедрений то промышленных нет… А железо стоит ой как не дешево…
Конечно если БД будет быстрее раз в 10-ть, то наверное скорость работы дашборда сократиться до 3-4 секунд. Но это все равно долго.
Самое интересное по этой теме, что я находил были GPU DB Kinetica и SQream. По их собственным заявлениям они быстрея и Exasol и HANA и даже ClickHouse, но внедрений то промышленных нет… А железо стоит ой как не дешево…
Вообще Tableau философию другую продвигает. Нет смысла в BI держать все детальные данные. В основном нужна такая визуализация, которая даст инсайт для принятия управленческого решения. И ее надо найти. Обычно она строится на агрегатах
Коллеги, добрый день!
Интересная проблема, я ее решил для Ашан РФ и Восточной Европы (Украина, Румыния, Венгрия) в 2013 году. ~~ Статистика:
1. ~400 млн чеков в год (1.2 млрд за 3 года), ~4 млрд линий чеков в год (12 млрд за 3 года) или ~1 млрд записей продаж на уровне товара в год (3 млрд за 3 года)
2. ~400 магазинов, ~50 регионов, ~5 форматов, ~4 канала продаж (гипер, супер, магазин у дома, интернет). Сбор чеков, кстати, в реальном времени со всех магазинов :)
3. ~5000 поставщиков
4. Периоды: День Неделя Месяц Год, возможны динамические периоды, несколько календарей
5. Товарный справочник: >2 млн разных товаров, продаваемых в год ~200 тыс. Номенклатура: 100 категорий (уровень менеджеров продаж, бюджетирования), 1000 под-категорий. Может меняться (SCD)
6. Количество пользователей: ~5000 (в крупных магазинах около 50 в мелких 5-10), систему используют 24/7 в том числе на мобильных устройствах
7. Показатели: более 10 основных (продажи, чеки, количества (шт, вес), маржа, референции (distinct), запас, списания, потери и тд) и более 50 синтетических (сравнения с прошлым годом, доли, нарастающим итогом, сравнения нарастающего итога и тд).
8. Агрегаты по сравнительным магазинам (like for like) в том числе динамически по годам
9. Отчеты — более 100. Основных 30.
10. Самый используемый дашборд: 300 магазинов и 30 показателей (comparative) или 100 категорий (comparative) latency менее 2 сек. включая динамический агрегат like for like.
11. Основные сравнительный дашборды по магазинам и категориям работают на мобильных устройствах (Retail Cockpit), REST API
12. Отчетность доступна 24/7, требования 7 утра в каждом часовом поясе по все стране и Восточной Европе
Буду рад встретиться, рассказать подробно. На базе этой системы есть много модулей расширений
Моя компания — Retail Data Factory redfactory.io
Мой профиль: www.linkedin.com/in/kirill-boyko-362a4117
С уважением,
Кирилл Бойко
Интересная проблема, я ее решил для Ашан РФ и Восточной Европы (Украина, Румыния, Венгрия) в 2013 году. ~~ Статистика:
1. ~400 млн чеков в год (1.2 млрд за 3 года), ~4 млрд линий чеков в год (12 млрд за 3 года) или ~1 млрд записей продаж на уровне товара в год (3 млрд за 3 года)
2. ~400 магазинов, ~50 регионов, ~5 форматов, ~4 канала продаж (гипер, супер, магазин у дома, интернет). Сбор чеков, кстати, в реальном времени со всех магазинов :)
3. ~5000 поставщиков
4. Периоды: День Неделя Месяц Год, возможны динамические периоды, несколько календарей
5. Товарный справочник: >2 млн разных товаров, продаваемых в год ~200 тыс. Номенклатура: 100 категорий (уровень менеджеров продаж, бюджетирования), 1000 под-категорий. Может меняться (SCD)
6. Количество пользователей: ~5000 (в крупных магазинах около 50 в мелких 5-10), систему используют 24/7 в том числе на мобильных устройствах
7. Показатели: более 10 основных (продажи, чеки, количества (шт, вес), маржа, референции (distinct), запас, списания, потери и тд) и более 50 синтетических (сравнения с прошлым годом, доли, нарастающим итогом, сравнения нарастающего итога и тд).
8. Агрегаты по сравнительным магазинам (like for like) в том числе динамически по годам
9. Отчеты — более 100. Основных 30.
10. Самый используемый дашборд: 300 магазинов и 30 показателей (comparative) или 100 категорий (comparative) latency менее 2 сек. включая динамический агрегат like for like.
11. Основные сравнительный дашборды по магазинам и категориям работают на мобильных устройствах (Retail Cockpit), REST API
12. Отчетность доступна 24/7, требования 7 утра в каждом часовом поясе по все стране и Восточной Европе
Буду рад встретиться, рассказать подробно. На базе этой системы есть много модулей расширений
Моя компания — Retail Data Factory redfactory.io
Мой профиль: www.linkedin.com/in/kirill-boyko-362a4117
С уважением,
Кирилл Бойко
Sign up to leave a comment.
Tableau в рознице, реально?