Mailing-List: contact dev-help@apex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.apache.org
Date: Sat, 22 Apr 2017 10:35:04 +0000 (UTC)
From: "Ananth (JIRA)" <jira@apache.org>
To: dev@apex.incubator.apache.org
Message-ID: <JIRA.13060938.1491084780000.25531.1492857304060@Atlassian.JIRA>
In-Reply-To: <JIRA.13060938.1491084780000@Atlassian.JIRA>
References: <JIRA.13060938.1491084780000@Atlassian.JIRA> <JIRA.13060938.1491084780104@jira-lw-us.apache.org>
Subject: [jira] [Updated] (APEXMALHAR-2472) Implement Kudu Input Operator
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 22 Apr 2017 10:35:13 -0000


     [ https://issues.apache.org/jira/browse/APEXMALHAR-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ananth updated APEXMALHAR-2472:
-------------------------------
    Issue Type: New Feature  (was: Bug)

> Implement Kudu Input Operator 
> ------------------------------
>
>                 Key: APEXMALHAR-2472
>                 URL: https://issues.apache.org/jira/browse/APEXMALHAR-2472
>             Project: Apache Apex Malhar
>          Issue Type: New Feature
>          Components: adapters database
>            Reporter: Ananth
>            Assignee: Ananth
>
> This operator would allow Kudu to be used as an Input store. This has multiple advantages like : 
> - Ability to solve the dedup problem from entire data set perspective. The dedupe operators we have today are primarily window based and this might not meet all of the use cases in real world. 
> - Ability to selectively stream data based on a SQL expression. Since Kudu is a structural store, we could effectively allow a SQL expression based "input" definition that would allow for selective streaming for all downstream operators. This could potentially be an alternative streaming store pattern as compared to Kafka as Kafka does not allow for selective streaming of tuples. 


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)