SQL is very common and even some business analysts learn them. Scala and
Python are great, but the easiest language to use is often the languages a
user already knows. And for a lot of users, that is SQL.
On Wednesday, March 2, 2016, Jerry Lam wrote:
> Hi guys,
>
> FYI... this wiki page (StreamS
Hi guys,
FYI... this wiki page (StreamSQL: https://en.wikipedia.org/wiki/StreamSQL)
has some histories related Event Stream Processing and SQL.
Hi Steve,
It is difficult to ask your customers that they should learn a new language
when they are not programmers :)
I don't know where/why they learn
> On 1 Mar 2016, at 22:25, Jerry Lam wrote:
>
> Hi Reynold,
>
> You are right. It is about the audience. For instance, in many of my cases,
> the SQL style is very attractive if not mandatory for people with minimum
> programming knowledge.
but SQL skills instead. Which is just relational se
Hi Reynold,
You are right. It is about the audience. For instance, in many of my cases,
the SQL style is very attractive if not mandatory for people with minimum
programming knowledge. SQL has its place for communication. Last time I
show someone spark dataframe-style, they immediately said it is
There are definitely pros and cons for Scala vs SQL-style CEP. Scala might
be more powerful, but the target audience is very different.
How much usage is there for a CEP style SQL syntax in practice? I've never
seen it coming up so far.
On Tue, Mar 1, 2016 at 9:35 AM, Alex Kozlov wrote:
> Loo
Looked at the paper: while we can argue on the performance side, I think
semantically the Scala pattern matching is much more expressive. The time
will decide.
On Tue, Mar 1, 2016 at 9:07 AM, Jerry Lam wrote:
> Hi Alex,
>
> We went through this path already :) This is the reason we try other
>
Hi Alex,
We went through this path already :) This is the reason we try other
approaches. The recursion makes it very inefficient for some cases.
For details, this paper describes it very well:
https://people.cs.umass.edu/%7Eyanlei/publications/sase-sigmod08.pdf
which is the same paper references
For the purpose of full disclosure, I think Scala offers a much more
efficient pattern matching paradigm. Using nPath is like using assembler
to program distributed systems. Cannot tell much here today, but the
pattern would look like:
| def matchSessions(h: Seq[Session[PageView]], id:
Hi Henri,
Finally, there is a good reason for me to use Flink! Thanks for sharing
this information. This is exactly the solution I'm looking for especially
the ticket references a paper I was reading a week ago. It would be nice if
Flink adds support SQL because this makes business analyst (trader
fwiw Apache Flink just added CEP. Queries are constructed programmatically
rather than in SQL, but the underlying functionality is similar.
https://issues.apache.org/jira/browse/FLINK-3215
On 1 March 2016 at 08:19, Jerry Lam wrote:
> Hi Herman,
>
> Thank you for your reply!
> This functionality
Hi Herman,
Thank you for your reply!
This functionality usually finds its place in financial services which use
CEP (complex event processing) for correlation and pattern matching. Many
commercial products have this including Oracle and Teradata Aster Data MR
Analytics. I do agree the syntax a bit
Hi Jerry,
This is not on any roadmap. I (shortly) browsed through this; and this
looks like some sort of a window function with very awkward syntax. I think
spark provided better constructs for this using dataframes/datasets/nested
data...
Feel free to submit a PR.
Kind regards,
Herman van Höve
Hi Spark developers,
Will you consider to add support for implementing "Pattern matching in
sequences of rows"? More specifically, I'm referring to this:
http://web.cs.ucla.edu/classes/fall15/cs240A/notes/temporal/row-pattern-recogniton-11.pdf
This is a very cool/useful feature to pattern matchin
13 matches
Mail list logo