You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kylin.apache.org by "yubo-ds1@yolo24.com" <yu...@yolo24.com> on 2016/08/04 10:20:47 UTC

Question abount BuildInFunctionTransformer



Hi all,

When we search with a sql “like clause”, we found in the log there will be a
BuildInFunctionTransformer which will transform the “like clause” into “in
clause”
But values seems not exactly right. Below is my usecases.

Case1 translate '%深海%'  to [深海新创专营店80002972, 义深海官方旗舰店80011438]
Case 2 translate  '%深海新创%'  to [深海新创专营店80002972]

This is not espected. 

Is this a bug or can anyone help to explain? Thanks.

1.
sql:

select merchant_name,* 
from session_view_shop_0
where merchant_name like '%深海%'
and dt_year='2016'
and dt_month='07'
and dt_day >='25' 
and dt_day <='28'

2016-08-04 17:38:46,095 INFO  [http-bio-7070-exec-31]
dict.BuildInFunctionTransformer:66 : Translated
{LIKE(KYLIN_REPORT_DB.SESSION_
VIEW_SHOP_0.MERCHANT_NAME,%深海%)} to IN clause:
{KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN [深海新创专营店80002972, 义深
海官方旗舰店80011438]}

2. 
Sql:

select merchant_name,* 
from session_view_shop_0
where merchant_name like '%深海新创%'
and dt_year='2016'
and dt_month='07'
and dt_day >='25' 
and dt_day <='28'

2016-08-04 17:41:52,321 INFO  [http-bio-7070-exec-31]
dict.BuildInFunctionTransformer:66 : Translated
{LIKE(KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME,%深海新创%)} to IN
clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN
[深海新创专营店80002972]}


Kylin version:apache-kylin-1.5.2.1-HBase1.x-bin.tar.gz



--
View this message in context: http://apache-kylin.74782.x6.nabble.com/Question-abount-BuildInFunctionTransformer-tp5499.html
Sent from the Apache Kylin mailing list archive at Nabble.com.

Re: 答复: Question abount BuildInFunctionTransformer

Posted by "yubo-ds1@yolo24.com" <yu...@yolo24.com>.
hi shaofeng,

yes, above cases are using same cube(session_view_shop_0_c1_clone).


2016-08-11 10:25:04,300 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:48 : The project manager's reference is
org.apache.kylin.
metadata.project.ProjectManager@2975ab7c
2016-08-11 10:25:04,301 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:60 : Find candidates by table
KYLIN_REPORT_DB.SESSION_VIE
W_SHOP_0 and project=KYLIN_REPORT_OPT :
org.apache.kylin.query.routing.Candidate@a324c7c
2016-08-11 10:25:04,301 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:49 : Applying rule: class
org.apache.kylin.query.routing.
rules.RemoveUncapableRealizationsRule, realizations before:
[session_view_shop_0_c1_clone(CUBE)], realizations after: [session_view_
shop_0_c1_clone(CUBE)]
2016-08-11 10:25:04,301 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:49 : Applying rule: class
org.apache.kylin.query.routing.
rules.RealizationSortRule, realizations before:
[session_view_shop_0_c1_clone(CUBE)], realizations after:
[session_view_shop_0_c1_cl
one(CUBE)]
2016-08-11 10:25:04,301 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:72 : The realizations remaining:
[session_view_shop_0_c1_
clone(CUBE)] And the final chosen one is the first one
2016-08-11 10:25:04,337 DEBUG [http-bio-7070-exec-165]
enumerator.OLAPEnumerator:107 : query storage...
2016-08-11 10:25:04,338 INFO  [http-bio-7070-exec-165]
v2.CubeStorageQuery:234 : exactAggregation is false because some column not
o
n group by: [KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_YEAR,
KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_DAY, KYLIN_REPORT_DB.SESSION_VIEW_S
HOP_0.DISPLAY_NAME, KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_MONTH,
KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DATASOURCE] (single value colu
mn: [KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_YEAR,
KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DISPLAY_NAME,
KYLIN_REPORT_DB.SESSION_VIEW_SHO
P_0.DT_MONTH])
2016-08-11 10:25:04,338 INFO  [http-bio-7070-exec-165]
v2.CubeStorageQuery:345 : Memory budget is set to: 16378
2016-08-11 10:25:04,348 INFO  [http-bio-7070-exec-165]
dict.BuildInFunctionTransformer:66 : Translated
{LIKE(KYLIN_REPORT_DB.SESSION
_VIEW_SHOP_0.MERCHANT_NAME,%深海新创%)} to IN clause:
{KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN [深海新创专营店80002972]
}




