Блог

Я следую руководству здесь.

Q1: Почему в конечном приложении мы очищаем все состояния и удаляем таймер всякий flagState = true раз, независимо от текущей суммы транзакции? Я ссылаюсь на эту часть кода:

 // Check if the flag is set
if (lastTransactionWasSmall != null) {
    if (transaction.getAmount() > LARGE_AMOUNT) {
        //Output an alert downstream
        Alert alert = new Alert();
        alert.setId(transaction.getAccountId());

        collector.collect(alert);
    }
    // Clean up our state [WHY HERE?]
    cleanUp(context);
}
 

Если поток данных для транзакции был 0.5, 10, 600 , то flagState он будет установлен для 0.5 , а затем очищен для 10 . Итак 600 , мы пропускаем приведенный выше блок кода и не проверяем наличие большого количества. Но если 0.5 600 транзакции и произошли в течение минуты, мы должны были отправить предупреждение, но мы этого не сделали.

Q2: Почему мы используем время обработки, чтобы определить, разделяют ли две транзакции 1 минуту? Класс транзакции имеет timeStamp поле, поэтому не лучше ли использовать время события? Поскольку время обработки зависит от скорости приложения, поэтому две транзакции с интервалом событий в пределах 1 минуты друг от друга могут обрабатываться с интервалом > 1 минуты из-за задержки.

A1: Модель мошенничества, используемая в этом примере, объясняется на этом рисунке:

В вашем примере транзакция 600 должна немедленно следовать за транзакцией 0.5 , чтобы считаться мошенничеством. Из-за промежуточной транзакции for 10 это не мошенничество, даже если все три транзакции происходят в течение минуты. Это просто вопрос того, как был сформулирован вариант использования.

A2: Выполнение этого со временем события было бы очень правильным выбором, но сделало бы пример намного более сложным. Мало того, что потребуются водяные знаки, но нам также придется сортировать поток по времени события, поскольку реалистичный пример должен учитывать, что события могут быть не в порядке.

На этом этапе реализация этого с помощью функции процесса больше не будет лучшим выбором. Правильным решением было бы использовать возможности сопоставления временных шаблонов библиотеки CEP от Flink или Flink SQL с MATCH_RECOGNIZE.