I intended to finalize these requirements through discussion here and then convert to JIRA
On Wed, Nov 11, 2015 at 5:54 PM, Li Yang <[email protected]> wrote: > Should these be converted into some JIRA to ensure we don't forget. > > On Fri, Nov 6, 2015 at 2:15 PM, Luke Han <[email protected]> wrote: > > > #5 should keep same logical as today's cube's one, each cube/streaming > > could have it's own notification mail lists. > > > > > > > > > > Best Regards! > > --------------------- > > > > Luke Han > > > > On Fri, Nov 6, 2015 at 10:26 AM, hongbin ma <[email protected]> > wrote: > > > > > 5. For each streaming case maintains a receiver mail list (support > > multiple > > > receivers) for all notification emails(including gaps notification, > etc) > > > > > > On Thu, Nov 5, 2015 at 11:19 AM, Li Yang <[email protected]> wrote: > > > > > > > Very good inputs. > > > > > > > > On Wed, Nov 4, 2015 at 11:42 AM, hongbin ma <[email protected]> > > > wrote: > > > > > > > > > Since we're working on designing new cluster management for manage > LB > > > > > servers and streaming job slaves. > > > > > I think it's a good opportunity for kylin user to share their pain > > > points > > > > > and wish list help to improve kylin use experience. > > > > > > > > > > Here're mine: > > > > > > > > > > 1. Cluster configuration is troublesome. Currently we have to write > > > down > > > > > the server list in kylin.properties and assign a role to each > server. > > > > This > > > > > is hard to maintain. The new cluster management should automate > > server > > > > > discovery, leader selection and failover. > > > > > > > > > > 2. Log analyze is not easy if multiple servers are running at the > > same > > > > > time. (https://issues.apache.org/jira/browse/KYLIN-1124 for > > example). > > > > For > > > > > query side, we should be able to answer questions like "I > submitted a > > > > query > > > > > XXXXX at 10:00, please check why it's slow?", "what are the most > time > > > > > consuming queries recently (and its related cube name)?". For > > streaming > > > > job > > > > > dispatcher side, we should be able to identify failed batches more > > > > > quickly(and resume it), as well as a better management of each > > batch's > > > > > build log (when you have tens of slaves, it's difficult to find > where > > > is > > > > a > > > > > batch's build log is). A related JIRA ticket is > > > > > https://issues.apache.org/jira/browse/KYLIN-1079 > > > > > > > > > > 3. Streaming batch jobs should be horizontally scalable. If a batch > > is > > > > > found to be too big to fit into a single JVM, we should detect it > and > > > > > divide the batch into smaller pieces so that we can dispatch the > job > > to > > > > > multiple JVMs, and let subsequent auto-merge job to merge them. > > Related > > > > > JIRA is https://issues.apache.org/jira/browse/KYLIN-1042 > > > > > > > > > > 4. Auto-merge job fail will lead to accumulating hundreds of > > segments, > > > > this > > > > > will greatly harm query performance. related JIRA: > > > > > https://issues.apache.org/jira/browse/KYLIN-1038 > > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > > > > > > *Bin Mahone | 马洪宾* > > > > > Apache Kylin: http://kylin.io > > > > > Github: https://github.com/binmahone > > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > > > > *Bin Mahone | 马洪宾* > > > Apache Kylin: http://kylin.io > > > Github: https://github.com/binmahone > > > > > > -- Regards, *Bin Mahone | 马洪宾* Apache Kylin: http://kylin.io Github: https://github.com/binmahone