2016-08-11 10:25:14,056 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:48 : The project manager's reference is
org.apache.kylin.
metadata.project.ProjectManager@2975ab7c
2016-08-11 10:25:14,057 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:60 : Find candidates by table
KYLIN_REPORT_DB.SESSION_VIE
W_SHOP_0 and project=KYLIN_REPORT_OPT :
org.apache.kylin.query.routing.Candidate@5c5e5638
2016-08-11 10:25:14,057 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:49 : Applying rule: class
org.apache.kylin.query.routing.
rules.RemoveUncapableRealizationsRule, realizations before:
[session_view_shop_0_c1_clone(CUBE)], realizations after: [session_view_
shop_0_c1_clone(CUBE)]
2016-08-11 10:25:14,057 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:49 : Applying rule: class
org.apache.kylin.query.routing.
rules.RealizationSortRule, realizations before:
[session_view_shop_0_c1_clone(CUBE)], realizations after:
[session_view_shop_0_c1_cl
one(CUBE)]
2016-08-11 10:25:14,058 INFO  [http-bio-7070-exec-165]
routing.QueryRouter:72 : The realizations remaining:
[session_view_shop_0_c1_
clone(CUBE)] And the final chosen one is the first one
2016-08-11 10:25:14,098 DEBUG [http-bio-7070-exec-165]
enumerator.OLAPEnumerator:107 : query storage...
2016-08-11 10:25:14,098 INFO  [http-bio-7070-exec-165]
v2.CubeStorageQuery:234 : exactAggregation is false because some column not
o
n group by: [KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_YEAR,
KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_DAY, KYLIN_REPORT_DB.SESSION_VIEW_S
HOP_0.DISPLAY_NAME, KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_MONTH,
KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DATASOURCE] (single value colu
mn: [KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DT_YEAR,
KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.DISPLAY_NAME,
KYLIN_REPORT_DB.SESSION_VIEW_SHO
P_0.DT_MONTH])
2016-08-11 10:25:14,099 INFO  [http-bio-7070-exec-165]
v2.CubeStorageQuery:345 : Memory budget is set to: 16378
2016-08-11 10:25:14,110 INFO  [http-bio-7070-exec-165]
dict.BuildInFunctionTransformer:66 : Translated
{LIKE(KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME,%深海新创手机%)} to IN
clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN []}

--
View this message in context: http://apache-kylin.74782.x6.nabble.com/Question-abount-BuildInFunctionTransformer-tp5499p5549.html
Sent from the Apache Kylin mailing list archive at Nabble.com.

Re: 答复: Question abount BuildInFunctionTransformer

Posted by ShaoFeng Shi <sh...@apache.org>.
Hi Yubo,

Thanks for the reporting and analysis; I'm trying to understand more; For
case 1 and case 2 queries, are they using the same cube, or are you getting
the result at the same moment?

The only didfference between case1 and case2 seems be the where condition:

case1:
where merchant_name like '%深海新创手机%'

case2:
where merchant_name like '%深海新创%'

So the result set of case2 should be a superset of case1 (if they're using
the same cube), but it isn't; Did I miss some key information? Thank you!


2016-08-10 10:53 GMT+08:00 yubo-ds1@yolo24.com <yu...@yolo24.com>:

