Спасибо за мнение. Что касается расходов, я же говорю про расходы организации, а не про то, сколько инженеры на руки получат. Налоги, ДМС, корпоративы/мероприятия, офис, техника, найм. В обычной компании можно считать х2 к ЗП, в ИТ компании с учетом льгот поменьше, но тоже далеко не 1 в 1. А по Monq, не знаю, под наши задачи вроде все есть, а там уже, конечно, надо смотреть под конкретную задачу. С другой стороны, они же доработки за свои деньги делают, так что с точки зрения клиента - это все равно может быть лучше, чем самому тратить на допил open-source. Но тут уже надо конкретный случай разбирать.
Очень круто и масштабно! Но с первого взгляда кажется очень сложным в разработке и поддержке, ну и вообще в нагрузке на инженеров. Вы сравнивали TCO с вариантом использования готового ПО а-ля Dynatrace? 20 инженеров - это миллионов 100 в год расходов. Понятно, что решения типа Dynatrace могут быть сейчас недоступны, но есть же и российские готовые решения, например, Monq. Мы смотрим на них сейчас, выглядит очень привлекательно.
А что касается загрузки "человекозаполняемых" Excel в BI, то по моему мнению и опыту, с точки зрения бизнеса - это зло. Потому что в этом случае BI перестает выполнять свою функцию источника качественных доверенных данных для принятия решений - все ошибки заполнения и импорта просто переезжают в отчеты. Понятно, что не все готовы к полной автоматизации всего (да это и не нужно часто), но если пачки Excel файлов уже возникли, значит есть потребность хотя бы в low-code автоматизации, благо, инструментов сейчас достаточно. В Visiology для решения этой задачи есть специальный модуль - Smart Forms.
Тут тоже оговорюсь, что в любом правиле бывают исключения, иногда пачки Excel файлов реально имеет смысл импортировать - для этого у Visiology есть специальный инструмент, ViLoader, как раз оптимизированный под работу с формами ручного ввода. Но по моему опыту - это даже не 1 из 10, а гораздо реже встречается.
Этот пример - это лишь одна из референсных архитектур, которую, кстати, часто используют и с Qlik/PBI/Tableau - очень много раз видел, когда ETL в Qlik используется только на уровне 'SELECT * FROM xxx.xxx', а все данные уже подготовлены на уровне КХД. Это дело вкуса и особенностей конкретной задачи. При желании всю модель можно и внутри Visiology сделать, более того, в третьей версии там гораздо больше возможностей, чем у традиционной снежинки/созвездия.
ETL, да, внешний - но можно использовать тот же самый ViXtract от Visiology - open-source и бесплатно. Действительно, для работы с ViXtract придется поразбираться с Python, но тут я выражу свое мнение, с которым вы, конечно, вправе не согласиться. Если смотреть с точки зрения специалиста, который хочет развиваться и оставаться востребованным, в 2023 году я бы лучше вкладывал силы в изучение Python для ETL, а не в проприетарный Qlik load script - и возможности шире, и компетенция более широко применима. А если говорить про язык аналитических запросов - то учил бы DAX, а не Qlik Expressions, потому что он уже больше 70% рынка занимает, по нему на порядки больше материалов доступно. Хотя, справедливости ради, у Qlik Expressions есть свои преимущества по сравнению с DAX, но не принципиальные.
Спасибо) А чего не хватило? Мне, если честно, фактуры по Decision Intelligence тоже не хватило - может, я что-то не заметил. Хотелось именно подсветить проблему.
Microstrategy - это точно очень крутой продукт (точнее, портфолио продуктов). Но, все-таки, как в концепции Microstrategy предлагается "расшивать" узкое место в виде подразделения, которое поддерживает актуальность единого семантического слоя? Ведь не все задачи требуют централизации, а ресурсы центра компетенций всегда ограничены. Я неоднократно видел, как в компаниях, в которых аналитика была исключительно централизованной, буйным цветом прорастали условные "Power BI Desktop", те самые Data Silos, которые очень трудно победить административными методами.
Я, как представитель одного из "объектов обзора", лицо заинтересованное, но предложил бы, все-таки, ознакомиться с содержанием обзора перед вынесением окончательного вердикта:) Работа реально большая проделана — хоть и не без недостатков, наверное (как и тот же квадрат Гартнера, впрочем). Аргументированная критика, думаю, всем будет полезна.
В базовой "комплектации" такие задачи сделать не получится, конечно. PETL был выбран как инструмент с минимальным порогом входа, а по производительности он уступает даже pandas (который при этом тоже грузит все данные в память). Так что для описанных задач уже нужно выбирать другие инструменты, хотя в качестве интерфейса/планировщика можно и оставить Jupyter, Python и Cronicle.
С Airflow не хотелось бы конкурировать, мы старались разделить позиционирование — Airflow для тяжелых продуктивных задач и опытных ETL разработчиков, ViXtract для простых и средних задач, пилотирования (PoC) и изучения данных аналитиками.
Спасибо за наводку на Java-based решения, изучим! По Python попробую еще раз объяснить логику выбора. Поскольку целевая аудитория ViXtract — это не разработчики, а именно аналитики, нужно было выбрать язык с минимальным порогом входа. Python в этом плане лидер, по крайней мере, в общественном мнении. Ну и еще у Python есть большой плюс именно для аналитиков — он является основным инструментом для Data Scientist, поэтому если аналитик решает развиваться в этом направлении (что логичнее, чем в сторону разработчика), то он может переиспользовать полученные опыт и знания.
Да, дублирование возникает, это минус предложенного решения. Вопрос, что в конкретном проекте более значительно — дополнительные затраты на сопровождение или потери на коммуникациях между аналитиками и разработчиками. Кроме того, есть гипотеза, что во многих проектах (не во всех, конечно) можно обойтись и чисто ViXtract. Тот же Cronicle поддерживает и работу в кластере, и может обеспечивать очень хорошие параметры по надежности. Понятно, что ключевая проблема в том, что сборка не имеет коммерческой поддержки, но, если будет серьезный интерес со стороны корпораций, это можно и исправить.
А в JupyterHub, а не в PyCharm, например, потому что:
Интерактивно работать с кодом и постоянно его исправлять в Jupyter проще, чем работать с отладчиком (для не очень опытного человека в разработке)
Поскольку код сразу запускается на сервере, нет вечных проблем в различии окружений на сервере и локальном компьютере (библиотеки, пути, сетевая доступность, права)
Имея знания в Python и Jupyter, аналитику уже гораздо проще сделать шаг в сторону Data Science, а это логичный путь развития для аналитика
Он никому ничего не должен, конечно. Просто я видел в своей практике множество случаев, когда аналитик мог решить задачу загрузки данных в 5 строчек за час времени, а вместо этого он ставил задачу ETL разработчику и начиналось: разработчик что-то сделал, аналитик увидел, что на самом деле нужно немного по-другому, разработчик снова ушел делать, в это время задача от бизнеса немного поменялась и т.д. и т.п. В итоге задача растянулась на пять дней. Наверное, это не панацея для всех задач, но на начальных этапах проекта или в исследовательских задачах точно востребовано.
Идея в том, что аналитик без особого опыта в Python сразу на AirFlow писать не может, а на ViXtract — может. И в этом ему как раз помогают уже встроенные рекомендованные библиотеки. При этом никто не запрещает использовать pandas и что угодно еще, по мере развития компетенций. Что касается разработчика промышленного ETL — ему, конечно все это не нужно, ему лучше сразу писать на AirFlow. Ну и это все — идея/гипотеза, в которую мы верим, и которая пока на тестированиях подтверждается. Выстрелит ли это — рассудит сообщество.
Этот график, конечно, субъективен, расскажу свою логику. Tableau Prep находится посередине между простыми и enterprise решениями, потому что я никогда не видел и не слышал, чтобы на нем делали тяжелые преобразования в Data Lake / DWH, которые могут даже быть никак не связаны с BI. А для Airflow — это вообще основной кейс применения, он для этого был сделан в Airbnb. Pentaho, безусловно, очень сильно коммерциализировался, но в контексте рассматриваемой задачи базовый инструмент (который особо сильно не изменился со время Kettle), по-моему, остается бесплатным — поправьте, если ошибаюсь.
Если я правильно понял, то таким образом можно распознать взаимосвязь между метриками, если задержка до реакции в среднем не больше 5 минут. А что делать со связями с большим лагом? Типа, начал сильно перегреваться сервер, и через сутки полетел диск.
Да, описание иногда сложное, особенно, если какой-нибудь нетривиальный временной период пользователь выберет. Типа, "сравни выручку в текущем квартале с выручкой на аналогичную дату прошлого квартала". Но тут вопрос — как еще можно добиться доверия к ответу бота? Потому что, если не выводить интерпретацию запроса, вообще никак нельзя проверить, правильно ли он тебя понял.
Зарубежные коллеги сейчас ну очень часто говорят про Snowflake (Северная Америка, по крайней мере). Давно хочу попробовать, но, действительно, спроса на российском рынке на такое не видно. Интересно, есть вообще в России примеры внедрений?
ClickHouse, конечно, очень быстрый. В режиме одного узла скорость исполнения аналогичных запросов получается примерно одинаковая. Но если сравнивать производительность именно BI системы в целом, то Visiology на базе ViQube будет гораздо лучше работать, чем, например, Mondrian+ClickHouse за счет правильной работы с кэшем, более эффективной трансляции многомерных запросов в табличные и т.п. А вот когда нужен кластер с шардированием — тут ROLAP с ClickHouse (или его коммерческой версией Arenadata QuickMarts) вне конкуренции.
Основной кейс для ViQube — это работа с горячими данными, ориентировочно 200-300 ГБ. Для всего, что больше этого, мы как раз интегрируемся с распределенными аналитическими СУБД, такими как Vertica и ClickHouse. Эта интеграция у нас появилась в этом году, и мы только совсем недавно стартовали несколько проектов с серьезным объемом DWH (там, правда, поменьше петабайта все-таки планируется, скорее, 10-100 ТБ). Надеюсь, там все пройдет успешно, и сможем в следующем году про них публично рассказать.
Спасибо за мнение. Что касается расходов, я же говорю про расходы организации, а не про то, сколько инженеры на руки получат. Налоги, ДМС, корпоративы/мероприятия, офис, техника, найм. В обычной компании можно считать х2 к ЗП, в ИТ компании с учетом льгот поменьше, но тоже далеко не 1 в 1. А по Monq, не знаю, под наши задачи вроде все есть, а там уже, конечно, надо смотреть под конкретную задачу. С другой стороны, они же доработки за свои деньги делают, так что с точки зрения клиента - это все равно может быть лучше, чем самому тратить на допил open-source. Но тут уже надо конкретный случай разбирать.
Очень круто и масштабно! Но с первого взгляда кажется очень сложным в разработке и поддержке, ну и вообще в нагрузке на инженеров. Вы сравнивали TCO с вариантом использования готового ПО а-ля Dynatrace? 20 инженеров - это миллионов 100 в год расходов. Понятно, что решения типа Dynatrace могут быть сейчас недоступны, но есть же и российские готовые решения, например, Monq. Мы смотрим на них сейчас, выглядит очень привлекательно.
А что касается загрузки "человекозаполняемых" Excel в BI, то по моему мнению и опыту, с точки зрения бизнеса - это зло. Потому что в этом случае BI перестает выполнять свою функцию источника качественных доверенных данных для принятия решений - все ошибки заполнения и импорта просто переезжают в отчеты. Понятно, что не все готовы к полной автоматизации всего (да это и не нужно часто), но если пачки Excel файлов уже возникли, значит есть потребность хотя бы в low-code автоматизации, благо, инструментов сейчас достаточно. В Visiology для решения этой задачи есть специальный модуль - Smart Forms.
Тут тоже оговорюсь, что в любом правиле бывают исключения, иногда пачки Excel файлов реально имеет смысл импортировать - для этого у Visiology есть специальный инструмент, ViLoader, как раз оптимизированный под работу с формами ручного ввода. Но по моему опыту - это даже не 1 из 10, а гораздо реже встречается.
Этот пример - это лишь одна из референсных архитектур, которую, кстати, часто используют и с Qlik/PBI/Tableau - очень много раз видел, когда ETL в Qlik используется только на уровне 'SELECT * FROM xxx.xxx', а все данные уже подготовлены на уровне КХД. Это дело вкуса и особенностей конкретной задачи. При желании всю модель можно и внутри Visiology сделать, более того, в третьей версии там гораздо больше возможностей, чем у традиционной снежинки/созвездия.
ETL, да, внешний - но можно использовать тот же самый ViXtract от Visiology - open-source и бесплатно. Действительно, для работы с ViXtract придется поразбираться с Python, но тут я выражу свое мнение, с которым вы, конечно, вправе не согласиться. Если смотреть с точки зрения специалиста, который хочет развиваться и оставаться востребованным, в 2023 году я бы лучше вкладывал силы в изучение Python для ETL, а не в проприетарный Qlik load script - и возможности шире, и компетенция более широко применима. А если говорить про язык аналитических запросов - то учил бы DAX, а не Qlik Expressions, потому что он уже больше 70% рынка занимает, по нему на порядки больше материалов доступно. Хотя, справедливости ради, у Qlik Expressions есть свои преимущества по сравнению с DAX, но не принципиальные.
Спасибо) А чего не хватило? Мне, если честно, фактуры по Decision Intelligence тоже не хватило - может, я что-то не заметил. Хотелось именно подсветить проблему.
Microstrategy - это точно очень крутой продукт (точнее, портфолио продуктов). Но, все-таки, как в концепции Microstrategy предлагается "расшивать" узкое место в виде подразделения, которое поддерживает актуальность единого семантического слоя? Ведь не все задачи требуют централизации, а ресурсы центра компетенций всегда ограничены. Я неоднократно видел, как в компаниях, в которых аналитика была исключительно централизованной, буйным цветом прорастали условные "Power BI Desktop", те самые Data Silos, которые очень трудно победить административными методами.
Я, как представитель одного из "объектов обзора", лицо заинтересованное, но предложил бы, все-таки, ознакомиться с содержанием обзора перед вынесением окончательного вердикта:) Работа реально большая проделана — хоть и не без недостатков, наверное (как и тот же квадрат Гартнера, впрочем). Аргументированная критика, думаю, всем будет полезна.
Возникают ли сложности с выражением в деньгах отклонений метрик от SLA со стороны клиента? Как справляетесь с этим?
В базовой "комплектации" такие задачи сделать не получится, конечно. PETL был выбран как инструмент с минимальным порогом входа, а по производительности он уступает даже pandas (который при этом тоже грузит все данные в память). Так что для описанных задач уже нужно выбирать другие инструменты, хотя в качестве интерфейса/планировщика можно и оставить Jupyter, Python и Cronicle.
С Airflow не хотелось бы конкурировать, мы старались разделить позиционирование — Airflow для тяжелых продуктивных задач и опытных ETL разработчиков, ViXtract для простых и средних задач, пилотирования (PoC) и изучения данных аналитиками.
Спасибо за наводку на Java-based решения, изучим! По Python попробую еще раз объяснить логику выбора. Поскольку целевая аудитория ViXtract — это не разработчики, а именно аналитики, нужно было выбрать язык с минимальным порогом входа. Python в этом плане лидер, по крайней мере, в общественном мнении. Ну и еще у Python есть большой плюс именно для аналитиков — он является основным инструментом для Data Scientist, поэтому если аналитик решает развиваться в этом направлении (что логичнее, чем в сторону разработчика), то он может переиспользовать полученные опыт и знания.
Да, дублирование возникает, это минус предложенного решения. Вопрос, что в конкретном проекте более значительно — дополнительные затраты на сопровождение или потери на коммуникациях между аналитиками и разработчиками. Кроме того, есть гипотеза, что во многих проектах (не во всех, конечно) можно обойтись и чисто ViXtract. Тот же Cronicle поддерживает и работу в кластере, и может обеспечивать очень хорошие параметры по надежности. Понятно, что ключевая проблема в том, что сборка не имеет коммерческой поддержки, но, если будет серьезный интерес со стороны корпораций, это можно и исправить.
А в JupyterHub, а не в PyCharm, например, потому что:
Он никому ничего не должен, конечно. Просто я видел в своей практике множество случаев, когда аналитик мог решить задачу загрузки данных в 5 строчек за час времени, а вместо этого он ставил задачу ETL разработчику и начиналось: разработчик что-то сделал, аналитик увидел, что на самом деле нужно немного по-другому, разработчик снова ушел делать, в это время задача от бизнеса немного поменялась и т.д. и т.п. В итоге задача растянулась на пять дней. Наверное, это не панацея для всех задач, но на начальных этапах проекта или в исследовательских задачах точно востребовано.
Если я правильно понял, то таким образом можно распознать взаимосвязь между метриками, если задержка до реакции в среднем не больше 5 минут. А что делать со связями с большим лагом? Типа, начал сильно перегреваться сервер, и через сутки полетел диск.
Спасибо за отзыв и предложение!
По эмбеддингам на Хабре есть хороший текст на русском с более подробным описанием: https://habr.com/ru/company/ods/blog/329410/
Да, описание иногда сложное, особенно, если какой-нибудь нетривиальный временной период пользователь выберет. Типа, "сравни выручку в текущем квартале с выручкой на аналогичную дату прошлого квартала". Но тут вопрос — как еще можно добиться доверия к ответу бота? Потому что, если не выводить интерпретацию запроса, вообще никак нельзя проверить, правильно ли он тебя понял.
Зарубежные коллеги сейчас ну очень часто говорят про Snowflake (Северная Америка, по крайней мере). Давно хочу попробовать, но, действительно, спроса на российском рынке на такое не видно. Интересно, есть вообще в России примеры внедрений?
ClickHouse, конечно, очень быстрый. В режиме одного узла скорость исполнения аналогичных запросов получается примерно одинаковая. Но если сравнивать производительность именно BI системы в целом, то Visiology на базе ViQube будет гораздо лучше работать, чем, например, Mondrian+ClickHouse за счет правильной работы с кэшем, более эффективной трансляции многомерных запросов в табличные и т.п. А вот когда нужен кластер с шардированием — тут ROLAP с ClickHouse (или его коммерческой версией Arenadata QuickMarts) вне конкуренции.
Основной кейс для ViQube — это работа с горячими данными, ориентировочно 200-300 ГБ. Для всего, что больше этого, мы как раз интегрируемся с распределенными аналитическими СУБД, такими как Vertica и ClickHouse. Эта интеграция у нас появилась в этом году, и мы только совсем недавно стартовали несколько проектов с серьезным объемом DWH (там, правда, поменьше петабайта все-таки планируется, скорее, 10-100 ТБ). Надеюсь, там все пройдет успешно, и сможем в следующем году про них публично рассказать.