H2O: fast statistical, machine learning and math runtime for big data
github.com
github.com
For good or for ill, many academic folks are technological curmudgeons.
Let me in fact make a much bolder but still true statement: very very few of the folks who are strong both algorithmically and mathematical are also adept at helping engineer transformatively better to use tools. Why? Because skill in any subset of the math, cs and engineering things nicely requires deliberate practice in that entire subset of skills. Deliberate practice of all three together in tandem does not happen in an academic environment, ever. (measure zero sized counter examples exist admittedly)
http://www.cliffc.org/blog/2012/05/
http://www.cliffc.org/blog/2012/06/21/progress-vacation/
___________
very readable code, also, no generics in the few files i looke at. And, like twitter, scalaz, akka etc they write their own Futures
https://github.com/0xdata/h2o/blob/8f6d81abeea8ef3221969d8aa...
Math has been packaged for way too long and modeling has been sampling driven. We envision a world where math is free and one does not have to choose between Big Data or Better Algorithms - get them both.
(answering some of the comments)
- One of our goals is to continue to be extensible and easy to use. H2O is extensible today via, JSON, R (& Python) or via simple java (see package hex) The core platform is very scalable and fast - Thanks again to an amazing team of devoted hackers.
- We are inspired by prior art and lessons from Mahout & efforts from RHIPE (Thanks, Saptarshi!) and think of ourselves as the next generation fulfilling the promise with a one simple stack for ML & Math on Bigdata that is open, useful and production grade (performance & testing)
- We also believe that great math systems can be built by great systems engineers surrounded by great math people and domain experts (Also, by starting with the end user experience especially one for Big Data Science.) Our team reflects some of that thinking. We welcome data analysts, scientists, math people, distributed systems engineers and domain experts to use, critique and extend our product.
- Data ingest into our system can be via SQL, NoSQL, HDFS and plain old filesystem. H2O ingests regular CSV, xls or hive delimiter files. Most all commands are JSON directives and can be easily programmed via Python, see our test bed in action here - http://test.0xdata.com
Above all, we are grateful for the attention by HN and would like to welcome and nurture a community of users, doers and data enthusiasts who can use, patch, add to the docs and give feedback through your data experiences.
A product is not complete without it's community. Come join us on the refreshing journey ahead!
the oxdata stuff seems to be more of "interact with a hadoop cluster via a restful api via R" kinda thing.
the 0xdata stuff seems to be less easily extensible because of that strong separation / siloing. (though it looks like they have some really smart interesting folks on board!)
[edit: I'm working on building some scalable extensible numerical / data analysis tools myself, and whenever I see that partitioning between the tools for extending vs the tools for using, it just screams "wrong" to me. That said, the more everyone else focuses on businesses where that partitioning is normal, the more left for me :) ]
Wakari is an infrastructure for doing repeatable, collaborative analytics with Python. Our existing tools include a simple browser-based environment for code editing, IPython notebook, and sharing of plots and workflows. Our goal is to support multiple applications on that infrastructure, and not necessarily all written by Continuum.
[1] https://github.com/0xdata/h2o/blob/master/py/h2o/h2o/cloud.p...
Also some "big guns" on that project.
Thanks.
My point is that this library provides the same features as Apache Mahout (that exists since quite a long time), so why duplicate the work and why not contribute to mahout ?
Duplicate features: - Hadoop support - RandomForest - Generalized Linear Modeling
The list of algorithm support my Mahout is way bigger than the one of 0xdata https://cwiki.apache.org/confluence/display/MAHOUT/Algorithm...
I would say the only interesting feature is the R support. So why not put R availability in Mahout ?
There is no explanations given although the existence of mahout is pretty obvious for anybody in the field. So without any proper argumentation, it seems that the authors voluntarily ignore the major concurrent tool in their fields.