> CubeStorageQuery.search/ CubeSegmentScanner
>
> when filter is translated for the first segment, filter is changed to
> CompareTupleFilter(IN clause)
> translate will not triger for the next segments.
> this is not right because dictionary is not same for every segments.
>
> assume data like this:
>
> merchant_name  cube segment
> 深海新创专营          20160725
> 深海新创手机          20160726
>
> when search with like '%深海新创%'
> CubeSegmentScanner scan segment '20160725' , and filter is changed to in
> clause( IN '深海新创专营')
> result is right for this segment ,but not for the next segments because
> filter now has been changed.
>
>
>
> --
> View this message in context: http://apache-kylin.74782.x6.
> nabble.com/Question-abount-BuildInFunctionTransformer-tp5499p5533.html
> Sent from the Apache Kylin mailing list archive at Nabble.com.
>



-- 
Best regards,

Shaofeng Shi

Re: 答复: Question abount BuildInFunctionTransformer

Posted by hongbin ma <ma...@apache.org>.
JIRA: https://issues.apache.org/jira/browse/KYLIN-1954

thanks for reporting!

On Thu, Aug 11, 2016 at 10:54 AM, hongbin ma <ma...@apache.org> wrote:

> I think you're right on this.
>
> the code modifies the filter in the first CubeSegmentScanner and won't get
> modified in the subsequent CubeSegmentScanners again. Due to the difference
> of different segment's dictionaries, it might be wrong.
>
> I'm opening a JIRA for this and it will be fixed in 1.5.4
>
> On Wed, Aug 10, 2016 at 10:53 AM, yubo-ds1@yolo24.com <yubo-ds1@yolo24.com
> > wrote:
>
>> CubeStorageQuery.search/ CubeSegmentScanner
>>
>> when filter is translated for the first segment, filter is changed to
>> CompareTupleFilter(IN clause)
>> translate will not triger for the next segments.
>> this is not right because dictionary is not same for every segments.
>>
>> assume data like this:
>>
>> merchant_name  cube segment
>> 深海新创专营          20160725
>> 深海新创手机          20160726
>>
>> when search with like '%深海新创%'
>> CubeSegmentScanner scan segment '20160725' , and filter is changed to in
>> clause( IN '深海新创专营')
>> result is right for this segment ,but not for the next segments because
>> filter now has been changed.
>>
>>
>>
>> --
>> View this message in context: http://apache-kylin.74782.x6.n
>> abble.com/Question-abount-BuildInFunctionTransformer-tp5499p5533.html
>> Sent from the Apache Kylin mailing list archive at Nabble.com.
>>
>
>
>
> --
> Regards,
>
> *Bin Mahone | 马洪宾*
>



-- 
Regards,

*Bin Mahone | 马洪宾*

Re: 答复: Question abount BuildInFunctionTransformer

Posted by hongbin ma <ma...@apache.org>.
I think you're right on this.

the code modifies the filter in the first CubeSegmentScanner and won't get
modified in the subsequent CubeSegmentScanners again. Due to the difference
of different segment's dictionaries, it might be wrong.

I'm opening a JIRA for this and it will be fixed in 1.5.4

On Wed, Aug 10, 2016 at 10:53 AM, yubo-ds1@yolo24.com <yu...@yolo24.com>
wrote:

> CubeStorageQuery.search/ CubeSegmentScanner
>
> when filter is translated for the first segment, filter is changed to
> CompareTupleFilter(IN clause)
> translate will not triger for the next segments.
> this is not right because dictionary is not same for every segments.
>
> assume data like this:
>
> merchant_name  cube segment
> 深海新创专营          20160725
> 深海新创手机          20160726
>
> when search with like '%深海新创%'
> CubeSegmentScanner scan segment '20160725' , and filter is changed to in
> clause( IN '深海新创专营')
> result is right for this segment ,but not for the next segments because
> filter now has been changed.
>
>
>
> --
> View this message in context: http://apache-kylin.74782.x6.
> nabble.com/Question-abount-BuildInFunctionTransformer-tp5499p5533.html
> Sent from the Apache Kylin mailing list archive at Nabble.com.
>



-- 
Regards,

*Bin Mahone | 马洪宾*

Re: 答复: Question abount BuildInFunctionTransformer

Posted by "yubo-ds1@yolo24.com" <yu...@yolo24.com>.
CubeStorageQuery.search/ CubeSegmentScanner

