Комментарии 21
Дмитрий, получившееся решение тестировалось под нагрузкой? Какие в итоге получились показатели производительности в продакшене? Очень интересует среднее время ответа антифрод-системы, запас по объёму транзакций (сколько транзакций в секунду/минуту могут быть обработаны без ухудшения общей производительности). Какие показатели при этом устанавливаются как целевые?
Ещё есть вопрос по таблице TransactionsStatistics: как и кем определяется, какие именно данные туда записываются? Понятно, что разных статистических данных и параметров транзакций можно записывать десятки, если не сотни, так вот интересует минимально необходимый набор, который сохраняется, и как он формируется. Спасибо.
(Если упрощенно) Показатели, влияющие на точность работы алгоритма предсказания (предикторы), определяют эксперты в предметной области. Data scientist'ы статистическими методами проверяют верна ли гипотеза экспертов. Если да, то разработчик интегрирует новый показатель в систему и запускается переобучение модели.
На самом деле, то, что вы нарисовали — это нормальный такой CQRS, где моделью на чтение выступает ML, а моделью на запись — лог транзакций. Осталось довести это до логического завершения, вставить ивенты максимально часто (включая прохождение внутри ML), после чего вы получите, с одной стороны, большую выборку данных для последующего анализа и построения статистики, а с другой — audit trail для ответов на вопросы «а почемуууу».
Мне вот другое интересно. Вы пишете, что Azure дает SLA .95. Ну допууууустим. Это гарантия SLA отдельного компонента?
Мне вот другое интересно. Вы пишете, что Azure дает SLA .95. Ну допууууустим. Это гарантия SLA отдельного компонента?
Разделение потоков на чтение и на запись — это довольно частый паттерн для высоконагруженных систем (но это только одна единственная концепция, и это точно ни CQRS, ни с Event Sourcing, ни CQRS + Event Sourcing.
Про SLA отдельных компонентов я не очень понял: что Вы подразумеваете под термином 'отдельных компонент'?
Про SLA отдельных компонентов я не очень понял: что Вы подразумеваете под термином 'отдельных компонент'?
Разделение потоков на чтение и на запись — это довольно частый паттерн для высоконагруженных систем (но это только одна единственная концепция, и это точно ни CQRS,
Я запутался в вашем предложении. Разделение потоков на чтение и запись — это CQRS (по собственному утверждению Янга).
что Вы подразумеваете под термином 'отдельных компонент'?
Я имею в виду: в вашем договоре с Azure SLA зафиксирован для всей системы целиком или для отдельного компонента — например, Azure Queue?
Определение Янга не читал, но за концепцией разделения потоков еще стоит и реализация. В .NET CQRS принято реализовывать с использованием паттернов Repository/Command/введением DDD/Event Sourcing/etс. (тема долгая) В описываемой системе все обстоит немного (сильно) по-другому.
Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).
Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).
Определение Янга не читал, но за концепцией разделения потоков еще стоит и реализация. В .NET CQRS принято реализовывать с использованием паттернов Repository/Command/введением DDD/Event Sourcing/etс.
Тем не менее, по определению основателя для CQRS достаточно разделения потоков. И нет, я не думаю, что он согласится с вашим «принято» (если что, он сам из .net-мира).
Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).
Я сейчас не про внешних клиентов, а про ваш договор с Azure, на основании которого вы делаете заявление: «Используемые антифрод-системой сервисы Azure [...] дают следующие преимущества из коробки: [...] SLA не ниже 99,95%;»
Значит у меня полноценный CQRS .)
A 99.95% Window Azure Service Level Agreement is only achievable with two nodes for each install
www.erpsoftwareblog.com/2014/04/windows-azure-service-level-agreement-sla-what-microsoft-users-need-to-know/
www.erpsoftwareblog.com/2014/04/windows-azure-service-level-agreement-sla-what-microsoft-users-need-to-know/
Это для компонента или для системы?
у каждой компоненты SLA 99.95%, при условии что у нее есть узел-«двойник».
То есть если мы хотим, чтоб у самой системы был SLA 99.95%, и система состоит из нескольких компонент, то надо составить уравнение чтоб подсчитать сколько узлов надо для каждой компоненты, так чтоб произведение вероятности ошибок было меньше чем 0.05%
ru.wikipedia.org/wiki/Надёжность
То есть если мы хотим, чтоб у самой системы был SLA 99.95%, и система состоит из нескольких компонент, то надо составить уравнение чтоб подсчитать сколько узлов надо для каждой компоненты, так чтоб произведение вероятности ошибок было меньше чем 0.05%
ru.wikipedia.org/wiki/Надёжность
Да я как бы понимаю, как считается — в первом приближении — надежность системы, мне просто было интересно, дает Azure гарантию на компоненты или на системы целиком. Мне казалось, что первое — и вы это подтвердили. Следовательно, с общей надежностью системы все не так прозрачно.
Есть ли проблемы юридического характера?
И если есть, как вы их решаете?
(Благодарю за пост!)
И если есть, как вы их решаете?
(Благодарю за пост!)
Проблем нет, есть законодательные ограничения (нефункциональные требования, описаны во 2-ой части статьи). Проблемы будут, если эти ограничения не соблюдать.
И второй вопрос:
в чем питоновский scikit-learn хуже, а в чем лучше предлагаемого вами решения?
в чем питоновский scikit-learn хуже, а в чем лучше предлагаемого вами решения?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Антифрод. Архитектура сервиса (часть 3)