[jira] [Created] (KYLIN-2257) executed sql query cannot be reproduced
Luyuan Zhai created KYLIN-2257: -- Summary: executed sql query cannot be reproduced Key: KYLIN-2257 URL: https://issues.apache.org/jira/browse/KYLIN-2257 Project: Kylin Issue Type: Bug Components: Web Affects Versions: v1.6.0 Environment: windows Reporter: Luyuan Zhai Assignee: Zhong,Jason Priority: Minor I've done several sql query and click the result record to reproduce these sql. They worked well at the first time, yet cannot be reproduced in the query window simultaneously. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KYLIN-2256) No horizontal scroll bar in insight result window
Luyuan Zhai created KYLIN-2256: -- Summary: No horizontal scroll bar in insight result window Key: KYLIN-2256 URL: https://issues.apache.org/jira/browse/KYLIN-2256 Project: Kylin Issue Type: Improvement Components: Web Affects Versions: v1.6.0 Environment: windows Reporter: Luyuan Zhai Assignee: Zhong,Jason Priority: Minor I used learn_kylin as my data source and inputed SQL as: select * from kylin_sales limit 5. Then results returned below and in the result window, yet I cannot find a horizontal scroll bar to move from left to right even the kylin_sales table's width is longer than the result window. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
kylin 1.6.0 cardinality can't greater than 5000000 ?
I improved the version from 1.5.4.1 to 1.6.0 and modified KYLIN_HOME, and modied "kylin.dictionary.max.cardinality=500" to "kylin.dictionary.max.cardinality=3000" in file kylin.properties, then start kylin 1.6-->create model-->create cube-->build cube I got the following error message: java.lang.RuntimeException: Failed to create dictionary on DEFAULT.TEST_500W_TBL.ROWKEY at org.apache.kylin.dict.DictionaryManager.buildDictionary(DictionaryManager.java:325) at org.apache.kylin.cube.CubeManager.buildDictionary(CubeManager.java:222) at org.apache.kylin.cube.cli.DictionaryGeneratorCLI.processSegment(DictionaryGeneratorCLI.java:50) at org.apache.kylin.cube.cli.DictionaryGeneratorCLI.processSegment(DictionaryGeneratorCLI.java:41) at org.apache.kylin.engine.mr.steps.CreateDictionaryJob.run(CreateDictionaryJob.java:54) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.kylin.engine.mr.common.HadoopShellExecutable.doWork(HadoopShellExecutable.java:63) at org.apache.kylin.job.execution.AbstractExecutable.execute(AbstractExecutable.java:113) at org.apache.kylin.job.execution.DefaultChainedExecutable.doWork(DefaultChainedExecutable.java:57) at org.apache.kylin.job.execution.AbstractExecutable.execute(AbstractExecutable.java:113) at org.apache.kylin.job.impl.threadpool.DefaultScheduler$JobRunner.run(DefaultScheduler.java:136) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: Too high cardinality is not suitable for dictionary -- cardinality: 5359970 at org.apache.kylin.dict.DictionaryGenerator.buildDictionary(DictionaryGenerator.java:96)
Re: Issues in building cubes of Apache Kylin
Seems you were not using any Hadoop distribution, such HDP or CDH, but Apache Hadoop, Apache Hive and Apache HBase. Could you try export HIVE_CONF to your hive config path first? 2016-12-08 13:53 GMT+08:00 Samirul Haque : > Hi Billy, > > > > Thanks for your response. > > > > Output of the bin/find-dependency.sh is : > > > > KYLIN_HOME is set to /usr/local/kylin > > SLF4J: Class path contains multiple SLF4J bindings. > > SLF4J: Found binding in [jar:file:/usr/local/hive/lib/ > log4j-slf4j-impl-2.4.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] > > SLF4J: Found binding in [jar:file:/usr/local/hadoop/ > share/hadoop/common/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/ > impl/StaticLoggerBinder.class] > > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > > SLF4J: Actual binding is of type [org.apache.logging.slf4j. > Log4jLoggerFactory] > > > > Logging initialized using configuration in jar:file:/usr/local/hive/lib/ > hive-common-2.1.0.jar!/hive-log4j2.properties Async: true > > HIVE_CONF is set to: /home/hduser/bin:/home/hduser/ > .local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/ > bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ > hadoop/bin:/usr/lib/jvm/java-8-openjdk-amd64/bin:/usr/ > local/hive/bin:/usr/local/kylin/bin:/usr/local/Hbase/ > bin:/usr/local/hadoop/bin:/usr/lib/jvm/java-8-openjdk- > amd64/bin:/usr/local/hive/bin:/usr/local/kylin/bin:/usr/ > local/Hbase/bin:/usr/local/hadoop/bin:/usr/lib/jvm/java- > 8-openjdk-amd64/bin:/usr/local/hive/bin:/usr/local/ > kylin/bin:/usr/local/Hbase/bin:/usr/local/hadoop/bin:/ > usr/lib/jvm/java-8-openjdk-amd64/bin:/usr/local/hive/bin: > /usr/local/kylin/bin:/usr/local/Hbase/bin:/usr/local/ > hadoop/bin:/usr/lib/jvm/java-8-openjdk-amd64/bin:/usr/ > local/hive/bin:/usr/local/kylin/bin:/usr/local/Hbase/ > bin:/usr/local/hadoop/bin:/usr/lib/jvm/java-8-openjdk- > amd64/bin:/usr/local/hive/bin:/usr/local/kylin/bin:/usr/ > local/Hbase/bin:/usr/local/hive/conf, use it to locate hive > configurations. > > HCAT_HOME is set to: /usr/local/hive/hcatalog, use it to find hcatalog > path: > > hive dependency: /home/hduser/bin:/home/hduser/ > .local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/ > bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ > hadoop/bin:/usr/lib/jvm/java-8-openjdk-amd64/bin:/usr/ > local/hive/bin:/usr/local/kylin/bin:/usr/local/Hbase/ > bin:/usr/local/hadoop/bin:/usr/lib/jvm/java-8-openjdk- > amd64/bin:/usr/local/hive/bin:/usr/local/kylin/bin:/usr/ > local/Hbase/bin:/usr/local/hadoop/bin:/usr/lib/jvm/java- > 8-openjdk-amd64/bin:/usr/local/hive/bin:/usr/local/ > kylin/bin:/usr/local/Hbase/bin:/usr/local/hadoop/bin:/ > usr/lib/jvm/java-8-openjdk-amd64/bin:/usr/local/hive/bin: > /usr/local/kylin/bin:/usr/local/Hbase/bin:/usr/local/ > hadoop/bin:/usr/lib/jvm/java-8-openjdk-amd64/bin:/usr/ > local/hive/bin:/usr/local/kylin/bin:/usr/local/Hbase/ > bin:/usr/local/hadoop/bin:/usr/lib/jvm/java-8-openjdk- > amd64/bin:/usr/local/hive/bin:/usr/local/kylin/bin:/usr/ > local/Hbase/bin:/usr/local/hive/conf:/usr/local/hive/lib/ > antlr-runtime-3.4.jar:/usr/local/hive/lib/servlet-api-2. > 4.jar:/usr/local/hive/lib/hive-llap-client-2.1.0.jar:/ > usr/local/hive/lib/twill-zookeeper-0.6.0-incubating. > jar:/usr/local/hive/lib/bonecp-0.8.0.RELEASE.jar:/usr/ > local/hive/lib/hbase-annotations-1.1.1.jar:/usr/ > local/hive/lib/zookeeper-3.4.6.jar:/usr/local/hive/lib/ > guice-assistedinject-3.0.jar:/usr/local/hive/lib/ivy-2.4.0. > jar:/usr/local/hive/lib/datanucleus-rdbms-4.1.7.jar:/ > usr/local/hive/lib/parquet-hadoop-bundle-1.8.1.jar:/usr/ > local/hive/lib/hive-exec-2.1.0.jar:/usr/local/hive/lib/ > hbase-common-1.1.1.jar:/usr/local/hive/lib/commons-lang3- > 3.1.jar:/usr/local/hive/lib/commons-pool-1.5.4.jar:/usr/ > local/hive/lib/accumulo-start-1.6.0.jar:/usr/local/hive/lib/ > twill-common-0.6.0-incubating.jar:/usr/local/hive/lib/jetty- > 6.1.26.jar:/usr/local/hive/lib/jackson-core-2.4.2.jar:/ > usr/local/hive/lib/commons-httpclient-3.0.1.jar:/usr/ > local/hive/lib/hive-jdbc-2.1.0.jar:/usr/local/hive/lib/ > hive-serde-2.1.0.jar:/usr/local/hive/lib/hbase-prefix- > tree-1.1.1.jar:/usr/local/hive/lib/commons-lang-2.6.jar: > /usr/local/hive/lib/opencsv-2.3.jar:/usr/local/hive/lib/jsp- > api-2.1.jar:/usr/local/hive/lib/antlr-2.7.7.jar:/usr/ > local/hive/lib/libfb303-0.9.3.jar:/usr/local/hive/lib/ > slider-core-0.90.2-incubating.jar:/usr/local/hive/lib/jsp-2. > 1-6.1.14.jar:/usr/local/hive/lib/metrics-json-3.1.0.jar:/ > usr/local/hive/lib/log4j-slf4j-impl-2.4.1.jar:/usr/ > local/hive/lib/jamon-runtime-2.3.1.jar:/usr/local/hive/lib/ > avro-1.7.7.jar:/usr/local/hive/lib/jetty-all-server-7.6. > 0.v20120127.jar:/usr/local/hive/lib/activation-1.1.jar:/ > usr/local/hive/lib/derby.jar:/usr/local/hive/lib/stax-api-1. > 0.1.jar:/usr/local/hive/lib/tephra-api-0.6.0.jar:/usr/ > local/hive/lib/netty-all-4.0.23.Final.jar:/usr/local/hive/ > lib/jersey-client-1.9.jar:/usr/local/hive/lib/metrics- > core-3.1.0.jar:/usr/local/hive/lib/paranamer-2.
回复：Re: 答复: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
对于SQL查询记录早了8小时的问题，我使用了JDBC和Kylin WEB两种方式进行测试，结果都是查询记录早了8小时。这说明Kylin服务端从HBase中扫描记录时，读取的记录就已经比实际时间早了8小时。所以，可能是Kylin服务端在处理kafka数据的时候，对于时间的处理有些问题。 在2016年12月8日 12:36， Jian Zhong写道： So, you can get right result you want for non-streaming cube? Did you query on Kylin UI or use jdbc driver? 2016-12-08 12:32 GMT+08:00 仇同心 : > streaming cube > > -邮件原件- > 发件人: Jian Zhong [mailto:zhongj...@apache.org] > 发送时间: 2016年12月8日 12:32 > 收件人: dev@kylin.apache.org > 主题: Re: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > this only happens in streaming cube or all cubes? > > 2016-12-08 11:28 GMT+08:00 Billy Liu : > > > here here some threads about getting the right Date from Kylin > > http://apache-kylin.74782.x6.nabble.com/JDBC-query-result- > > Date-column-get-wrong-value-td5370.html > > > > 在 2016年12月8日 上午11:09，仇同心 写道： > > > > > 是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 > > > > > > > > > > > > -邮件原件- > > > 发件人: 汪胜 [mailto:sky...@163.com] > > > 发送时间: 2016年12月8日 11:06 > > > 收件人: dev > > > 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > > > > > 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式， > > > 我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候， > > > 没有考虑到配置文件的时区问题，但是我还没有进行验证。 > > > 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ > > > > > > > > > > > > > > > > > > 在2016年12月8日 10:57， 仇同心写道： > > > > > > 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 > > > > > > 但是segment的时间早8个小时： > > > Start Time: 2016-12-08 02:44:00 > > > End Time: 2016-12-08 02:45:00 > > > > > > 请问这个问题是kylin哪里造成的？ > > > > > > > > > 发件人: 汪胜 [mailto:sky...@163.com] > > > 发送时间: 2016年12月6日 21:17 > > > 收件人: dev > > > 主题: Re: Kylin1.6.0流式Cube查询时间错误 > > > > > > 你好， > > > 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： > > > > > > 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage” > > 标签下显示的每个segment的start > > > time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。 > > > 我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_ > > > unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ > > > -- > > > [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] > > > --- > > > [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] > > > -- > > > [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] > > > > > > 2 > > > 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？ > > > （ > > > 我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） > > > > > > [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] > > > 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。 > > > 每一列数据的时间都比电脑上的实际时间晚了8小时。 > > > > > > > > > > > > > > > 在2016年12月6日 20:30， Mario Copperfield > > whfcen...@gmail.com>> 写道： > > > > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 > > > > > > On 6 Dec 2016, 19:40 +0800, 汪胜 > > > mailto:sky...@163.com>>, > > > wrote: > > > > 你好， > > > > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候， > > 发现所有的“MINUTE_START” > > > 列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时， > > > 但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > > > > 注：我在kylin.properties文件中将timezone改为了GMT+8 > > > > > > > > > > > > > > >
回复：Re: 答复: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
我之前使用Kylin的时候从来没有出现过这种问题。在安装Kylin1.6.0之后，才出现这种问题的。 我在HBase里面查看流式cube对应的json数据时，每个segment的start time和end time对应的timestamp都是正确的，但是在Kylin WEB上显示的就早了8小时。用JDBC获取的timestamp肯定也是正确的，所以应该是Kylin WEB转换的问题。 在2016年12月8日 12:36， Jian Zhong写道： So, you can get right result you want for non-streaming cube? Did you query on Kylin UI or use jdbc driver? 2016-12-08 12:32 GMT+08:00 仇同心 : > streaming cube > > -邮件原件- > 发件人: Jian Zhong [mailto:zhongj...@apache.org] > 发送时间: 2016年12月8日 12:32 > 收件人: dev@kylin.apache.org > 主题: Re: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > this only happens in streaming cube or all cubes? > > 2016-12-08 11:28 GMT+08:00 Billy Liu : > > > here here some threads about getting the right Date from Kylin > > http://apache-kylin.74782.x6.nabble.com/JDBC-query-result- > > Date-column-get-wrong-value-td5370.html > > > > 在 2016年12月8日 上午11:09，仇同心 写道： > > > > > 是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 > > > > > > > > > > > > -邮件原件- > > > 发件人: 汪胜 [mailto:sky...@163.com] > > > 发送时间: 2016年12月8日 11:06 > > > 收件人: dev > > > 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > > > > > 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式， > > > 我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候， > > > 没有考虑到配置文件的时区问题，但是我还没有进行验证。 > > > 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ > > > > > > > > > > > > > > > > > > 在2016年12月8日 10:57， 仇同心写道： > > > > > > 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 > > > > > > 但是segment的时间早8个小时： > > > Start Time: 2016-12-08 02:44:00 > > > End Time: 2016-12-08 02:45:00 > > > > > > 请问这个问题是kylin哪里造成的？ > > > > > > > > > 发件人: 汪胜 [mailto:sky...@163.com] > > > 发送时间: 2016年12月6日 21:17 > > > 收件人: dev > > > 主题: Re: Kylin1.6.0流式Cube查询时间错误 > > > > > > 你好， > > > 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： > > > > > > 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage” > > 标签下显示的每个segment的start > > > time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。 > > > 我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_ > > > unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ > > > -- > > > [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] > > > --- > > > [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] > > > -- > > > [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] > > > > > > 2 > > > 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？ > > > （ > > > 我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） > > > > > > [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] > > > 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。 > > > 每一列数据的时间都比电脑上的实际时间晚了8小时。 > > > > > > > > > > > > > > > 在2016年12月6日 20:30， Mario Copperfield > > whfcen...@gmail.com>> 写道： > > > > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 > > > > > > On 6 Dec 2016, 19:40 +0800, 汪胜 > > > mailto:sky...@163.com>>, > > > wrote: > > > > 你好， > > > > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候， > > 发现所有的“MINUTE_START” > > > 列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时， > > > 但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > > > > 注：我在kylin.properties文件中将timezone改为了GMT+8 > > > > > > > > > > > > > > >
Re: 答复: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
So, you can get right result you want for non-streaming cube? Did you query on Kylin UI or use jdbc driver? 2016-12-08 12:32 GMT+08:00 仇同心 : > streaming cube > > -邮件原件- > 发件人: Jian Zhong [mailto:zhongj...@apache.org] > 发送时间: 2016年12月8日 12:32 > 收件人: dev@kylin.apache.org > 主题: Re: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > this only happens in streaming cube or all cubes? > > 2016-12-08 11:28 GMT+08:00 Billy Liu : > > > here here some threads about getting the right Date from Kylin > > http://apache-kylin.74782.x6.nabble.com/JDBC-query-result- > > Date-column-get-wrong-value-td5370.html > > > > 在 2016年12月8日 上午11:09，仇同心 写道： > > > > > 是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 > > > > > > > > > > > > -邮件原件- > > > 发件人: 汪胜 [mailto:sky...@163.com] > > > 发送时间: 2016年12月8日 11:06 > > > 收件人: dev > > > 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > > > > > 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式， > > > 我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候， > > > 没有考虑到配置文件的时区问题，但是我还没有进行验证。 > > > 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ > > > > > > > > > > > > > > > > > > 在2016年12月8日 10:57， 仇同心写道： > > > > > > 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 > > > > > > 但是segment的时间早8个小时： > > > Start Time: 2016-12-08 02:44:00 > > > End Time: 2016-12-08 02:45:00 > > > > > > 请问这个问题是kylin哪里造成的？ > > > > > > > > > 发件人: 汪胜 [mailto:sky...@163.com] > > > 发送时间: 2016年12月6日 21:17 > > > 收件人: dev > > > 主题: Re: Kylin1.6.0流式Cube查询时间错误 > > > > > > 你好， > > > 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： > > > > > > 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage” > > 标签下显示的每个segment的start > > > time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。 > > > 我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_ > > > unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ > > > -- > > > [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] > > > --- > > > [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] > > > -- > > > [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] > > > > > > 2 > > > 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？ > > > （ > > > 我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） > > > > > > [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] > > > 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。 > > > 每一列数据的时间都比电脑上的实际时间晚了8小时。 > > > > > > > > > > > > > > > 在2016年12月6日 20:30， Mario Copperfield > > whfcen...@gmail.com>> 写道： > > > > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 > > > > > > On 6 Dec 2016, 19:40 +0800, 汪胜 > > > mailto:sky...@163.com>>, > > > wrote: > > > > 你好， > > > > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候， > > 发现所有的“MINUTE_START” > > > 列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时， > > > 但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > > > > 注：我在kylin.properties文件中将timezone改为了GMT+8 > > > > > > > > > > > > > > >
答复: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
streaming cube -邮件原件- 发件人: Jian Zhong [mailto:zhongj...@apache.org] 发送时间: 2016年12月8日 12:32 收件人: dev@kylin.apache.org 主题: Re: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误 this only happens in streaming cube or all cubes? 2016-12-08 11:28 GMT+08:00 Billy Liu : > here here some threads about getting the right Date from Kylin > http://apache-kylin.74782.x6.nabble.com/JDBC-query-result- > Date-column-get-wrong-value-td5370.html > > 在 2016年12月8日 上午11:09，仇同心 写道： > > > 是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 > > > > > > > > -邮件原件- > > 发件人: 汪胜 [mailto:sky...@163.com] > > 发送时间: 2016年12月8日 11:06 > > 收件人: dev > > 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > > > 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式， > > 我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候， > > 没有考虑到配置文件的时区问题，但是我还没有进行验证。 > > 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ > > > > > > > > > > > > 在2016年12月8日 10:57， 仇同心写道： > > > > 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 > > > > 但是segment的时间早8个小时： > > Start Time: 2016-12-08 02:44:00 > > End Time: 2016-12-08 02:45:00 > > > > 请问这个问题是kylin哪里造成的？ > > > > > > 发件人: 汪胜 [mailto:sky...@163.com] > > 发送时间: 2016年12月6日 21:17 > > 收件人: dev > > 主题: Re: Kylin1.6.0流式Cube查询时间错误 > > > > 你好， > > 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： > > > > 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage” > 标签下显示的每个segment的start > > time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。 > > 我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_ > > unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ > > -- > > [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] > > --- > > [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] > > -- > > [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] > > > > 2 > > 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？ > > （ > > 我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） > > > > [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] > > 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。 > > 每一列数据的时间都比电脑上的实际时间晚了8小时。 > > > > > > > > > > 在2016年12月6日 20:30， Mario Copperfield > whfcen...@gmail.com>> 写道： > > > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 > > > > On 6 Dec 2016, 19:40 +0800, 汪胜 > > mailto:sky...@163.com>>, > > wrote: > > > 你好， > > > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候， > 发现所有的“MINUTE_START” > > 列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时， > > 但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > > > 注：我在kylin.properties文件中将timezone改为了GMT+8 > > > > > > > > >
Re: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
this only happens in streaming cube or all cubes? 2016-12-08 11:28 GMT+08:00 Billy Liu : > here here some threads about getting the right Date from Kylin > http://apache-kylin.74782.x6.nabble.com/JDBC-query-result- > Date-column-get-wrong-value-td5370.html > > 在 2016年12月8日 上午11:09，仇同心 写道： > > > 是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 > > > > > > > > -邮件原件- > > 发件人: 汪胜 [mailto:sky...@163.com] > > 发送时间: 2016年12月8日 11:06 > > 收件人: dev > > 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > > > 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式， > > 我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候， > > 没有考虑到配置文件的时区问题，但是我还没有进行验证。 > > 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ > > > > > > > > > > > > 在2016年12月8日 10:57， 仇同心写道： > > > > 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 > > > > 但是segment的时间早8个小时： > > Start Time: 2016-12-08 02:44:00 > > End Time: 2016-12-08 02:45:00 > > > > 请问这个问题是kylin哪里造成的？ > > > > > > 发件人: 汪胜 [mailto:sky...@163.com] > > 发送时间: 2016年12月6日 21:17 > > 收件人: dev > > 主题: Re: Kylin1.6.0流式Cube查询时间错误 > > > > 你好， > > 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： > > > > 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage” > 标签下显示的每个segment的start > > time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。 > > 我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_ > > unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ > > -- > > [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] > > --- > > [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] > > -- > > [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] > > > > 2 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？（ > > 我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） > > > > [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] > > 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。 > > 每一列数据的时间都比电脑上的实际时间晚了8小时。 > > > > > > > > > > 在2016年12月6日 20:30， Mario Copperfield > whfcen...@gmail.com>> 写道： > > > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 > > > > On 6 Dec 2016, 19:40 +0800, 汪胜 mailto:sky...@163.com>>, > > wrote: > > > 你好， > > > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候， > 发现所有的“MINUTE_START” > > 列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时， > > 但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > > > 注：我在kylin.properties文件中将timezone改为了GMT+8 > > > > > > > > >
Re: 答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
here here some threads about getting the right Date from Kylin http://apache-kylin.74782.x6.nabble.com/JDBC-query-result-Date-column-get-wrong-value-td5370.html 在 2016年12月8日 上午11:09，仇同心 写道： > 是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 > > > > -邮件原件- > 发件人: 汪胜 [mailto:sky...@163.com] > 发送时间: 2016年12月8日 11:06 > 收件人: dev > 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 > > 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式， > 我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候， > 没有考虑到配置文件的时区问题，但是我还没有进行验证。 > 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ > > > > > > 在2016年12月8日 10:57， 仇同心写道： > > 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 > > 但是segment的时间早8个小时： > Start Time: 2016-12-08 02:44:00 > End Time: 2016-12-08 02:45:00 > > 请问这个问题是kylin哪里造成的？ > > > 发件人: 汪胜 [mailto:sky...@163.com] > 发送时间: 2016年12月6日 21:17 > 收件人: dev > 主题: Re: Kylin1.6.0流式Cube查询时间错误 > > 你好， > 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： > > 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage”标签下显示的每个segment的start > time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。 > 我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_ > unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ > -- > [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] > --- > [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] > -- > [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] > > 2 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？（ > 我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） > > [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] > 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。 > 每一列数据的时间都比电脑上的实际时间晚了8小时。 > > > > > 在2016年12月6日 20:30， Mario Copperfield whfcen...@gmail.com>> 写道： > > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 > > On 6 Dec 2016, 19:40 +0800, 汪胜 mailto:sky...@163.com>>, > wrote: > > 你好， > > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候，发现所有的“MINUTE_START” > 列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时， > 但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > > 注：我在kylin.properties文件中将timezone改为了GMT+8 > > > >
答复: 回复：答复: Kylin1.6.0流式Cube查询时间错误
是的，构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时 -邮件原件- 发件人: 汪胜 [mailto:sky...@163.com] 发送时间: 2016年12月8日 11:06 收件人: dev 主题: 回复：答复: Kylin1.6.0流式Cube查询时间错误 我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式，我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候，没有考虑到配置文件的时区问题，但是我还没有进行验证。 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ 在2016年12月8日 10:57， 仇同心写道： 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 但是segment的时间早8个小时： Start Time: 2016-12-08 02:44:00 End Time: 2016-12-08 02:45:00 请问这个问题是kylin哪里造成的？ 发件人: 汪胜 [mailto:sky...@163.com] 发送时间: 2016年12月6日 21:17 收件人: dev 主题: Re: Kylin1.6.0流式Cube查询时间错误 你好， 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage”标签下显示的每个segment的start time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ -- [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] --- [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] -- [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] 2 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？（我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。每一列数据的时间都比电脑上的实际时间晚了8小时。 在2016年12月6日 20:30， Mario Copperfield mailto:xwhfcen...@gmail.com>> 写道： > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 On 6 Dec 2016, 19:40 +0800, 汪胜 mailto:sky...@163.com>>, wrote: > 你好， > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候，发现所有的“MINUTE_START”列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时，但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > 注：我在kylin.properties文件中将timezone改为了GMT+8
回复：答复: Kylin1.6.0流式Cube查询时间错误
我在查看前端页面代码的时候，发现传到前端的start time和end time都是timestamp的形式，我自己对这些timestamp进行转换的时候，发现时间是正确。因此我觉得有可能是前端在转换这些timestamp的时候，没有考虑到配置文件的时区问题，但是我还没有进行验证。 除此之外，我在对构建好的segment进行SQL查询的时候，发现这些查询记录的时间也都是早了8小时，不知道你有没有碰到这个问题？ 在2016年12月8日 10:57， 仇同心写道： 我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 但是segment的时间早8个小时： Start Time: 2016-12-08 02:44:00 End Time: 2016-12-08 02:45:00 请问这个问题是kylin哪里造成的？ 发件人: 汪胜 [mailto:sky...@163.com] 发送时间: 2016年12月6日 21:17 收件人: dev 主题: Re: Kylin1.6.0流式Cube查询时间错误 你好， 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage”标签下显示的每个segment的start time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ -- [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] --- [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] -- [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] 2 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？（我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。每一列数据的时间都比电脑上的实际时间晚了8小时。 在2016年12月6日 20:30， Mario Copperfield mailto:xwhfcen...@gmail.com>> 写道： > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 On 6 Dec 2016, 19:40 +0800, 汪胜 mailto:sky...@163.com>>, wrote: > 你好， > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候，发现所有的“MINUTE_START”列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时，但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > 注：我在kylin.properties文件中将timezone改为了GMT+8
Re: Re: 使用全局字典报错AppendTrieDictionary can't retrive value from id
Thank you for your answer, I will try my best to use English to ask question.
发件人： Billy Liu
发送时间： 2016-12-08 09:15
收件人： dev
主题： Re: Re: 使用全局字典报错AppendTrieDictionary can't retrive value from id
To use GlobalDictionaryBuilder, there are some benefits, but also some
limitation. It's very useful for precise count by using bitmap dictionary,
but could not preserve the value order. That means it supports equals
operator, but not greater(less) than operator.
Back to your case, you should define precise count in the Cube measure
settings page(Return Type is Precise(bitmap actually), not hllc12 in your
json definition).
Since you are distinct count on column "NAME", please define Name for
global dictionary. Currently, you have defined
"ROWKEY","SEX","LOCAL","JOB", but without "NAME".
Then it should work.
By the way, you have so many ultra high cardinality dimensions, and put all
of them as normal dimensions. It will cost too much resource for building
and index storage. If you are caring about TopN requirement, you could
define topN measure also, order by SUM(1), it will be more efficiency
for "select
label, count(label) from USERCASE_20161204 group by label order by label
desc".
If you could, please using English also. This is worldwide community,
English is the better language for everyone.
2016-12-06 13:24 GMT+08:00 wang...@snqu.com :
> Hi Roger
>
> cube的详细定义如下：
> {
> "uuid": "9a27b749-1989-482a-a3bb-6f4fe1f8f3a0",
> "last_modified": 1480931382552,
> "version": "1.6.0",
> "name": "dmp_cube_590w",
> "model_name": "dmp_model_590w",
> "description": "",
> "null_string": null,
> "dimensions": [
> {
> "name": "ROWKEY",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "ROWKEY",
> "derived": null
> },
> {
> "name": "TIMESTAMP",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "TIMESTAMP",
> "derived": null
> },
> {
> "name": "NAME",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "NAME",
> "derived": null
> },
> {
> "name": "SEX",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "SEX",
> "derived": null
> },
> {
> "name": "LOCAL",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "LOCAL",
> "derived": null
> },
> {
> "name": "JOB",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "JOB",
> "derived": null
> },
> {
> "name": "LABEL",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "LABEL",
> "derived": null
> }
> ],
> "measures": [
> {
> "name": "_COUNT_",
> "function": {
> "expression": "COUNT",
> "parameter": {
> "type": "constant",
> "value": "1",
> "next_parameter": null
> },
> "returntype": "bigint"
> },
> "dependent_measure_ref": null
> },
> {
> "name": "CD_NAME",
> "function": {
> "expression": "COUNT_DISTINCT",
> "parameter": {
> "type": "column",
> "value": "NAME",
> "next_parameter": null
> },
> "returntype": "hllc12"
> },
> "dependent_measure_ref": null
> }
> ],
> "dictionaries": [
> {
> "column": "ROWKEY",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> },
> {
> "column": "SEX",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> },
> {
> "column": "LOCAL",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> },
> {
> "column": "JOB",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> }
> ],
> "rowkey": {
> "rowkey_columns": [
> {
> "column": "ROWKEY",
> "encoding": "dict",
> "isShardBy": true
> },
> {
> "column": "NAME",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "TIMESTAMP",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "SEX",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "LOCAL",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "JOB",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "LABEL",
> "encoding": "dict",
> "isShardBy": false
> }
> ]
> },
> "hbase_mapping": {
> "column_family": [
> {
> "name": "F1",
> "columns": [
> {
> "qualifier": "M",
> "measure_refs": [
> "_COUNT_"
> ]
> }
> ]
> },
> {
> "name": "F2",
> "columns": [
> {
> "qualifier": "M",
> "measure_refs": [
> "CD_NAME"
>
答复: Kylin1.6.0流式Cube查询时间错误
我也遇到了一样的问题，cube的Last Build Time 是正确的：2016-12-08 10:48:37 GMT+8 但是segment的时间早8个小时： Start Time: 2016-12-08 02:44:00 End Time: 2016-12-08 02:45:00 请问这个问题是kylin哪里造成的？ 发件人: 汪胜 [mailto:sky...@163.com] 发送时间: 2016年12月6日 21:17 收件人: dev 主题: Re: Kylin1.6.0流式Cube查询时间错误 你好， 非常感谢您的回答，但是我仍然有两个地方不太理解，望指教： 1 如果kylin.properties改的是页面上显示的时间，那么为什么在web页面的“Storage”标签下显示的每个segment的start time和end time则比电脑早了8个小时，但是cube的创建时间和最后一次修改时间显示却是正确的。我在HBase中查看对应cube的JSON数据，在这里面每个segment的起始和结束时间的timestamp，用mysql的from_unixtime函数转换之后与电脑上的时间是一致的，这是否是前端页面解析的问题？ -- [cid:56910fa5$1$158d4477d62$Coremail$skyyws$163.com] --- [cid:1deff3e1$2$158d4477d63$Coremail$skyyws$163.com] -- [cid:6448603e$3$158d4477d63$Coremail$skyyws$163.com] 2 您说的流式Cube用脚本启动之后，应该手动加上8小时，是否是指：Kylin服务端在处理kafka的数据时，时间会比电脑上的时间少8小时？（我在对流式Cube进行SQL查询时，发现Kylin服务端返回的每一列的时间都比电脑上的晚了8小时） [cid:d96b8d1$4$158d4477d63$Coremail$skyyws$163.com] 这个数据是通过IDEA远程调试得到的来自Kylin服务器的数据，是Kylin通过查询HBase之后返回的。每一列数据的时间都比电脑上的实际时间晚了8小时。 在2016年12月6日 20:30， Mario Copperfield mailto:xwhfcen...@gmail.com>> 写道： > kylin.properties改的应该是页面上显示的时间，流式Cube用脚本启动了话和页面上的时间是不一致的，应该手动加上8小时 On 6 Dec 2016, 19:40 +0800, 汪胜 mailto:sky...@163.com>>, wrote: > 你好， > 我在安装了Kylin1.6.0之后，根据官网的教程，成功地构建了流式cube。但在进行SQL查询的时候，发现所有的“MINUTE_START”列的时间比实际时间少了8个小时，而且在WEB页面上，每个流式segment的起始和结束时间也少了8个小时，但是cube的创建时间和最后一次修改时间都是正确的，请问可能是什么原因呢？ > 注：我在kylin.properties文件中将timezone改为了GMT+8
Re:sql query(min/max over) seems to be replicated-more info
It seems the images cannot be present. So I grabbed part of tables mentioned. >>Table structure looks as: | Row | TRANS_ID | PART_DT | LSTG_FORMAT_NAME | LEAF_CATEG_ID | LSTG_SITE_ID | SLR_SEGMENT_CD | PRICE | ITEM_COUNT | SELLER_ID | USER_ID | REGION | | 1 | 0 | 2012-12-14 | Others | 88750 | 0 | 11 | 36.2828 | 0 | 1349 | ANALYST | Beijing | >>(Part)Results returned as: | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | FP-non GTC | 49.81376 | 145.495 | 0.0537 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | | Others | 49.2756 | 186.9764 | 0.0232 | Does it look more detailed? Best, Luyuan(Adora) At 2016-12-08 10:13:39, "翟鹿渊" wrote: Hi Kylin Dev team, I used a dataset called learn_kylin, the sample data of table kylin_sales looks like: A problem came when I inputed sql query as: " select LSTG_FORMAT_NAME, avg(price) over(partition by LSTG_FORMAT_NAME) as price_level, max(price) over(partition by LSTG_FORMAT_NAME) as price_max, min(price) over(partition by LSTG_FORMAT_NAME) as price_min from kylin_sales" then replicated results returned. They look like: How does this happen and if there is any way to solve it? Thank you! Luyuan(Adora)
sql query(min/max over) seems to be replicated
Hi Kylin Dev team, I used a dataset called learn_kylin, the sample data of table kylin_sales looks like: A problem came when I inputed sql query as: " select LSTG_FORMAT_NAME, avg(price) over(partition by LSTG_FORMAT_NAME) as price_level, max(price) over(partition by LSTG_FORMAT_NAME) as price_max, min(price) over(partition by LSTG_FORMAT_NAME) as price_min from kylin_sales" then replicated results returned. They look like: How does this happen and if there is any way to solve it? Thank you! Luyuan(Adora)
[jira] [Created] (KYLIN-2255) Drop v1 CubeStorageQuery
liyang created KYLIN-2255: - Summary: Drop v1 CubeStorageQuery Key: KYLIN-2255 URL: https://issues.apache.org/jira/browse/KYLIN-2255 Project: Kylin Issue Type: Improvement Reporter: liyang Assignee: liyang There are two versions of storage query implementation. - org.apache.kylin.storage.hbase.cube.v2.CubeStorageQuery - org.apache.kylin.storage.hbase.cube.v1.CubeStorageQuery The v2 was created in Aug 2015 and has been stable for a long time. It's time to say bye to the v1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: select * clause still case all regionserver crash
about v1.5.4,"select * from table limit N" clause seems not to crash regionserver,but meantime no result return for the clause -- View this message in context: http://apache-kylin.74782.x6.nabble.com/select-clause-still-cause-all-regionserver-crash-tp6474p6535.html Sent from the Apache Kylin mailing list archive at Nabble.com.
Re: kylin1.6版本增量build的BUG
Thanks for the reporting, but the images could not display. 在 2016年12月8日 上午8:55，gaolv123...@163.com 写道： > kylin1.6版本增量build的BUG > > 如下两张图片所示，条件只能是日期嘛？ > 并且手动输入的无效，必须通过控件输入 > > > -- > gaolv123...@163.com >
Re: Re: 使用全局字典报错AppendTrieDictionary can't retrive value from id
To use GlobalDictionaryBuilder, there are some benefits, but also some
limitation. It's very useful for precise count by using bitmap dictionary,
but could not preserve the value order. That means it supports equals
operator, but not greater(less) than operator.
Back to your case, you should define precise count in the Cube measure
settings page(Return Type is Precise(bitmap actually), not hllc12 in your
json definition).
Since you are distinct count on column "NAME", please define Name for
global dictionary. Currently, you have defined
"ROWKEY","SEX","LOCAL","JOB", but without "NAME".
Then it should work.
By the way, you have so many ultra high cardinality dimensions, and put all
of them as normal dimensions. It will cost too much resource for building
and index storage. If you are caring about TopN requirement, you could
define topN measure also, order by SUM(1), it will be more efficiency
for "select
label, count(label) from USERCASE_20161204 group by label order by label
desc".
If you could, please using English also. This is worldwide community,
English is the better language for everyone.
2016-12-06 13:24 GMT+08:00 wang...@snqu.com :
> Hi Roger
>
> cube的详细定义如下：
> {
> "uuid": "9a27b749-1989-482a-a3bb-6f4fe1f8f3a0",
> "last_modified": 1480931382552,
> "version": "1.6.0",
> "name": "dmp_cube_590w",
> "model_name": "dmp_model_590w",
> "description": "",
> "null_string": null,
> "dimensions": [
> {
> "name": "ROWKEY",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "ROWKEY",
> "derived": null
> },
> {
> "name": "TIMESTAMP",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "TIMESTAMP",
> "derived": null
> },
> {
> "name": "NAME",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "NAME",
> "derived": null
> },
> {
> "name": "SEX",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "SEX",
> "derived": null
> },
> {
> "name": "LOCAL",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "LOCAL",
> "derived": null
> },
> {
> "name": "JOB",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "JOB",
> "derived": null
> },
> {
> "name": "LABEL",
> "table": "DEFAULT.USERCASE_20161204",
> "column": "LABEL",
> "derived": null
> }
> ],
> "measures": [
> {
> "name": "_COUNT_",
> "function": {
> "expression": "COUNT",
> "parameter": {
> "type": "constant",
> "value": "1",
> "next_parameter": null
> },
> "returntype": "bigint"
> },
> "dependent_measure_ref": null
> },
> {
> "name": "CD_NAME",
> "function": {
> "expression": "COUNT_DISTINCT",
> "parameter": {
> "type": "column",
> "value": "NAME",
> "next_parameter": null
> },
> "returntype": "hllc12"
> },
> "dependent_measure_ref": null
> }
> ],
> "dictionaries": [
> {
> "column": "ROWKEY",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> },
> {
> "column": "SEX",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> },
> {
> "column": "LOCAL",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> },
> {
> "column": "JOB",
> "builder": "org.apache.kylin.dict.GlobalDictionaryBuilder"
> }
> ],
> "rowkey": {
> "rowkey_columns": [
> {
> "column": "ROWKEY",
> "encoding": "dict",
> "isShardBy": true
> },
> {
> "column": "NAME",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "TIMESTAMP",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "SEX",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "LOCAL",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "JOB",
> "encoding": "dict",
> "isShardBy": false
> },
> {
> "column": "LABEL",
> "encoding": "dict",
> "isShardBy": false
> }
> ]
> },
> "hbase_mapping": {
> "column_family": [
> {
> "name": "F1",
> "columns": [
> {
> "qualifier": "M",
> "measure_refs": [
> "_COUNT_"
> ]
> }
> ]
> },
> {
> "name": "F2",
> "columns": [
> {
> "qualifier": "M",
> "measure_refs": [
> "CD_NAME"
> ]
> }
> ]
> }
> ]
> },
> "aggregation_groups": [
> {
> "includes": [
> "ROWKEY",
> "NAME",
> "SEX",
> "LOCAL",
>
kylin1.6版本增量build的BUG
kylin1.6版本增量build的BUG 如下两张图片所示，条件只能是日期嘛？ 并且手动输入的无效，必须通过控件输入 gaolv123...@163.com
Re: Issues in building cubes of Apache Kylin
Hi Tarun, what's the output of bin/find-hive-dependency.sh? It seems something wrong in the environment variables. Which Hadoop distribution were you using? 2016-12-07 23:04 GMT+08:00 Tarun Vashisth : > Hi, > > > > We are trying to build cubes for data and while doing so, we are getting > the following error during the step 3 of cube creating > > File does not exist: hdfs://localhost:54310/app/hadoop/tmp/mapred/staging/ > hduser341814501/.staging/job_local341814501_0007/libjars/ > hive-exec-2.1.0.jar > > > Earlier, it was trying to find the jars at > hdfs://localhost:54310/usr/local/hive/lib. > We manually put all the jars of hive there and after that, it started > failing at this step. > > * Is kylin trying to create this directory hduser../ and so on and > unable to do so? Is it failing at that step? > > Hadoop Version: - 2.7.3 > Hive Version: - 2.1.0 > Hbase Version: - 1.2.4 > Kylin Version: - 1.6 > > Any help would be much appreciated in this regard. > > > Regards, > > Tarun >
Issues in building cubes of Apache Kylin
Hi, We are trying to build cubes for data and while doing so, we are getting the following error during the step 3 of cube creating File does not exist: hdfs://localhost:54310/app/hadoop/tmp/mapred/staging/hduser341814501/.staging/job_local341814501_0007/libjars/hive-exec-2.1.0.jar Earlier, it was trying to find the jars at hdfs://localhost:54310/usr/local/hive/lib. We manually put all the jars of hive there and after that, it started failing at this step. * Is kylin trying to create this directory hduser../ and so on and unable to do so? Is it failing at that step? Hadoop Version: - 2.7.3 Hive Version: - 2.1.0 Hbase Version: - 1.2.4 Kylin Version: - 1.6 Any help would be much appreciated in this regard. Regards, Tarun
Re: Cube Configuration Overwrites doesn't work
Hi Peter, Which version were you using? This override feature is introduced by KYLIN-2095, which is released in Kylin 1.6.0. 2016-12-07 19:47 GMT+08:00 Jian Zhong : > Forward to dev list. > > -- Forwarded message -- > From: peter zhang > Date: Wed, Dec 7, 2016 at 9:03 AM > Subject: Re: Cube Configuration Overwrites doesn't work > To: u...@kylin.apache.org > > > In case of inline snapshots break, add attchment > > 2016-12-07 9:00 GMT+08:00 peter zhang : > >> Hi, Dear Kylin User/Developer, >> >> I am a newer of Kylin. >> >> I created a cube in kylin and referring your user manual add two hive >> related tunning parameters as below: >> >> >> >> >> I excepted this parameter add before create flat hive table of first cube >> building step, but I can’t find these two configurations in the log. Is >> there anything wrong of my operation our understanding. >> >> Looking forwarding for reply. >> >> >> >> >> >> Thanks >> > > >
Fwd: Cube Configuration Overwrites doesn't work
Forward to dev list. -- Forwarded message -- From: peter zhang Date: Wed, Dec 7, 2016 at 9:03 AM Subject: Re: Cube Configuration Overwrites doesn't work To: u...@kylin.apache.org In case of inline snapshots break, add attchment 2016-12-07 9:00 GMT+08:00 peter zhang : > Hi, Dear Kylin User/Developer, > > I am a newer of Kylin. > > I created a cube in kylin and referring your user manual add two hive > related tunning parameters as below: > > > > > I excepted this parameter add before create flat hive table of first cube > building step, but I can’t find these two configurations in the log. Is > there anything wrong of my operation our understanding. > > Looking forwarding for reply. > > > > > > Thanks >
[jira] [Created] (KYLIN-2254) A kind of sub-query does not work
liyang created KYLIN-2254: - Summary: A kind of sub-query does not work Key: KYLIN-2254 URL: https://issues.apache.org/jira/browse/KYLIN-2254 Project: Kylin Issue Type: Bug Reporter: liyang For example below query does not work. SELECT f.lstg_format_name ,sum(price) as sum_price FROM test_kylin_fact f inner join ( select lstg_format_name, min(slr_segment_cd) as min_seg from test_kylin_fact group by lstg_format_name ) t on f.lstg_format_name = t.lstg_format_name where f.slr_segment_cd = min_seg group by f.lstg_format_name -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KYLIN-2253) sql union did not remove replicated records (distinct)
zhou degao created KYLIN-2253: - Summary: sql union did not remove replicated records (distinct) Key: KYLIN-2253 URL: https://issues.apache.org/jira/browse/KYLIN-2253 Project: Kylin Issue Type: Bug Components: Driver - JDBC Affects Versions: v1.5.4.1 Environment: apache-kylin-1.6.0-hbase1.x-bin.tar.gz Reporter: zhou degao Priority: Critical sql like following: select "LOOKUP_TIME_BY_DAY"."THE_YEAR" as "c0", "LOOKUP_TIME_BY_DAY"."MONTH_OF_YEAR" as "c1" from "VCGBI_FACT_SALE" as "VCGBI_FACT_SALE" join "LOOKUP_TIME_BY_DAY" as "LOOKUP_TIME_BY_DAY" on "VCGBI_FACT_SALE"."DEAL_TIME" = "LOOKUP_TIME_BY_DAY"."THE_DATE" group by "LOOKUP_TIME_BY_DAY"."THE_YEAR", "LOOKUP_TIME_BY_DAY"."MONTH_OF_YEAR" union select "LOOKUP_TIME_BY_DAY"."THE_YEAR" as "c0", "LOOKUP_TIME_BY_DAY"."MONTH_OF_YEAR" as "c1" from "VCGBI_FACT_PERSON_MISC_DATA" as "VCGBI_FACT_PERSON_MISC_DATA" join "LOOKUP_TIME_BY_DAY" as "LOOKUP_TIME_BY_DAY" on "VCGBI_FACT_PERSON_MISC_DATA"."TIME" = "LOOKUP_TIME_BY_DAY"."THE_DATE" group by "LOOKUP_TIME_BY_DAY"."THE_YEAR", "LOOKUP_TIME_BY_DAY"."MONTH_OF_YEAR" order by 1 ASC, 2 ASC I got result like following: 20161 20161 20162 20162 20163 20163 20164 20164 20165 20165 20166 20166 20167 20167 20168 20168 20169 20169 201610 201611 201612 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