when filter is translated for the first segment, filter is changed to
CompareTupleFilter(IN clause)
translate will not triger for the next segments.
this is not right because dictionary is not same for every segments.

assume data like this:

merchant_name  cube segment  
深海新创专营          20160725
深海新创手机          20160726

when search with like '%深海新创%'
CubeSegmentScanner scan segment '20160725' , and filter is changed to in
clause( IN '深海新创专营')
result is right for this segment ,but not for the next segments because
filter now has been changed.



--
View this message in context: http://apache-kylin.74782.x6.nabble.com/Question-abount-BuildInFunctionTransformer-tp5499p5533.html
Sent from the Apache Kylin mailing list archive at Nabble.com.

答复: Question abount BuildInFunctionTransformer

Posted by "yubo-ds1@yolo24.com" <yu...@yolo24.com>.
Sorry for the wrong description and thanks for the explaination.

I have another question on this.

Case1
select merchant_name,dt_day,count(*)
from session_view_shop_0
where merchant_name like '%深海新创手机%'
and dt_year='2016'
and dt_month='07'
and dt_day >='25'
and dt_day <='28'
group by merchant_name,dt_day

2016-08-05 09:25:06,263 INFO  [http-bio-7070-exec-10] dict.BuildInFunctionTransformer:66 : Translated {LIKE(KYLIN_REPORT_DB.SESSION_
VIEW_SHOP_0.MERCHANT_NAME,%深海新创手机%)} to IN clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN []}

Result1
深海新创手机专营店80002972 28 6360
深海新创手机专营店80002972 27 5501
深海新创手机专营店80002972 26 4830

Case 2
select merchant_name,dt_day,count(*)
from session_view_shop_0
where merchant_name like '%深海新创%'
and dt_year='2016'
and dt_month='07'
and dt_day >='25'
and dt_day <='28'
group by merchant_name,dt_day

2016-08-05 09:37:55,469 INFO  [http-bio-7070-exec-15] dict.BuildInFunctionTransformer:66 : Translated {LIKE(KYLIN_REPORT_DB.SESSION_
VIEW_SHOP_0.MERCHANT_NAME,%深海新创%)} to IN clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN [深海新创专营店80002972]}

Result2
深海新创专营店80002972 25 5283


’深海新创手机专营店80002972’ is expected in result2 , as it exists which case1 shows.



发件人: mahongbin [via Apache Kylin] [mailto:ml-node+s74782n5501h89@n6.nabble.com]
发送时间: 2016年8月4日 22:58
收件人: yubo-ds1(于渤.大数据中心.大数据平台部)
主题: Re: Question abount BuildInFunctionTransformer

To me the translation is expected behavior

On Thu, Aug 4, 2016 at 10:47 PM, Yiming Liu <[hidden email]</user/SendEmail.jtp?type=node&node=5501&i=0>> wrote:

