Hi Dongwon, I guess you are right and the example is wrong. The new matching sequence should start from line "18".
Regards, Dian > 在 2019年9月5日，下午8:28，Dongwon Kim <eastcirc...@gmail.com> 写道： > > Oops, I think I explained something wrong in the previous email. > B means not A. > Therefore, after the completed match, there must be no new partial match > starting from there. > There's nothing wrong with the implementation, but the example in [2] is > wrong. > > Am I right? > > Best, > Dongwon > > On Thu, Sep 5, 2019 at 9:15 PM Dongwon Kim <eastcirc...@gmail.com > <mailto:eastcirc...@gmail.com>> wrote: > Hi, > I'm using Flink 1.9 and testing MATCH_RECOGNIZE by following [1]. > While testing the query in [2] on myself, I've got the different result from > [2] > The query result from [2] is as follows: > symbol start_tstamp end_tstamp avgPrice > ========= ================== ================== ============ > ACME 01-APR-11 10:00:00 01-APR-11 10:00:03 14.5 > ACME 01-APR-11 10:00:04 01-APR-11 10:00:09 13.5 > The other query result from the attached maven project (which only contains a > sample program that executes the query in [2]) is as follows: > ACME,1970-01-01 00:00:01.0,1970-01-01 00:00:04.0,14.5 > There's just one entry, not two. > (As you might notice, the time of the first record in the attached maven > project is 1970-01-01 00:00:01 for testing. The other numbers are the same.) > > I dug into the internal implementation of CepOperator and got the followings: > INPUT : ACME,1000,12.0,1 > PARTIAL MATCH : [A*1] > > INPUT : ACME,2000,17.0,2 > PARTIAL MATCH : [A*2] > > INPUT : ACME,3000,13.0,1 > PARTIAL MATCH : [A*3] > PARTIAL MATCH : [A*1] > > INPUT : ACME,4000,16.0,3 > PARTIAL MATCH : [A*4] > PARTIAL MATCH : [A*2] > > INPUT : ACME,5000,25.0,2 > COMPLETED MATCH : [A*4, B*1] > > INPUT : ACME,6000,2.0,1 > PARTIAL MATCH : [A*1] > > INPUT : ACME,7000,4.0,1 > PARTIAL MATCH : [A*2] > PARTIAL MATCH : [A*1] > > INPUT : ACME,8000,10.0,2 > PARTIAL MATCH : [A*3] > PARTIAL MATCH : [A*2] > PARTIAL MATCH : [A*1] > > INPUT : ACME,9000,15.0,2 > PARTIAL MATCH : [A*4] > PARTIAL MATCH : [A*3] > PARTIAL MATCH : [A*2] > > INPUT : ACME,10000,25.0,2 > PARTIAL MATCH : [A*5] > PARTIAL MATCH : [A*4] > > INPUT : ACME,11000,30.0,1 > PARTIAL MATCH : [A*6] > > My observation is that, when "ACME,5000,25.0,2" comes in (line 15), we get a > completed match (line 16) but no partial match (which is [A*1] in my > notation) starting from it. > According to the definition of "AFTER MATCH SKIP TO FIRST B", as > "ACME,5000,25,2" is B, a new match should start from "ACME,5000,25.0,2". > However, a new match starts from the next one (line 18, 19) in the above > trace. > Therefore, when the last one "ACME,11000,30.0,1" comes in, the average at > that point is 14.3(=2+4+10+15+25+30/6) which is less than 15 so > "ACME,11000,30.0,1" belongs to A, not B as shown in the example. > > Is it a bug? or did I miss something conceptually? > > p.s. how do you load rows from a local csv file with rowtime configured? I > don't like the way I implemented my custom table source in the attached file > which I use for testing. > > Best, > Dongwon > > [1] > https://ci.apache.org/projects/flink/flink-docs-stable/dev/table/streaming/match_recognize.html > > <https://ci.apache.org/projects/flink/flink-docs-stable/dev/table/streaming/match_recognize.html> > [2] > https://ci.apache.org/projects/flink/flink-docs-stable/dev/table/streaming/match_recognize.html#aggregations > > <https://ci.apache.org/projects/flink/flink-docs-stable/dev/table/streaming/match_recognize.html#aggregations>
