Druid: fast column-oriented distributed data store | Hacker News Reader

Druid: fast column-oriented distributed data store

druid.io

131 pointssamueladam47 comments

Druid is quickly becoming the leading open source solution for building highly scalable analytics. We evaluated it for getstream.io. Unfortunately the setup and maintenance is still very labour intensive. For startups that's a concern. Many larger companies we spoke to were extremely happy about running Druid in production though.

Druid isn't even close to being the leading solution. The overwhelming majority of places doing big data analytics will be Hadoop/Spark using core HDFS.

Then most places will augment this with a range of database solutions depending on how structured/clean the data is and the various workloads. Cassandra, HBase, MongoDB, Teradata, Oracle, ElasticSearch, Greenplum are all pretty common place in most enterprises.

And of course the ridiculous array of SQL engines on top of HDFS/S3/whatever else e.g. Hive, Spark SQL, Presto, Drill, SAP etc.

Druid's main value add to the data infrastructure space is around power user-facing data applications at scale. The queries it is best at are OLAP/business intelligence style queries. It isn't really designed to be a general processing tool such as Hadoop or Spark. The open source data space is very complex, and there are many different solutions targeted towards many different use cases. Druid is better than other solutions at some of these use cases, and worse than other solutions at others.

I wrote my interpretation of the current open source data landscape here for anyone interested: http://imply.io/post/2015/11/04/big-data-zoo.html

As someone who hasn't yet had the opportunity to use many of these systems, this was a great high-level overview of how the various systems fit together. Thanks for writing it!

Your Wikipedia link to "stream processors" is for the wrong kind of stream processors. For a decades, the digital signal processing and graphics worlds have used the streaming abstraction to design programs and hardware. Their applications are typically expressed in pipelines, and do have to continually process data.

"Big data" stream processing is obviously related as its a dataflow programming model, but it's still very different in practice. The streaming abstraction is generally more free-form, and not realized directly in hardware. I contrast the two kinds of streaming in Section 2 of a paper from a few years ago: http://www.scott-a-s.com/files/pact2012.pdf

If one of these databases included a really good SparkSQL connector (including great predicate push-down), I could see that being hugely beneficial to growth. Part of why people are using these systems is because you can connect in many different types of data. Make your database part of that ecosystem and you can gradually take in more of the analytics workload without the users losing the ability to also throw in some plain old text files or something and join between multiple worlds.

Druid has a SparkSQL connector: https://github.com/SparklineData/spark-druid-olap

Cool! Yeah I poked around the druid site and didn't find anything originally, but this looks pretty promising. It's hard to tell how full-featured it is without getting hands-on, but I see something like this making Druid much more usable in a lot of analytics environments.

We have couple of companies running Tableau on top of this. The deployment is Tableau - Spark ThriftServer(with our extension) - Druid. We push down Slice and Dice and Star Join Queries as Druid Queries; all of Spark SQL is supported with some portions of a Query Plan being executed in Spark. We are working on supporting more Spark UDFs being pushed to Druid, performance improvements, and more coverage for Tableau. Further down we will support Star Schemas where some or all dimensions are not indexed. Happy to discuss specific SQL support or deployment questions. Please reach out to us.

- Harish.

Cassandra, MongoDB and ElasticSearch all have SparkSQL DataSource drivers with predicate pushdown support. Most of the limitations in that support is from the database itself and not from the driver.

The biggest problems with SparkSQL is simply in its limited support for ANSI SQL. It's getting better with every release but not nearly quick enough.

I don't know the specific state of the DataSources you mention, but yes just providing a DataSource only is not enough; you can only push Filters and Projections to the underlying engine. You need to develop Query Rewrite Rules to rewrite Joins, Group Bys, Having, Limit etc to the underlying engine. For example our Rewrite engine for Druid is here: https://github.com/SparklineData/spark-druid-olap/blob/maste...

Can you be specific about ANSI SQL compliance requirements. Spark SQL is closing the gap on Hive SQL; both have decent support for analytical queries: Cubes/Rollups/Windowing etc. The only major gap between Spark and Hive SQL I know off is SubQuery predicates(exists/not exists).

Second that experience:

When I was at Optimizely, my team chose Druid for a large-scale analytics application, after a pretty extensive benchmarking. It was very impressive, though not trivial to set up.

Blog post with a bit more detail: https://medium.com/engineers-optimizely/slicing-and-dicing-d...

Druid committer here. We spent a lot of time in the early days on making sure the system worked (at scale) and now we're spending more time to make it much easier to set up and manage.

It might be helpful perhaps to provide some kubernetes configuration set up (or like a presetup kubernetes running in vagrant) that has all the nodes correctly configured out of the box to easily get started with development and prototyping.

I'm a bit surprised about forking the druid chef cookbook. From the blog post:

> we were delighted to find an existing community cookbook, chef-druid, that can configure and deploy a druid cluster. However, that community cookbook hasn’t been updated for nearly a year and does not support the latest version of druid. We have therefore forked off our own version, optimizely/chef-druid, which supports the latest version of druid.

Why didn't you create a pull request to the upstream project? That way, all people who are using the original cookbook could have directly benefit from your improvements, without having to discover the new fork.

I wasn't involved in that specific implementation decision, so can't say.

Speculating personally, it was probably just something that happened for speed/ease - as opposed to trying to get an apparently abandoned repo rolling again.

We did make optimizely/chef-druid open and public though, and while I'm not with Optimizely any more, I'm sure the good folk there would be more than happy to merge back into the original repo if anyone was still maintaining it and wanted that to happen.

Much of the effort for the next release of Druid (0.9) has been put into docs. Even with that you still need to handle a complex cluster made of several services: zookeeper, druid overlord, druid middlemanager, druid broker, etc... still it sounds more complicate than it actually is. What was the alternative solution adopted by your company?

"becoming the leading open source solution" is something you can say that doesn't mean much and is difficult to prove or disprove. There are a number of entrenched players, open source and commercial that provide a column oriented database: http://www.timestored.com/time-series-data/column-oriented-d...

That's a short description of 12 alternatives I wrote up. Druid does look interesting, it appears to have got the architecture pretty spot on and I'm going to look into it more.

No it isn't

Elasticsearch and Redshift are.

Huh? GP will make an unsubstantiated claim and you'll double down with an unsubstantiated counter claim (in one line!)

Seriously: What, specifically, do you disagree with, in the context of your use case, and what is your use-case?

That doesn't make any sense at all.

The realtime ingestion is interesting especially if I can still batch import. When processing machine data, I've found that a quantity of sources come in chunks (logfiles written out every 24 hours for exmaple) but the eventual aim is to migrate to realtime (i.e.: a data point every n seconds/minutes/etc. where you instantly consume that data point) streaming.

If this transition is easy without reworking infrastructure, the solution is far more attractive.

Every open source column database I've seen is very poor: text, no decent array oriented ability (give me the prevoius row), slow, json output, etc. When will somebody get it right?

This is simply false. PostgreSQL + cstore_ftw, Presto, Impala, etc. all support "array oriented ability" via window functions.

I mean like give me the preceding row from the current. Very useful for calculating anything from a simple rate of change to a properly doing a temporal database. Arrays as a column type doesn't get you that.

No, but window functions do, unless I'm not understanding what your goal is.

http://www.postgresql.org/docs/current/static/functions-wind...

I actually was using that yesterday. So so so so very very very very slow.

Impala supports LAG and LEAD, etc.: http://www.cloudera.com/documentation/archive/impala/2-x/2-0...

So do most databased, but they are SLOOOOOOOW.

A friend of mine who interned with me at eBay used Druid and Angular to great success to build a tool for analysts to look at trends in our data. Druid is some seriously cool stuff.

Our 2-man team set up Druid........ i took 5+ months and was excruciating to configure and get running smoothly (things were slightly more complicated because we decided to use docker). It also took ~30 servers to make a truly fault-tolerant setup.

With that said, it works very well, but it definitely came at the cost of a good dose of sanity.

FWIW, Imply repackaged Druid in such a way that should make it much much easier to set up and evaluate. We've been porting our docs over to Druid for 0.9.0: http://imply.io/docs/latest/quickstart

There's also a production-ready docker distribution: https://hub.docker.com/r/imply/imply/

Has anyone done a meaningful private benchmark comparison with http://www.scylladb.com/ ? I didn't find one online.

It is a 100% different type of database. Druid is olap while scylladb is oltp. They have nothing in common (except for the "columnar" name)

Yes, but that doesn't mean you can't benchmark them anyway. And I think you could probably find some meaningful comparison. Certainly it would be more useful than the Druid whitepaper's benchmarks against MySQL. (I used to work on a DB project, we too had a benchmark against MySQL even though our DB was OLAP-focused.)

No they can't because scylladb can't do the stuff druid can (and vice-versa). While mysql can (even though it's a completely different way).

What's the advantage of a "column-oriented" data store/database?

Analytics like sum(column) are much faster if data is saved column-oriented. Also every time you don't do select *, but select a, b, it's much easier on disk because you're not even touching some columns.

Wikipedia is a good start: https://en.wikipedia.org/wiki/Column-oriented_DBMS The references section has good primary sources.

How does it compare to Vertica?

Great, just what we need, a Druish database.

Funny, it doesn't look druish...

It takes only what it needs to survive...

We're down voting Spaceballs references? Who are you monsters!?

people who come here for serious discussions. Reddit is more the place for memes, references and stuff like that, not HN

Yeah, more database solutions that's what we need.

https://xkcd.com/927/

It actually is needed. It's a great enterprise-level timeseries-centric database.

Reply on news.ycombinator.com