> Why do you think that's not expectation? What's the expected translation?
> Kylin will encode the dimension column original value into internal
> representation. And based on these encoding dictionary, Kylin would rewrite
> some SQL for better performance. In your case, the LIKE statement was
> translated into IN, then Kylin would find the query result by the key
> directly. It does not need filter all raw data.
>
> 2016-08-04 18:20 GMT+08:00 [hidden email]</user/SendEmail.jtp?type=node&node=5501&i=1> <[hidden email]</user/SendEmail.jtp?type=node&node=5501&i=2>>:
>
> >
> >
> >
> > Hi all,
> >
> > When we search with a sql “like clause”, we found in the log there will
> be
> > a
> > BuildInFunctionTransformer which will transform the “like clause” into
> “in
> > clause”
> > But values seems not exactly right. Below is my usecases.
> >
> > Case1 translate '%深海%'  to [深海新创专营店80002972, 义深海官方旗舰店80011438]
> > Case 2 translate  '%深海新创%'  to [深海新创专营店80002972]
> >
> > This is not espected.
> >
> > Is this a bug or can anyone help to explain? Thanks.
> >
> > 1.
> > sql:
> >
> > select merchant_name,*
> > from session_view_shop_0
> > where merchant_name like '%深海%'
> > and dt_year='2016'
> > and dt_month='07'
> > and dt_day >='25'
> > and dt_day <='28'
> >
> > 2016-08-04 17:38:46,095 INFO  [http-bio-7070-exec-31]
> > dict.BuildInFunctionTransformer:66 : Translated
> > {LIKE(KYLIN_REPORT_DB.SESSION_
> > VIEW_SHOP_0.MERCHANT_NAME,%深海%)} to IN clause:
> > {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN [深海新创专营店80002972,
> 义深
> > 海官方旗舰店80011438]}
> >
> > 2.
> > Sql:
> >
> > select merchant_name,*
> > from session_view_shop_0
> > where merchant_name like '%深海新创%'
> > and dt_year='2016'
> > and dt_month='07'
> > and dt_day >='25'
> > and dt_day <='28'
> >
> > 2016-08-04 17:41:52,321 INFO  [http-bio-7070-exec-31]
> > dict.BuildInFunctionTransformer:66 : Translated
> > {LIKE(KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME,%深海新创%)} to IN
> > clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN
> > [深海新创专营店80002972]}
> >
> >
> > Kylin version:apache-kylin-1.5.2.1-HBase1.x-bin.tar.gz
> >
> >
> >
> > --
> > View this message in context: http://apache-kylin.74782.x6.
> > nabble.com/Question-abount-BuildInFunctionTransformer-tp5499.html
> > Sent from the Apache Kylin mailing list archive at Nabble.com.
> >
>
>
>
> --
> With Warm regards
>
> Yiming Liu (刘一鸣)
>



--
Regards,

*Bin Mahone | 马洪宾*

________________________________
If you reply to this email, your message will be added to the discussion below:
http://apache-kylin.74782.x6.nabble.com/Question-abount-BuildInFunctionTransformer-tp5499p5501.html
To start a new topic under Apache Kylin, email ml-node+s74782n1h89@n6.nabble.com
To unsubscribe from Apache Kylin, click here<http://apache-kylin.74782.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=eXViby1kczFAeW9sbzI0LmNvbXwxfC0xMTE5OTYzOTg4>.
NAML<http://apache-kylin.74782.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


--
View this message in context: http://apache-kylin.74782.x6.nabble.com/Question-abount-BuildInFunctionTransformer-tp5499p5509.html
Sent from the Apache Kylin mailing list archive at Nabble.com.

Re: Question abount BuildInFunctionTransformer

Posted by hongbin ma <ma...@apache.org>.
To me the translation is expected behavior

On Thu, Aug 4, 2016 at 10:47 PM, Yiming Liu <li...@gmail.com> wrote:

> Why do you think that's not expectation? What's the expected translation?
> Kylin will encode the dimension column original value into internal
> representation. And based on these encoding dictionary, Kylin would rewrite
> some SQL for better performance. In your case, the LIKE statement was
> translated into IN, then Kylin would find the query result by the key
> directly. It does not need filter all raw data.
>
> 2016-08-04 18:20 GMT+08:00 yubo-ds1@yolo24.com <yu...@yolo24.com>:
>
> >
> >
> >
> > Hi all,
> >
> > When we search with a sql “like clause”, we found in the log there will
> be
> > a
> > BuildInFunctionTransformer which will transform the “like clause” into
> “in
> > clause”
> > But values seems not exactly right. Below is my usecases.
> >
> > Case1 translate '%深海%'  to [深海新创专营店80002972, 义深海官方旗舰店80011438]
> > Case 2 translate  '%深海新创%'  to [深海新创专营店80002972]
> >
> > This is not espected.
> >
> > Is this a bug or can anyone help to explain? Thanks.
> >
> > 1.
> > sql:
> >
> > select merchant_name,*
> > from session_view_shop_0
> > where merchant_name like '%深海%'
> > and dt_year='2016'
> > and dt_month='07'
> > and dt_day >='25'
> > and dt_day <='28'
> >
> > 2016-08-04 17:38:46,095 INFO  [http-bio-7070-exec-31]
> > dict.BuildInFunctionTransformer:66 : Translated
> > {LIKE(KYLIN_REPORT_DB.SESSION_
> > VIEW_SHOP_0.MERCHANT_NAME,%深海%)} to IN clause:
> > {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN [深海新创专营店80002972,
> 义深
> > 海官方旗舰店80011438]}
> >
> > 2.
> > Sql:
> >
> > select merchant_name,*
> > from session_view_shop_0
> > where merchant_name like '%深海新创%'
> > and dt_year='2016'
> > and dt_month='07'
> > and dt_day >='25'
> > and dt_day <='28'
> >
> > 2016-08-04 17:41:52,321 INFO  [http-bio-7070-exec-31]
> > dict.BuildInFunctionTransformer:66 : Translated
> > {LIKE(KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME,%深海新创%)} to IN
> > clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN
> > [深海新创专营店80002972]}
> >
> >
> > Kylin version:apache-kylin-1.5.2.1-HBase1.x-bin.tar.gz
> >
> >
> >
> > --
> > View this message in context: http://apache-kylin.74782.x6.
> > nabble.com/Question-abount-BuildInFunctionTransformer-tp5499.html
> > Sent from the Apache Kylin mailing list archive at Nabble.com.
> >
>
>
>
> --
> With Warm regards
>
> Yiming Liu (刘一鸣)
>



