Все зависит от структуры данных и поставленных SLA. Зачастую даже объем не настолько критичен, как состав данных, которые нужно реплицировать в кратчайшие сроки с минимальным влиянием на продуктивные сервисы.
Повода для обновления не было — использовалась актуальная на тот момент версия прошивки. А о более продвинутом функционале расскажем во второй части статьи, уже скоро.
Да, мы не можем сказать, будет ли модель так же хорошо работать в условиях, которые никогда не наблюдались за последние пару лет. Например, при расходах воды в 2 раза выше, чем в обучающей выборке. Или при одновременной работе не четырех-шести насосов, а двух или десяти. Но для целей работы сервиса в этом нет необходимости. А если бы такие режимы и появились - модель была бы обновлена. Что же касается наблюдаемых режимов, метрики приведены в статье:
Точность прогноза потребляемой мощности, кстати, оказалась тоже довольно высокой, коэффициент детерминации R² = 0,99, а средняя абсолютная ошибка составила всего 40 кВт, при том что потребляемая мощность каждого насоса — около 2 МВт.
Энергоэффективными насосами в статье называются те, которые потребляют меньше электроэнергии на единицу объема подаваемой воды при заданном давлении. А энергоэффективность всей станции достигается за счет минимального потребления электроэнергии при требуемом расходе с учетом ограничения на минимально допустимое давление. Поэтому не всегда рекомендуется включать самый энергоэффективный насос. Иногда, если есть запас по давлению, выгоднее будет включить менее эффективный, но потребляющий меньше электроэнергии в абсолюте.
Схема изображена верно – насосы работают на общий коллектор из которого вода поступает на котлы. Для упрощения их изображено 3 штуки, но на самом деле котлов и деаэраторов больше. Нельзя утверждать, что каждый насос работает на определенный котел.
Вы правы на счет расходчика, спасибо за замечание. Я пытался упростить описание, но стоило изложить как есть. На самом деле расходомеров много, они установлены перед каждым из котлов. Таким образом нам все еще неизвестен расход питательной воды на каждом отдельном насосе, а известен лишь суммарный расход. Поправил этот момент в тексте.
Да, характеристики насосов ухудшаются с их наработкой. А ML как раз-таки полезен для мониторинга текущего состояния и результатов проведения капитального ремонта.
На ТЭЦ уже был внедрен подсказчик по оптимальному потреблению топлива котельными агрегатами, но цифровых проектов про оптимизации насосного оборудования ранее не было.
Рассмотренный выше пример не относится к теме статьи, но может возникнуть при ошибке проектирования насосной станции. На счет механизма страхующего от неполноты данных - если часть данных отсутствует, то прогноз и рекомендации не выдаются до возобновления передачи всех данных. Черным ящиком можно было назвать более сложные модели типа градиентного бустинга или нейронных сетей. В нашем же случае все модели легко интерпретируются и проверяются на непротиворечивость здравому смыслу. Оффтоп: для упомянутых выше нейронных сетей кстати существует physics-informed подход [ссылка], позволяющей сделать работу модели физичной.
Благодарю за замечание, вы абсолютно правы про разрыв потока в данной области графика. График для последовательного соединения убрал. Неточность на картинке допущена не по незнанию, а по невнимательности, так как основной темой статьи является параллельное соединение насосов. Для него, кстати, тоже можно придумать критическую ситуацию, когда один насос передавливает другой (насосные характеристики насосов сильно отличаются, а сопротивление сети высоко). Если так вдруг произошло, то, как и в вашем случае, это произошло из-за неверно подобранного оборудования при проектировании станции, но это не наш случай и мы такую "интересную" ситуацию не рассматриваем.
История там, на наш взгляд, еще более запутанная. То, что IBM отдал в комьюнити и было EVMS, а то, что потом стало LVM в привычном нам виде, - это синтаксис от HP-UX + код от IBM. Но это было очень давно.
Да, в Enterprise многие лимиты - это не что-то невероятное, а вполне достижимые значения.
Конечно! Очень хотелось "поместиться" в небольшую статью и сильно не выходить за рамки LVM, но породили неточность, что это исчерпывающий сиписок типов карт.
Спасибо за комментарий! В статье описали самые популярные продукты, с которыми чаще взаимодействуем мы и наши заказчики. Однако с продуктами по типу Proxmox и Bacula мы тоже работаем.
Все верно. Если нет ограничений регуляторов и внутренних регламентов, то можно хранить РК в любом публичном облаке, которое работает по 152-ФЗ. Со средним и крупным бизнесом, особенно с банками, есть нюансы)
Добрый день! Спасибо за идею для будущей статьи :) Мы не работаем с малым бизнесом, а для среднего проектируем и внедряем СРК поэтапно. Если в компании не очень большие объемы, то можем порекомендовать использовать автолоадеры с одним драйвом уровня HPE MSL 1/8 G2, которые могут хранить достаточно большой объем с учетом компрессии.
Опрашивали как раз ИТ и ИБ подразделения. Видимо, вам повезло меньше, чем вашим коллегам из других банков. Насчет топовой техники - мы убеждены, что хороший ноутбук или комп лучше, чем плохой, даже если у вас Астра Линукс.
Исследование проводили мы ("Инфосистемы Джет") совместно с hh.ru. Разрешите с вами не согласиться, - в нашей компании у всех сотрудников после прохождения испытательного срока есть возможность оформить ДМС.
Коллеги, спасибо за мероприятие! Было круто 💙
Добрый день! Спасибо!
Все зависит от структуры данных и поставленных SLA. Зачастую даже объем не настолько критичен, как состав данных, которые нужно реплицировать в кратчайшие сроки с минимальным влиянием на продуктивные сервисы.
Повода для обновления не было — использовалась актуальная на тот момент версия прошивки. А о более продвинутом функционале расскажем во второй части статьи, уже скоро.
Спасибо! Да, вы правы:)
Спасибо! От профессионала отрасли хорошие слова вдвойне приятней :)
Да, мы не можем сказать, будет ли модель так же хорошо работать в условиях, которые никогда не наблюдались за последние пару лет. Например, при расходах воды в 2 раза выше, чем в обучающей выборке. Или при одновременной работе не четырех-шести насосов, а двух или десяти. Но для целей работы сервиса в этом нет необходимости. А если бы такие режимы и появились - модель была бы обновлена. Что же касается наблюдаемых режимов, метрики приведены в статье:
Энергоэффективными насосами в статье называются те, которые потребляют меньше электроэнергии на единицу объема подаваемой воды при заданном давлении. А энергоэффективность всей станции достигается за счет минимального потребления электроэнергии при требуемом расходе с учетом ограничения на минимально допустимое давление. Поэтому не всегда рекомендуется включать самый энергоэффективный насос. Иногда, если есть запас по давлению, выгоднее будет включить менее эффективный, но потребляющий меньше электроэнергии в абсолюте.
Схема изображена верно – насосы работают на общий коллектор из которого вода поступает на котлы. Для упрощения их изображено 3 штуки, но на самом деле котлов и деаэраторов больше. Нельзя утверждать, что каждый насос работает на определенный котел.
Вы правы на счет расходчика, спасибо за замечание. Я пытался упростить описание, но стоило изложить как есть. На самом деле расходомеров много, они установлены перед каждым из котлов. Таким образом нам все еще неизвестен расход питательной воды на каждом отдельном насосе, а известен лишь суммарный расход. Поправил этот момент в тексте.
Да, характеристики насосов ухудшаются с их наработкой. А ML как раз-таки полезен для мониторинга текущего состояния и результатов проведения капитального ремонта.
На ТЭЦ уже был внедрен подсказчик по оптимальному потреблению топлива котельными агрегатами, но цифровых проектов про оптимизации насосного оборудования ранее не было.
Рассмотренный выше пример не относится к теме статьи, но может возникнуть при ошибке проектирования насосной станции.
На счет механизма страхующего от неполноты данных - если часть данных отсутствует, то прогноз и рекомендации не выдаются до возобновления передачи всех данных.
Черным ящиком можно было назвать более сложные модели типа градиентного бустинга или нейронных сетей. В нашем же случае все модели легко интерпретируются и проверяются на непротиворечивость здравому смыслу.
Оффтоп: для упомянутых выше нейронных сетей кстати существует physics-informed подход [ссылка], позволяющей сделать работу модели физичной.
Благодарю за замечание, вы абсолютно правы про разрыв потока в данной области графика. График для последовательного соединения убрал. Неточность на картинке допущена не по незнанию, а по невнимательности, так как основной темой статьи является параллельное соединение насосов. Для него, кстати, тоже можно придумать критическую ситуацию, когда один насос передавливает другой (насосные характеристики насосов сильно отличаются, а сопротивление сети высоко). Если так вдруг произошло, то, как и в вашем случае, это произошло из-за неверно подобранного оборудования при проектировании станции, но это не наш случай и мы такую "интересную" ситуацию не рассматриваем.
Спасибо за ваше замечание!
История там, на наш взгляд, еще более запутанная. То, что IBM отдал в комьюнити и было EVMS, а то, что потом стало LVM в привычном нам виде, - это синтаксис от HP-UX + код от IBM. Но это было очень давно.
Да, в Enterprise многие лимиты - это не что-то невероятное, а вполне достижимые значения.
Спасибо за уточнение!
Конечно! Очень хотелось "поместиться" в небольшую статью и сильно не выходить за рамки LVM, но породили неточность, что это исчерпывающий сиписок типов карт.
На эту тему и опрос проводить не надо, - большинство будет "за" :)
Спасибо за комментарий! В статье описали самые популярные продукты, с которыми чаще взаимодействуем мы и наши заказчики. Однако с продуктами по типу Proxmox и Bacula мы тоже работаем.
Все верно. Если нет ограничений регуляторов и внутренних регламентов, то можно хранить РК в любом публичном облаке, которое работает по 152-ФЗ. Со средним и крупным бизнесом, особенно с банками, есть нюансы)
Всеми руками за!)
Добрый день! Спасибо за идею для будущей статьи :) Мы не работаем с малым бизнесом, а для среднего проектируем и внедряем СРК поэтапно. Если в компании не очень большие объемы, то можем порекомендовать использовать автолоадеры с одним драйвом уровня HPE MSL 1/8 G2, которые могут хранить достаточно большой объем с учетом компрессии.
Опрашивали как раз ИТ и ИБ подразделения. Видимо, вам повезло меньше, чем вашим коллегам из других банков. Насчет топовой техники - мы убеждены, что хороший ноутбук или комп лучше, чем плохой, даже если у вас Астра Линукс.
Исследование проводили мы ("Инфосистемы Джет") совместно с hh.ru. Разрешите с вами не согласиться, - в нашей компании у всех сотрудников после прохождения испытательного срока есть возможность оформить ДМС.