Да, чтобы высчитать ROI тоже нужно время и определенные навыки, да ещё и опыт - чтоб не ошибиться в своих прогнозах. Планируем отдельную статью где будет более подробно написано, почему мы всё же решились такую команду сформировать и это направление открыть. Нам внутри Дата-офиса субъективно кажется, что работа стала эффективнее P.S. 5 новых человек мы не добавляли. Новых ставок не появилось. Мы перераспределили набор людей внутри Дата-Офиса. Мы забрали из команд поставки 3 ETL-разработчиков и из платформы 2 вакансии переделали под DQ Поэтому нам внутри Дата-офиса субъективно кажется, что это того стоило. А объективность этому прибавляет то, что у нас сейчас в команде более 40 задач в бэклоге от бизнеса и большинство не про доработку инструмента, а именно про бизнес-кейсы.
Вообще думаю реально. Просто нам с коллегами было проще это сделать. Так как поиск специалистов нужных занимает время, и так же есть риск, что продукт не взлетит - не будет спроса, то что делать с набранными людьми... Поэтому у нас получилось на мой взгляд классно - мы начали с того, что выделили трех сотрудников из Дата Офиса, которые занимались в основном ETL на эту активность, они продумали архитектуру, помогали с продвижением и поиском потенциальных "мест" использования, а коллеги-подрядчики быстро вывели к нам ребят с нужными hard-скилами и помогли этот MVP написать на старте. К моменту когда мы взяли к себе в штат backend'ера - уже было понятно, что продукт востребован и "полет нормальный" Ну и кстати, фронт то мы вообще внутренней командой сделали, один из ETL-разработчиков изучил параллельно bootstrap фреймворк и буквально за две недели у нас появилась первая очень простая, но рабочая версия web-интерфейса пользователя Поэтому если готовы рискнуть - думаю такой продукт можно сделать и без подрядчика. Но с ними я бы сказал спокойнее) (как говорится одна голова хорошо, а две лучше)
На старте команда была 6 человек. 3 от команды Сапиенс, 3 внутри. Потом команда то чуть росла, то чуть уменьшалась. Прямо сейчас команда 5 человек. Мы обучили много команд ETL-разработки и аналитиков в компании, поэтому многие уже начали заводить проверки. И не смотря на то что команда у нас сейчас всего 5 человек мы успеваем и дорабатывать инструмент и помогать бизнесу с новыми проверками. Поэтому чтобы посчитать стоимость можно взять 6 разработчиков и посчитать их з.п. За 5 месяцев - это будет первоначальная версия - старт MVP. За 9 месяцев - текущее состояние. А насчет закопали - мы считаем это инвестициями и надеемся что семена эти прорастут и принесут плоды. В целом те кейсы по бизнесу, что уже мы закрыли через инструмент уже окупают наши трудозатраты.
Да, если поставить более быструю базу должно работать быстрее. Но, как я писал, в целом БД то отвечает за разумное время. Когда дашборд работает за 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 был, но это десятки секунд
В сторону 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 недели точно сократить.
В компании около 15 человек с компетенциями в ML, глубокой аналитики и прогнозах. А аналитиков данных в офисе данных и бизнес-функциях около 100
Спасибо!
Да, мы знаем что есть ещё много над чем работать!
Будем улучшаться
Да, чтобы высчитать ROI тоже нужно время и определенные навыки, да ещё и опыт - чтоб не ошибиться в своих прогнозах.
Планируем отдельную статью где будет более подробно написано, почему мы всё же решились такую команду сформировать и это направление открыть.
Нам внутри Дата-офиса субъективно кажется, что работа стала эффективнее
P.S. 5 новых человек мы не добавляли. Новых ставок не появилось. Мы перераспределили набор людей внутри Дата-Офиса. Мы забрали из команд поставки 3 ETL-разработчиков и из платформы 2 вакансии переделали под DQ
Поэтому нам внутри Дата-офиса субъективно кажется, что это того стоило. А объективность этому прибавляет то, что у нас сейчас в команде более 40 задач в бэклоге от бизнеса и большинство не про доработку инструмента, а именно про бизнес-кейсы.
Вообще думаю реально.
Просто нам с коллегами было проще это сделать. Так как поиск специалистов нужных занимает время, и так же есть риск, что продукт не взлетит - не будет спроса, то что делать с набранными людьми...
Поэтому у нас получилось на мой взгляд классно - мы начали с того, что выделили трех сотрудников из Дата Офиса, которые занимались в основном ETL на эту активность, они продумали архитектуру, помогали с продвижением и поиском потенциальных "мест" использования, а коллеги-подрядчики быстро вывели к нам ребят с нужными hard-скилами и помогли этот MVP написать на старте.
К моменту когда мы взяли к себе в штат backend'ера - уже было понятно, что продукт востребован и "полет нормальный"
Ну и кстати, фронт то мы вообще внутренней командой сделали, один из ETL-разработчиков изучил параллельно bootstrap фреймворк и буквально за две недели у нас появилась первая очень простая, но рабочая версия web-интерфейса пользователя
Поэтому если готовы рискнуть - думаю такой продукт можно сделать и без подрядчика. Но с ними я бы сказал спокойнее) (как говорится одна голова хорошо, а две лучше)
На старте команда была 6 человек. 3 от команды Сапиенс, 3 внутри. Потом команда то чуть росла, то чуть уменьшалась. Прямо сейчас команда 5 человек. Мы обучили много команд ETL-разработки и аналитиков в компании, поэтому многие уже начали заводить проверки. И не смотря на то что команда у нас сейчас всего 5 человек мы успеваем и дорабатывать инструмент и помогать бизнесу с новыми проверками.
Поэтому чтобы посчитать стоимость можно взять 6 разработчиков и посчитать их з.п. За 5 месяцев - это будет первоначальная версия - старт MVP. За 9 месяцев - текущее состояние.
А насчет закопали - мы считаем это инвестициями и надеемся что семена эти прорастут и принесут плоды. В целом те кейсы по бизнесу, что уже мы закрыли через инструмент уже окупают наши трудозатраты.
Демьян , в каком именно "месте"?
Полная стоимость разработки данного инструмента?
Конечно если БД будет быстрее раз в 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, работаем над этим. Само хранилище на таких витринах работает очень шустро.
HADOOP и наша цель делать выборки из таблиц в 2-3 млрд. строк за 0,1-0,5 секунды у меня друг с другом не вяжутся.
Опыт работы с HIVE и HBASE был, но это десятки секунд
Я правильно понимаю, что имеется ввиду Tibco Spotfire?
А с какими объемами данных работаете? Над какими БД построена отчетность?
Мы хотели построить в Tableau дашборды для self-service аналитики top и middle менеджмента компании.
Основной критерии описал выше. Полный скоринг выглядел вот так:
Как видно, Tableau почти по всем направлениям, в важных для нас критериях оказывался предпочтителен.
Что касается кэширования в инструменте визуализации. Промежуточные слои есть везде. И в Power BI, SAP SAC, Qlik.
В Qlik, что смущало:
1. Qlik Sense достаточно молод. А Qlik View устарел и не пригоден был для наших потребностей по визуализации.
2. Qlik рисует свою модель данных, если же ее менять, то все преимущества qlik теряеются, и вы несете доп.косты. На текущий момент у нас есть большая модель данных для всей компании, рисовать такую же модель данных в еще одном инструменте не очень хочется, это если говорить про долгосрочные планы. Т.е. у нас была идея Tableau подключить к текущей моделе данных в HANA, с Qlik это было бы не возможно, так требуется модель делать в Qlik.
3. Qlik достаточно ресурсоемкий продукт, т.е. требовалась бы хорошие инвестиции в оборудование. В 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 недели точно сократить.
Нет HANA — это и есть БД