Реплицированный кеш в памяти для задач Apache Flink
Я обрабатываю поток, который необходимо преобразовать на основе данных инвентаризации. По своей сути данные инвентаризации будут большими (точных цифр нет), в них будет МНОГО операций чтения и очень мало операций записи.
Предположим, у меня есть 3 диспетчера задач по 1 слоту для каждого.
Как мой оператор преобразования, работающий на трех разных машинах, может использовать реплицируемый кеш в памяти?
Хм, не уверен. Количество ключей где-то между 50К-100К.
Чтобы дать вам немного больше контекста: поток, который я пытаюсь обогатить, состоит из нескольких идентификаторов устройств по 100 тысяч. Идентификаторы позволяют мне присоединиться к данным инвентаризации, которые могут время от времени записываться. Это данные инвентаризации, которые я хочу сохранить в памяти и воспроизвести. Я читал о схеме вещания, которая может сработать. Согласно шаблону, я могу транслировать свои данные invt в параллельные потоки. Мысли?
Если инвентарь можно сопоставить с несколькими идентификаторами устройств, кажется, что правильным решением для вас является метод широковещания. Вы записываете состояние трансляции каждый раз, когда инвентарь изменяется, и читаете его всякий раз, когда вам нужно присоединиться с идентификатором устройства.
Ответы 1
Обычно (при разумном размере записи для дополнительных данных) вы можете легко сохранить в состоянии сотни тысяч уникальных записей. Поскольку вы присоединяете дополнительные данные к своему потоку на основе идентификаторов, просто используйте KeyedCoProcessFunction.
Часто основной проблемой здесь является холодный запуск, когда вы хотите сначала убедиться, что ваше состояние (данные обогащения) полностью загружено, прежде чем начинать обработку данных, подлежащих обогащению. Одним из простых решений является запуск рабочего процесса в специальном режиме, где у вас есть фиктивный источник потоковых данных. После загрузки всех дополнительных данных остановите их с помощью точки сохранения, а затем перезапустите в обычном режиме с этой точки сохранения.
Как вы предлагаете мне создать поток инвентаризации как часть KeyedCoProcessFunction? Может быть, поток CDC с использованием Debezium?
Да, это рекомендуемый подход. В противном случае вы обычно пишете собственный источник, который регулярно запрашивает БД и сохраняет текущую верхнюю отметку в состоянии (например, временную метку последнего изменения из самого последнего успешного запроса). Но это нетривиально, чтобы получить право.
Можно ли разделить поток и кеш по одному и тому же ключу, чтобы избежать необходимости реплицировать кеш и сделать решение более масштабируемым?