[jira] [Resolved] (KYLIN-1961) Project name is always constant instead of real project name in email notification
[ https://issues.apache.org/jira/browse/KYLIN-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Li resolved KYLIN-1961. Resolution: Fixed Fix Version/s: v1.5.4 > Project name is always constant instead of real project name in email > notification > -- > > Key: KYLIN-1961 > URL: https://issues.apache.org/jira/browse/KYLIN-1961 > Project: Kylin > Issue Type: Bug >Affects Versions: v1.5.3 >Reporter: Dong Li >Assignee: Dong Li > Fix For: v1.5.4 > > > Build Result of Job kylin_sales_cube - 20160930235500_20161006105000 - BUILD > - PDT 2016-08-17 05:56:41 > Build Result: SUCCEED > Job Engine: sandbox.hortonworks.com > Env: envName > Project: projectName > Cube Name: kylin_sales_cube > Source Records Count: 0 > Start Time: Wed Aug 17 05:57:17 PDT 2016 > Duration: 5mins > MR Waiting: 1mins > Last Update Time: Wed Aug 17 06:02:19 PDT 2016 > Submitter: ADMIN > Error Log: job has succeeded -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KYLIN-1961) Project name is always constant instead of real project name in email notification
[ https://issues.apache.org/jira/browse/KYLIN-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Li updated KYLIN-1961: --- Description: Build Result of Job kylin_sales_cube - 20160930235500_20161006105000 - BUILD - PDT 2016-08-17 05:56:41 Build Result: SUCCEED Job Engine: sandbox.hortonworks.com Env: envName Project: projectName Cube Name: kylin_sales_cube Source Records Count: 0 Start Time: Wed Aug 17 05:57:17 PDT 2016 Duration: 5mins MR Waiting: 1mins Last Update Time: Wed Aug 17 06:02:19 PDT 2016 Submitter: ADMIN Error Log: job has succeeded was:Project name is always constant 'projectName' in email notification, so is deployEnv. > Project name is always constant instead of real project name in email > notification > -- > > Key: KYLIN-1961 > URL: https://issues.apache.org/jira/browse/KYLIN-1961 > Project: Kylin > Issue Type: Bug >Affects Versions: v1.5.3 >Reporter: Dong Li >Assignee: Dong Li > > Build Result of Job kylin_sales_cube - 20160930235500_20161006105000 - BUILD > - PDT 2016-08-17 05:56:41 > Build Result: SUCCEED > Job Engine: sandbox.hortonworks.com > Env: envName > Project: projectName > Cube Name: kylin_sales_cube > Source Records Count: 0 > Start Time: Wed Aug 17 05:57:17 PDT 2016 > Duration: 5mins > MR Waiting: 1mins > Last Update Time: Wed Aug 17 06:02:19 PDT 2016 > Submitter: ADMIN > Error Log: job has succeeded -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KYLIN-1612) Cube is ready but insight tables not result
[ https://issues.apache.org/jira/browse/KYLIN-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423624#comment-15423624 ] liyang commented on KYLIN-1612: --- pls git log | grep > Cube is ready but insight tables not result > --- > > Key: KYLIN-1612 > URL: https://issues.apache.org/jira/browse/KYLIN-1612 > Project: Kylin > Issue Type: Bug >Reporter: hongbin ma >Assignee: liyang > Fix For: v1.5.2 > > > As reported by Roy ( aqinnxuk...@163.com) > Hi All, > i use kylin v1.5.1. add Cube and bulid successful.Cube status is Ready. but > in Insight tabs, tables display no result. > has anyone encountered a similar situation, how to resovle it? > Best Regards > Roy He -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KYLIN-1944) UTF 8
[ https://issues.apache.org/jira/browse/KYLIN-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liyang resolved KYLIN-1944. --- Resolution: Invalid Not about Kylin. > UTF 8 > -- > > Key: KYLIN-1944 > URL: https://issues.apache.org/jira/browse/KYLIN-1944 > Project: Kylin > Issue Type: Bug > Components: Tools, Build and Test >Reporter: nandan priyadarshi >Assignee: Zhong,Jason > Original Estimate: 34h > Remaining Estimate: 34h > > I am using Datastax Cassandra 4.8 version. Using Solr for Search activity. In > my table , I have Chinese character as well as English character. Table > retrieval is working smooth ,but some time I am not able to retrive all > records for particular filter. > For example :- > select * from yf_product_books where solr_query = 'author:杰奎琳'; > gives me 1 record . > but > select * from yf_product_books where solr_query = 'author:杰奎*'; > or > select * from yf_product_books where solr_query = 'author:*奎*'; > I am not getting zero rows. > Please suggest me where I am doing wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KYLIN-1834) java.lang.IllegalArgumentException: Value not exists! - in Step 4 - Build Dimension Dictionary
[
https://issues.apache.org/jira/browse/KYLIN-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423571#comment-15423571
]
liyang commented on KYLIN-1834:
---
KYLIN-1948 is not related, it is not about dictionary.
> java.lang.IllegalArgumentException: Value not exists! - in Step 4 - Build
> Dimension Dictionary
> --
>
> Key: KYLIN-1834
> URL: https://issues.apache.org/jira/browse/KYLIN-1834
> Project: Kylin
> Issue Type: Bug
>Affects Versions: v1.5.2, v1.5.2.1
>Reporter: Richard Calaba
>Priority: Blocker
> Attachments: job_2016_06_28_09_59_12-value-not-found.zip
>
>
> Getting exception in Step 4 - Build Dimension Dictionary:
> java.lang.IllegalArgumentException: Value not exists!
> at
> org.apache.kylin.dimension.Dictionary.getIdFromValueBytes(Dictionary.java:160)
> at
> org.apache.kylin.dict.TrieDictionary.getIdFromValueImpl(TrieDictionary.java:158)
> at
> org.apache.kylin.dimension.Dictionary.getIdFromValue(Dictionary.java:96)
> at
> org.apache.kylin.dimension.Dictionary.getIdFromValue(Dictionary.java:76)
> at
> org.apache.kylin.dict.lookup.SnapshotTable.takeSnapshot(SnapshotTable.java:96)
> at
> org.apache.kylin.dict.lookup.SnapshotManager.buildSnapshot(SnapshotManager.java:106)
> at
> org.apache.kylin.cube.CubeManager.buildSnapshotTable(CubeManager.java:215)
> at
> org.apache.kylin.cube.cli.DictionaryGeneratorCLI.processSegment(DictionaryGeneratorCLI.java:59)
> at
> org.apache.kylin.cube.cli.DictionaryGeneratorCLI.processSegment(DictionaryGeneratorCLI.java:42)
> at
> org.apache.kylin.engine.mr.steps.CreateDictionaryJob.run(CreateDictionaryJob.java:56)
> 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:60)
> at
> org.apache.kylin.job.execution.AbstractExecutable.execute(AbstractExecutable.java:114)
> at
> org.apache.kylin.job.execution.DefaultChainedExecutable.doWork(DefaultChainedExecutable.java:50)
> at
> org.apache.kylin.job.execution.AbstractExecutable.execute(AbstractExecutable.java:114)
> at
> org.apache.kylin.job.impl.threadpool.DefaultScheduler$JobRunner.run(DefaultScheduler.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> result code:2
> The code which generates the exception is:
> org.apache.kylin.dimension.Dictionary.java:
> /**
> * A lower level API, return ID integer from raw value bytes. In case of
> not found
> *
> * - if roundingFlag=0, throw IllegalArgumentException;
> * - if roundingFlag<0, the closest smaller ID integer if exist;
> * - if roundingFlag>0, the closest bigger ID integer if exist.
> *
> * Bypassing the cache layer, this could be significantly slower than
> getIdFromValue(T value).
> *
> * @throws IllegalArgumentException
> * if value is not found in dictionary and rounding is off;
> * or if rounding cannot find a smaller or bigger ID
> */
> final public int getIdFromValueBytes(byte[] value, int offset, int len,
> int roundingFlag) throws IllegalArgumentException {
> if (isNullByteForm(value, offset, len))
> return nullId();
> else {
> int id = getIdFromValueBytesImpl(value, offset, len,
> roundingFlag);
> if (id < 0)
> throw new IllegalArgumentException("Value not exists!");
> return id;
> }
> }
> ==
> The Cube is big - fact 110 mio rows, the largest dimension (customer) has 10
> mio rows. I have increased the JVM -Xmx to 16gb and set the
> kylin.table.snapshot.max_mb=2048 in kylin.properties to make sure the Cube
> build doesn't fail (previously we were getting exception complaining about
> the 300MB limit for Dimension dictionary size (req. approx 700MB)).
> ==
> Before that we were getting exception complaining about the Dictionary
> encoding problem - "Too high cardinality is not suitable for dictionary --
> cardinality: 10873977" - this we resolved by changing the affected
> dimension/row key Encoding from "dict" to "int; length=8" on the Advanced
> Settings of the Cube.
> ==
> We have 2 high-cardinality fields (one from fact table and one from the big
> dimension (customer - see
[jira] [Updated] (KYLIN-1849) add basic search capability at model UI
[ https://issues.apache.org/jira/browse/KYLIN-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kangkaisen updated KYLIN-1849: -- Attachment: KYLIN-1849.patch This patch supports to search cube by name in web. > add basic search capability at model UI > --- > > Key: KYLIN-1849 > URL: https://issues.apache.org/jira/browse/KYLIN-1849 > Project: Kylin > Issue Type: New Feature > Components: Web >Affects Versions: v1.5.2 >Reporter: Dayue Gao >Assignee: kangkaisen > Attachments: KYLIN-1849.patch > > > In order to work with dozens of cubes, could we add a search box at "Model" > page? Just like the one at "Monitor" page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KYLIN-1849) add basic search capability at model UI
[ https://issues.apache.org/jira/browse/KYLIN-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kangkaisen reassigned KYLIN-1849: - Assignee: kangkaisen (was: Zhong,Jason) > add basic search capability at model UI > --- > > Key: KYLIN-1849 > URL: https://issues.apache.org/jira/browse/KYLIN-1849 > Project: Kylin > Issue Type: New Feature > Components: Web >Affects Versions: v1.5.2 >Reporter: Dayue Gao >Assignee: kangkaisen > > In order to work with dozens of cubes, could we add a search box at "Model" > page? Just like the one at "Monitor" page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KYLIN-1960) Provide a new build type called COVER
[
https://issues.apache.org/jira/browse/KYLIN-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422471#comment-15422471
]
Zhong Yanghong commented on KYLIN-1960:
---
[~Shaofengshi] and [~liyang.g...@gmail.com], could you help review this patch?
Thanks.
> Provide a new build type called COVER
> -
>
> Key: KYLIN-1960
> URL: https://issues.apache.org/jira/browse/KYLIN-1960
> Project: Kylin
> Issue Type: New Feature
>Reporter: Zhong Yanghong
>Assignee: Zhong Yanghong
> Attachments: provide_a_new_build_type_COVER.patch
>
>
> The current three build types are not good at dealing with incremental
> building with refreshing old data.
> For example, there are [S1, S2, S3] segments in a cube. S1 with time range
> [t1, t2); S2 with time range [t2, t3); S3 with time range [t3, t4).
> Now users want to refresh the old data within [t2, t4). The current strategy
> is to merge S2 and S3 firstly. Then refresh the bigger segment with time
> range [t2, t4). The first step is meaningless and wasteful.
> What if users want to build a new segment with time range [t2, t5), where t5
> is larger than t4. The current strategy is clumsy.
> How about providing a new build type? Here, it's called COVER. For this type,
> users also should provide start time and end time as parameters. The start
> time should match the boundaries of segments. In this case, it should be in
> set {t1, t2, t3, t4}. While the end time should be larger than t4, or match
> one of the end times of existing segments. In this case, it should be in set
> {t2, t3, t4}. Of course, the end time should be larger than the start time.
> What job engine will do with this build type is as follows:
> 1. first build a new segment with the time range;
> 2. then the covered segments will be deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KYLIN-1960) Provide a new build type called COVER
[
https://issues.apache.org/jira/browse/KYLIN-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhong Yanghong updated KYLIN-1960:
--
Attachment: (was: provide_a_new_build_type_COVER.patch)
> Provide a new build type called COVER
> -
>
> Key: KYLIN-1960
> URL: https://issues.apache.org/jira/browse/KYLIN-1960
> Project: Kylin
> Issue Type: New Feature
>Reporter: Zhong Yanghong
>Assignee: Zhong Yanghong
> Attachments: provide_a_new_build_type_COVER.patch
>
>
> The current three build types are not good at dealing with incremental
> building with refreshing old data.
> For example, there are [S1, S2, S3] segments in a cube. S1 with time range
> [t1, t2); S2 with time range [t2, t3); S3 with time range [t3, t4).
> Now users want to refresh the old data within [t2, t4). The current strategy
> is to merge S2 and S3 firstly. Then refresh the bigger segment with time
> range [t2, t4). The first step is meaningless and wasteful.
> What if users want to build a new segment with time range [t2, t5), where t5
> is larger than t4. The current strategy is clumsy.
> How about providing a new build type? Here, it's called COVER. For this type,
> users also should provide start time and end time as parameters. The start
> time should match the boundaries of segments. In this case, it should be in
> set {t1, t2, t3, t4}. While the end time should be larger than t4, or match
> one of the end times of existing segments. In this case, it should be in set
> {t2, t3, t4}. Of course, the end time should be larger than the start time.
> What job engine will do with this build type is as follows:
> 1. first build a new segment with the time range;
> 2. then the covered segments will be deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KYLIN-1960) Provide a new build type called COVER
[
https://issues.apache.org/jira/browse/KYLIN-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhong Yanghong updated KYLIN-1960:
--
Attachment: provide_a_new_build_type_COVER.patch
> Provide a new build type called COVER
> -
>
> Key: KYLIN-1960
> URL: https://issues.apache.org/jira/browse/KYLIN-1960
> Project: Kylin
> Issue Type: New Feature
>Reporter: Zhong Yanghong
>Assignee: Zhong Yanghong
> Attachments: provide_a_new_build_type_COVER.patch
>
>
> The current three build types are not good at dealing with incremental
> building with refreshing old data.
> For example, there are [S1, S2, S3] segments in a cube. S1 with time range
> [t1, t2); S2 with time range [t2, t3); S3 with time range [t3, t4).
> Now users want to refresh the old data within [t2, t4). The current strategy
> is to merge S2 and S3 firstly. Then refresh the bigger segment with time
> range [t2, t4). The first step is meaningless and wasteful.
> What if users want to build a new segment with time range [t2, t5), where t5
> is larger than t4. The current strategy is clumsy.
> How about providing a new build type? Here, it's called COVER. For this type,
> users also should provide start time and end time as parameters. The start
> time should match the boundaries of segments. In this case, it should be in
> set {t1, t2, t3, t4}. While the end time should be larger than t4, or match
> one of the end times of existing segments. In this case, it should be in set
> {t2, t3, t4}. Of course, the end time should be larger than the start time.
> What job engine will do with this build type is as follows:
> 1. first build a new segment with the time range;
> 2. then the covered segments will be deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KYLIN-1960) Provide a new build type called COVER
[
https://issues.apache.org/jira/browse/KYLIN-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhong Yanghong updated KYLIN-1960:
--
Attachment: provide_a_new_build_type_COVER.patch
> Provide a new build type called COVER
> -
>
> Key: KYLIN-1960
> URL: https://issues.apache.org/jira/browse/KYLIN-1960
> Project: Kylin
> Issue Type: New Feature
>Reporter: Zhong Yanghong
>Assignee: Zhong Yanghong
> Attachments: provide_a_new_build_type_COVER.patch
>
>
> The current three build types are not good at dealing with incremental
> building with refreshing old data.
> For example, there are [S1, S2, S3] segments in a cube. S1 with time range
> [t1, t2); S2 with time range [t2, t3); S3 with time range [t3, t4).
> Now users want to refresh the old data within [t2, t4). The current strategy
> is to merge S2 and S3 firstly. Then refresh the bigger segment with time
> range [t2, t4). The first step is meaningless and wasteful.
> What if users want to build a new segment with time range [t2, t5), where t5
> is larger than t4. The current strategy is clumsy.
> How about providing a new build type? Here, it's called COVER. For this type,
> users also should provide start time and end time as parameters. The start
> time should match the boundaries of segments. In this case, it should be in
> set {t1, t2, t3, t4}. While the end time should be larger than t4, or match
> one of the end times of existing segments. In this case, it should be in set
> {t2, t3, t4}. Of course, the end time should be larger than the start time.
> What job engine will do with this build type is as follows:
> 1. first build a new segment with the time range;
> 2. then the covered segments will be deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KYLIN-1702) The Key of the Snapshot to the related lookup table may be not informative
[ https://issues.apache.org/jira/browse/KYLIN-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhong Yanghong updated KYLIN-1702: -- Attachment: (was: change_layout_path_of_table_snapshot_with_tableName.patch) > The Key of the Snapshot to the related lookup table may be not informative > -- > > Key: KYLIN-1702 > URL: https://issues.apache.org/jira/browse/KYLIN-1702 > Project: Kylin > Issue Type: Improvement >Reporter: Zhong Yanghong >Assignee: Zhong Yanghong > Attachments: change_layout_path_of_table_snapshot_with_tableName.patch > > > Currently the key for the snapshot stored in hbase metadata file is as > follows: > ResourceStore.SNAPSHOT_RESOURCE_ROOT + "/" + new > File(signature.getPath()).getName() + "/" + uuid + ".snapshot" > However, some hive tables stored in hive may organized like > dirName/tableName/00, dirName/tableName/01. > Based on current setting, the key will be > ResourceStore.SNAPSHOT_RESOURCE_ROOT + "/" + 00 + "/" + uuid + ".snapshot", > which is lack of the table name information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KYLIN-1702) The Key of the Snapshot to the related lookup table may be not informative
[ https://issues.apache.org/jira/browse/KYLIN-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhong Yanghong updated KYLIN-1702: -- Attachment: change_layout_path_of_table_snapshot_with_tableName.patch A small patch for changing the layout path of snapshot table is attached. [~Shaofengshi], could you help review this patch? Thanks. > The Key of the Snapshot to the related lookup table may be not informative > -- > > Key: KYLIN-1702 > URL: https://issues.apache.org/jira/browse/KYLIN-1702 > Project: Kylin > Issue Type: Improvement >Reporter: Zhong Yanghong >Assignee: Zhong Yanghong > Attachments: change_layout_path_of_table_snapshot_with_tableName.patch > > > Currently the key for the snapshot stored in hbase metadata file is as > follows: > ResourceStore.SNAPSHOT_RESOURCE_ROOT + "/" + new > File(signature.getPath()).getName() + "/" + uuid + ".snapshot" > However, some hive tables stored in hive may organized like > dirName/tableName/00, dirName/tableName/01. > Based on current setting, the key will be > ResourceStore.SNAPSHOT_RESOURCE_ROOT + "/" + 00 + "/" + uuid + ".snapshot", > which is lack of the table name information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