-- 
Regards,

*Bin Mahone | 马洪宾*

Re: Question abount BuildInFunctionTransformer

Posted by Yiming Liu <li...@gmail.com>.
Why do you think that's not expectation? What's the expected translation?
Kylin will encode the dimension column original value into internal
representation. And based on these encoding dictionary, Kylin would rewrite
some SQL for better performance. In your case, the LIKE statement was
translated into IN, then Kylin would find the query result by the key
directly. It does not need filter all raw data.

2016-08-04 18:20 GMT+08:00 yubo-ds1@yolo24.com <yu...@yolo24.com>:

>
>
>
> Hi all,
>
> When we search with a sql “like clause”, we found in the log there will be
> a
> BuildInFunctionTransformer which will transform the “like clause” into “in
> clause”
> But values seems not exactly right. Below is my usecases.
>
> Case1 translate '%深海%'  to [深海新创专营店80002972, 义深海官方旗舰店80011438]
> Case 2 translate  '%深海新创%'  to [深海新创专营店80002972]
>
> This is not espected.
>
> Is this a bug or can anyone help to explain? Thanks.
>
> 1.
> sql:
>
> select merchant_name,*
> from session_view_shop_0
> where merchant_name like '%深海%'
> and dt_year='2016'
> and dt_month='07'
> and dt_day >='25'
> and dt_day <='28'
>
> 2016-08-04 17:38:46,095 INFO  [http-bio-7070-exec-31]
> dict.BuildInFunctionTransformer:66 : Translated
> {LIKE(KYLIN_REPORT_DB.SESSION_
> VIEW_SHOP_0.MERCHANT_NAME,%深海%)} to IN clause:
> {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN [深海新创专营店80002972, 义深
> 海官方旗舰店80011438]}
>
> 2.
> Sql:
>
> select merchant_name,*
> from session_view_shop_0
> where merchant_name like '%深海新创%'
> and dt_year='2016'
> and dt_month='07'
> and dt_day >='25'
> and dt_day <='28'
>
> 2016-08-04 17:41:52,321 INFO  [http-bio-7070-exec-31]
> dict.BuildInFunctionTransformer:66 : Translated
> {LIKE(KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME,%深海新创%)} to IN
> clause: {KYLIN_REPORT_DB.SESSION_VIEW_SHOP_0.MERCHANT_NAME IN
> [深海新创专营店80002972]}
>
>
> Kylin version:apache-kylin-1.5.2.1-HBase1.x-bin.tar.gz
>
>
>
> --
> View this message in context: http://apache-kylin.74782.x6.
> nabble.com/Question-abount-BuildInFunctionTransformer-tp5499.html
> Sent from the Apache Kylin mailing list archive at Nabble.com.
>



-- 
With Warm regards

Yiming Liu (刘一鸣)