Поднимать в In-Memory можно из любого хранилища, без разницы, вы правы. Имелось ввиду, что именно в памяти данные лежат по колонкам.
А вот в случае ROLAP архитектуры с запросами к распределенной СУБД колоночное дисковое хранилище становится очень актуальным, потому что помогает сильно уменьшить количество обращений к диску.
Если говорить про In-Memory OLAP, то там, как правило, все данные будут в памяти одной ноды, причем движок может даже сам заранее "сджойнить" таблицы. А если данные лежат в кластере, то там у всех аналитических СУБД свои стратегии шардирования. Но вообще принцип похожий — максимальная денормализация и объединение колонок в одной таблице. Иначе, как вы правильно заметили, джойны и функции от нескольких аргументов будут так замедлять исполнение запроса, что это будет уже не онлайн.
А в понятие AIOps как-то входит мониторинг вещей, связанных с кибербезопасностью? Или это исключительно про инфраструктуру и работоспособность сервисов?
Я к тому, что если сервис упал, это может произойти в том числе и в результате атаки, причем понять точную причину иногда очень трудно. Тут как AIOps может помочь?
Тут, как мне кажется, есть две составляющие ответа на этот вопрос:
Что выгоднее? Если в вашем продукте просто есть несколько дашбордов, которые редко меняются, обычно лучше сделать их просто вручную in-house. А если объем отчетности значительный, она изменяется еженедельно и, самое главное, надо дать конечным пользователям возможность самим настраивать дашборды и отчеты, то надо серьезно задуматься об использовании стороннего аналитического решения — не обязательно нашего, OEM и White label варианты лицензирования есть почти у всех BI вендоров, а где-то и open-source решений будет достаточно (типа Grafana или Superset). Тут уже надо аккуратно посчитать трудозатраты и "TCO" для всех вариантов.
Риски и контроль. Как я писал в статье, любая внешняя зависимость — это потенциальные риски для проекта. Что будет, если поставщик решит изменить схему лицензирования? Что если его фокус развития продукта разойдется с вашими потребностями? Насколько хорошо вы лично знаете команду продукта и доверяете ей? Тут главное, такой список рисков составить и учитывать его при принятии окончательного решения.
Если вопрос про то, на какие средства велась разработка платформы до того, как пошли продажи, то тут никакого секрета нет. В Visiology инвестировала компания Polymedia, из которой мы и вышли изначально.
По восприятию — вам решать, но все наши сайты мы несколько лет назад перевели на тильду и супер довольны результатом. Раньше у нас для сайтов использовался целый ассортимент технологий от ASP.NET до Битрикса, и главная проблема была в том, что для внесения изменений постоянно приходилось отвлекать разработчиков от основных задач (которых у них выше крыши). Сейчас 80% задач по поддержке сайта закрываются маркетологами самостоятельно, а на оставшиеся привлекаем фрилансеров “универсалов”. Конечно, иногда тильда ограничивает полет фантазии, но тут уж ничего не поделать, это плата за простоту поддержки.
Для малого бизнеса облако — отличный вариант, и действительно, многие BI-вендоры активно переходят к SaaS модели (или изначально ее выбирают, как Yandex DataLens). Но крупные компании абсолютно не готовы отдавать свои чувствительные данные в облака. И это характерно не только для России — вот свежий обзор от BARC Research, из которого видно, что по всему миру облачной аналитике сами корпоративные пользователи придают гораздо меньше значения, чем вендоры — http://barc-research.com/research/bi-trend-monitor/. Поскольку наш целевой сегмент — это именно большие компании, то и облачную версию Visiology мы пока делать не планируем, просто нет спроса.
Оговорюсь, что это все касается публичных облачных сервисов, SaaS. Облако в режиме IaaS, конечно, многие применяют. У нас уже сейчас больше половины пилотных проектов живут в Yandex Compute Cloud.
Хочу отметить, что помимо БИТ: Финанс есть и другие российские платформы, более близкие к Hyperion/Cognos по идеологии, например, ПланФакт для SMB или Visiology для крупных компаний.
Если ваш софт под лицензией GPL, то вы не можете его продавать — тогда вам и реестр не нужен, так как его единственное назначение — предоставление преимуществ на госзакупках.
Если же у вас в составе софта используются какие-то библиотеки под GPL, без которых софт не может работать, то переподайте заявку следующим образом: исключите эти библиотеки из дистрибутива, а в инструкции по установке напишите, как эксперт может самостоятельно их скачать и поставить, чтобы ваш софт заработал.
В этом случае будет соблюдена и буква, и смысл закона — вы представите на экспертизу только то, что вы разработали, на что вы реально имеете исключительные права.
В моем понимании, эта норма создан для защиты реестра от любителей взять open-source, изменить цвет GUI и копирайты, и вперёд.
А не оценивали идею сделать следующий шаг, и сами преобразования тоже в Airflow сделать в виде Python/SQL операторов? Не стали так делать из-за трудоемкости миграции или по другим соображениям?
А в какой момент все работники подписывают согласие на обработку своих биометрических данных? И имеют ли они возможность от этого отказаться, не потеряв работу?
Ну из известных навскидку — Прогноз (Форсайт), Visiology, Полиматика. Я в одной из этих компаний работаю, поэтому не буду ссылки кидать, чтобы не сочли за рекламу. В данном случае интересно было именно — смотрели или нет, какие результаты.
Не думаю, что это подойдёт всем, но могу рассказать, как я для себя полностью решил эту проблему. Я сам далеко от фриланса, но вот эта тема, когда ты даже в отпуске на связи, в делах, постоянно контролируешь почту и в результате не отдыхаешь — она мне близка.
Решение — экстремальный туризм вообще и альпинизм в частности. Раз в год я еду на 7-10 дней в место, в котором НЕТ мобильной связи — горные или пустынные районы Алтая, Кавказа, Казахстана, в Сахару ходил один раз. Там добавляются жёсткие изнуряющие физические нагрузки (можно 4 часа идти на пределе в гору, и в голове только "правая… левая..."), которые вознаграждаются чувством свершения и наслаждения простыми вещами, когда заходишь на перевал из последних сил, садишься на камень, кладешь в рот маленький кусочек шоколадки и просто, ни о чем не думая, балдеешь от захватывающего вида и чувства расслабления. Ещё, конечно, общение в команде с друзьями, на которых в обычное время так мало времени остаётся. Плюс — преодоление самого себя и тренировка силы воли (в три часа ночи на штурм в -20 вылезти из теплого спальничка — это просто за гранью добра и зла:) )
Все это вместе так замечательно прочищает и тренирует мозг (и тело, на самом деле), что в цивилизацию ты возвращаешься другим человеком. Лично для меня прививка действует примерно год, потом надо повторять)
Ещё раз — метод, наверное, не для всех, но если кто-то задумывается об этом и сомневается — рекомендую хотя бы раз попробовать.
Полностью согласен с изложенным. Сам неоднократно сталкивался с этой проблемой — в основном в визуальных инструментах ETL, но и в BPM системах тоже. Визуальный инструмент разработки красив на презентациях, обеспечивает быстрый quick start для людей, не имеющих опыта написания кода, но в мало-мальски сложном внедрении быстро становится ограничением — не хватает хорошей отладки, гибкости, абстракций. Кроме того, когда начинаешь дописывать код, часть системы, управляемая визуальным конструктором, обычно остается плохо документированным черным ящиком, с которым приходится работать методом проб и ошибок.
С другой стороны, понятно, откуда это все берется — любой заказчик старается избегать кода при внедрении, и для вендора проще сделать визуальный конструктор (причем в некоторых случаях реально абы-как), чем объяснять, как должен выглядеть зрелый процесс поддержки конфигурации системы.
Допускаю, что могут быть кейсы, где визуальные конструкторы хороши, но они тогда должны покрывать 95% нужной функциональности — а это точно не про enterprise внедрения.
Поднимать в In-Memory можно из любого хранилища, без разницы, вы правы. Имелось ввиду, что именно в памяти данные лежат по колонкам.
А вот в случае ROLAP архитектуры с запросами к распределенной СУБД колоночное дисковое хранилище становится очень актуальным, потому что помогает сильно уменьшить количество обращений к диску.
Если говорить про In-Memory OLAP, то там, как правило, все данные будут в памяти одной ноды, причем движок может даже сам заранее "сджойнить" таблицы. А если данные лежат в кластере, то там у всех аналитических СУБД свои стратегии шардирования. Но вообще принцип похожий — максимальная денормализация и объединение колонок в одной таблице. Иначе, как вы правильно заметили, джойны и функции от нескольких аргументов будут так замедлять исполнение запроса, что это будет уже не онлайн.
А в понятие AIOps как-то входит мониторинг вещей, связанных с кибербезопасностью? Или это исключительно про инфраструктуру и работоспособность сервисов?
Я к тому, что если сервис упал, это может произойти в том числе и в результате атаки, причем понять точную причину иногда очень трудно. Тут как AIOps может помочь?
Тут, как мне кажется, есть две составляющие ответа на этот вопрос:
Некоторые так его называют, он, вроде, не обижается. Но кто знает, что там в "голове" у этого искусственного интеллекта :)
Если вопрос про то, на какие средства велась разработка платформы до того, как пошли продажи, то тут никакого секрета нет. В Visiology инвестировала компания Polymedia, из которой мы и вышли изначально.
По восприятию — вам решать, но все наши сайты мы несколько лет назад перевели на тильду и супер довольны результатом. Раньше у нас для сайтов использовался целый ассортимент технологий от ASP.NET до Битрикса, и главная проблема была в том, что для внесения изменений постоянно приходилось отвлекать разработчиков от основных задач (которых у них выше крыши). Сейчас 80% задач по поддержке сайта закрываются маркетологами самостоятельно, а на оставшиеся привлекаем фрилансеров “универсалов”. Конечно, иногда тильда ограничивает полет фантазии, но тут уж ничего не поделать, это плата за простоту поддержки.
Для малого бизнеса облако — отличный вариант, и действительно, многие BI-вендоры активно переходят к SaaS модели (или изначально ее выбирают, как Yandex DataLens). Но крупные компании абсолютно не готовы отдавать свои чувствительные данные в облака. И это характерно не только для России — вот свежий обзор от BARC Research, из которого видно, что по всему миру облачной аналитике сами корпоративные пользователи придают гораздо меньше значения, чем вендоры — http://barc-research.com/research/bi-trend-monitor/. Поскольку наш целевой сегмент — это именно большие компании, то и облачную версию Visiology мы пока делать не планируем, просто нет спроса.
Оговорюсь, что это все касается публичных облачных сервисов, SaaS. Облако в режиме IaaS, конечно, многие применяют. У нас уже сейчас больше половины пилотных проектов живут в Yandex Compute Cloud.
Спасибо за статью. Плюсы-минусы bottom-up и top-down планирования еще хорошо разобраны в курсе "Budgeting essentials" на курсере, рекомендую интересующимся — https://www.coursera.org/learn/budgeting-essentials-development
Хочу отметить, что помимо БИТ: Финанс есть и другие российские платформы, более близкие к Hyperion/Cognos по идеологии, например, ПланФакт для SMB или Visiology для крупных компаний.
Если ваш софт под лицензией GPL, то вы не можете его продавать — тогда вам и реестр не нужен, так как его единственное назначение — предоставление преимуществ на госзакупках.
Если же у вас в составе софта используются какие-то библиотеки под GPL, без которых софт не может работать, то переподайте заявку следующим образом: исключите эти библиотеки из дистрибутива, а в инструкции по установке напишите, как эксперт может самостоятельно их скачать и поставить, чтобы ваш софт заработал.
В этом случае будет соблюдена и буква, и смысл закона — вы представите на экспертизу только то, что вы разработали, на что вы реально имеете исключительные права.
В моем понимании, эта норма создан для защиты реестра от любителей взять open-source, изменить цвет GUI и копирайты, и вперёд.
С чего вы взяли, что борьба за эффективность вошла в "вялотекущую" стадию? Есть какая-то статистика?
А не оценивали идею сделать следующий шаг, и сами преобразования тоже в Airflow сделать в виде Python/SQL операторов? Не стали так делать из-за трудоемкости миграции или по другим соображениям?
Ну из известных навскидку — Прогноз (Форсайт), Visiology, Полиматика. Я в одной из этих компаний работаю, поэтому не буду ссылки кидать, чтобы не сочли за рекламу. В данном случае интересно было именно — смотрели или нет, какие результаты.
А российские варианты не смотрели?
Не думаю, что это подойдёт всем, но могу рассказать, как я для себя полностью решил эту проблему. Я сам далеко от фриланса, но вот эта тема, когда ты даже в отпуске на связи, в делах, постоянно контролируешь почту и в результате не отдыхаешь — она мне близка.
Решение — экстремальный туризм вообще и альпинизм в частности. Раз в год я еду на 7-10 дней в место, в котором НЕТ мобильной связи — горные или пустынные районы Алтая, Кавказа, Казахстана, в Сахару ходил один раз. Там добавляются жёсткие изнуряющие физические нагрузки (можно 4 часа идти на пределе в гору, и в голове только "правая… левая..."), которые вознаграждаются чувством свершения и наслаждения простыми вещами, когда заходишь на перевал из последних сил, садишься на камень, кладешь в рот маленький кусочек шоколадки и просто, ни о чем не думая, балдеешь от захватывающего вида и чувства расслабления. Ещё, конечно, общение в команде с друзьями, на которых в обычное время так мало времени остаётся. Плюс — преодоление самого себя и тренировка силы воли (в три часа ночи на штурм в -20 вылезти из теплого спальничка — это просто за гранью добра и зла:) )
Все это вместе так замечательно прочищает и тренирует мозг (и тело, на самом деле), что в цивилизацию ты возвращаешься другим человеком. Лично для меня прививка действует примерно год, потом надо повторять)
Ещё раз — метод, наверное, не для всех, но если кто-то задумывается об этом и сомневается — рекомендую хотя бы раз попробовать.
Не в тему, но все же — откуда иллюстрации в статье, кто художник? Есть в них что-то сильное и тяжёлое.
По теме — упомянутая NORMA — это полностью ваша собственная разработка? С чем вы конкурируете этим продуктом?
Даже не могу описать, как благодарен вам за совет с JS. Реально работает.
Полностью согласен с изложенным. Сам неоднократно сталкивался с этой проблемой — в основном в визуальных инструментах ETL, но и в BPM системах тоже. Визуальный инструмент разработки красив на презентациях, обеспечивает быстрый quick start для людей, не имеющих опыта написания кода, но в мало-мальски сложном внедрении быстро становится ограничением — не хватает хорошей отладки, гибкости, абстракций. Кроме того, когда начинаешь дописывать код, часть системы, управляемая визуальным конструктором, обычно остается плохо документированным черным ящиком, с которым приходится работать методом проб и ошибок.
С другой стороны, понятно, откуда это все берется — любой заказчик старается избегать кода при внедрении, и для вендора проще сделать визуальный конструктор (причем в некоторых случаях реально абы-как), чем объяснять, как должен выглядеть зрелый процесс поддержки конфигурации системы.
Допускаю, что могут быть кейсы, где визуальные конструкторы хороши, но они тогда должны покрывать 95% нужной функциональности — а это точно не про enterprise внедрения.