fanrui created FLINK-18503:
------------------------------
Summary: bug occurs when `HeapReducingState#add` method handles
null
Key: FLINK-18503
URL: https://issues.apache.org/jira/browse/FLINK-18503
Project: Flink
Issue Type: Bug
Components: Runtime / State Backends
Affects Versions: 1.12.0
Reporter: fanrui
Fix For: 1.12.0
Attachments: image-2020-07-07-02-20-03-420.png,
image-2020-07-07-02-20-57-299.png
In our production environment, there are advertising billing jobs, which are
keyBy according to advertiserId. Calculate the cost of each advertiser in the
specified window, that is, use ReducingFunction to sum the price after keyBy by
advertiser.
But it is found that the results calculated using FsStateBackend and
RocksDBStateBackend are different. The calculation result of FsStateBackend is
wrong, and the calculation result of RocksDBStateBackend is correct.
After reading the source code, HeapReducingState#add code:[code
link|https://github.com/apache/flink/blob/f730e16fb47b0fcace7d3a1a8c8e3cb2c837ceec/flink-runtime/src/main/java/org/apache/flink/runtime/state/heap/HeapReducingState.java#L93]
{code:java}
public void add(V value) throws IOException {
if (value == null) {
clear();
return;
}
try {
stateTable.transform(currentNamespace, value, reduceTransformation);
} catch (Exception e) {
throw new IOException("Exception while applying ReduceFunction in
reducing state", e);
}
}
{code}
If value==null, the clear method deletes the data of the current
<key,namespace> from the StateTable. ReducingFunction will only be executed if
value!=null.
h2. Why is there a bug?
For a job that calculates cost, if price != null, the price is added to result;
if price == null, then result is unchanged.
The ResultFunction method handles the case of price == null, our ResultFunction
is as follows:
{code:java}
ReduceFunction<Long> sumFunction = new ReduceFunction<Long>() {
@Override
public Long reduce(Long previousState, Long newValue) throws Exception {
// if newValue ==null,
// consider newValue to be 0 and return previousState directly
if (newValue == null) {
return previousState;
}
return previousState + newValue;
}
};
{code}
However, when HeapReducingState#add finds that the input value == null, it
directly executes the clear method, and does not execute the user-defined
ResultFunction at all.
For example: if the input prices are 17, null, and 11, the price saved in the
state is 17 when you enter 17, the price is cleared when you enter null, and
the price is 11 when you enter 11, so the result is wrong.
Fortunately, the calculation result of RocksDBStateBackend is correct. The
RocksDBReducingState#add method does not perform special treatment for null.
RocksDBReducingState#add code is as follows:[code
link|https://github.com/apache/flink/blob/f730e16fb47b0fcace7d3a1a8c8e3cb2c837ceec/flink-state-backends/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/RocksDBReducingState.java#L92]
{code:java}
public void add(V value) throws Exception {
byte[] key = getKeyBytes();
V oldValue = getInternal(key);
V newValue = oldValue == null ? value : reduceFunction.reduce(oldValue,
value);
updateInternal(key, newValue);
}
{code}
h2. Flink UT can reproduce this bug
StateBackendTestBase#testReducingStateAddAndGet can reproduce this bug.
Need to be modified as follows:
# udf
{code:java}
ReduceFunction<Long> sumFunction = new ReduceFunction<Long>() {
@Override
public Long reduce(Long previousState, Long newValue) throws Exception {
// if newValue ==null,
// consider newValue to be 0 and return previousState directly
if (newValue == null) {
return previousState;
}
return previousState + newValue;
}
};
final ReducingStateDescriptor<Long> stateDescr =
new ReducingStateDescriptor<>("my-state", sumFunction, Long.class);{code}
# add element
{code:java}
keyedBackend.setCurrentKey("def");
assertNull(state.get());
state.add(17L);
state.add(null);//new code
state.add(11L);
assertEquals(28L, state.get().longValue());{code}
My code repository commit
[link|https://github.com/1996fanrui/flink/commit/645118dd2f95de88580d07e00d88e8783a0f9680]
The UT execution output of RocksDBStateBackendTest is as follows:
!image-2020-07-07-02-20-03-420.png!
The UT execution output of FileStateBackendTest&MemoryStateBackendTest is as
follows:
!image-2020-07-07-02-20-57-299.png!
{code:java}
java.lang.AssertionError:
Expected :28
Actual :11{code}
The above phenomenon shows that the HeapReducingState#add method has a bug.
Regardless of which state backend you choose, the semantics provided by the
Flink engine should be consistent and should not output different calculation
results.
h2. My solution
Remove the processing logic of value == null in HeapReducingState#add. Result:
All UTs of FileStateBackendTest can be passed.
h2. Similar bug
HeapFoldingState#add & HeapAggregatingState#add
h2. Question
HeapReducingState#add When designing, why does the designer handle the null
case specially? I think the case of null should be handled by the user-defined
ReducingFunction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)