Tales at Scale Podcast Kicks off with the Apache Druid Origin Story

To quote the mid-2000s classic Zoolander: Real time analytics…so hot right now. OK, maybe that wasn’t the line but that’s where we find ourselves today. Traditional business intelligence cannot deliver all the insights companies need. From this shift, a new use case has emerged: analytics applications. These allow companies to harness the power of data, often in real time, for everything from security improvements and new product efficiency to better customer experience. But who are the industry leaders and what tech solutions do they provide? What companies are tackling these data challenges head on? What’s the next big thing for real-time analytics? That’s what we’re exploring on Imply’s new podcast, Tales at Scale. 

Tales at Scale cracks open the world of analytics projects and shares stories from developers and engineers who are building analytics applications or working within the real-time data space. One of the key areas of focus for the show is Apache Druid.

We wanted to know why Druid was invented and what makes it unique, straight from one of its creators. To kick off the show, our first guest was none other than Eric “Cheddar” Tschetter, co-creator of Apache Druid and field CTO at Imply.

A new database emerges

As the story goes, back in 2011, a data team at a technology company had a problem. They needed to quickly aggregate and query real-time data coming from website users across the Internet to analyze digital ad auctions. They tried a few existing solutions, but none of the relational and NoSQL options at the time were able to achieve scale and speed they needed. So they did something crazy. They built their own database. 

Eric Tschetter: “It all started at this little AdTech startup working, trying to provide effective visibility on the digital advertising market. We got auction data from a bunch of different marketplaces. And to give a little bit of context on this, all of those ads you see on the Internet, every time you go to a web page, there’s an auction where a bunch of people are fighting to be able to show you that ad. And these auctions, there’s billions upon billions of these happening on a daily basis. And it’s actually even worse than that because one auction will breed ten more auctions and it just expands massively.”

“So we were trying to bring visibility into that kind of marketplace. We partnered with some people who run these auctions. They gave us data and we were trying to then show them what’s happening in their market. We started out with a relational database and we were doing the normal kind of data warehousing things that you would do like summary tables, where you kind of pre aggregate a smaller set of dimensions, and it kind of worked. But the customer was always asking for more dimensions, more visibility. This was the 2010, 2011 time frame. And so back then there was Hadoop that was all the rage and there was this other thing called HBase that also people loved. And we were like ‘Oh, maybe we can use Hadoop and HBase to do this better.’ And so we started going down that path, wrote some MapReduce jobs, put some stuff in HBase, and did this whole precomputing thing where we basically pre computed the results so that we could show them super quick to the end user.”

At first, all of those solutions together worked better than a relational database. Eric continues, “We still had this problem with adding dimensions. The kicker for me was when one of the customers had nine dimensions they wanted to be able to view the data on and they asked for a few more. We weren’t going to say no. We were like ‘You should be able to have as many dimensions as you want.’ So we added them. But now the pre-computation job jumped from 4 hours on 15 machines to 9 hours on 25 machines. That math wasn’t very good. The amount of input data didn’t actually change. The only thing that changed was that we were looking at more things. So then from there we were like ‘Well, what can we do to allow for any dimensions to be added that the customer wants but still give them the experience that they want?’ That’s pretty much where it started.”

During all this, they started to wonder if it was possible to build something totally new. For those who have never tried before – building your own database is not an easy task. And at the time, there were good options out there- were they just not finding the right ones or the right combo of tech to get what they needed? Eric spoke with a former LinkedIn colleague about a search architecture he just open sourced that could maybe work. At the time, LinkedIn search fit all data into memory to work faster. But that approach wouldn’t work for aggregations, which is really what they needed. 

“At one point, I was just like, ‘Well, okay, let’s say I have a million numbers in an array in Java. If I just do a loop and add that million numbers, how long does that take?’ And I did that and it was so fast, it was sub-millisecond. I was like, “OK, so Hadoop takes minutes to add one million numbers, but if I have it as an array in Java, it’s sub millisecond. Great, there’s lots of room for optimization there. And so let’s do it.’”

This was Eric’s “aha moment.” Well, almost. 

“Even from the beginning, I always had this doubt about creating another database. We were creating a database – you’re not supposed to do that!  But when we were initially building it, we weren’t creating a generic database. We’re creating infrastructure that supported the transparency and visibility needs of our product. And so it was like we’re not building a database- it happens to look like a database, it happens to share a lot of concepts from a database. But it was infrastructure supporting a very specific product. The most common thing people say when they say, ‘Don’t make a database’ is  ‘Don’t reinvent the wheel.’ Then I’m sitting there like, there’s this company called Goodyear, and there’s this company called Bridgestone, and somehow they seem to be reinventing the wheel on a yearly or multi-year basis!”

Even though Druid came to be to solve one specific challenge around visibility, there were several other challenges that Druid ended up helping solve as new features were added.

“We really just went where the product took us. It started with this visibility: how much money is being generated from auctions? How many impressions are there? How many ads were shown? And then one of the things that people want to do is reach. If only one person sees the same ad ten times, 50 times, two times, one time, you only actually reached one person with that ad, not 50 people. And so they want to understand that. In database terms,this is called uniques. Uniques are kind of this really simple problem, but yet difficult to do at scale because they require memory and computation that scales with the number of uniques. And so the larger that number is, the more computing power you need. And it tends to kind of slow things down as you scale out. 

With digital advertising, there are billions of auctions happening every day. Dealing with these uniques led us to this idea of sketches. They were primarily used internally in databases or in network infrastructure, and they were used to try to make good enough approximations of results so that they could make decisions on it. And we were like, ‘Well, maybe we can use these and actually show the numbers to end users, because there are well defined error bounds. So we started using sketches and exposing those to end users.” 

Since then, sketches have become a well-adopted concept across databases. Both new databases as well as pre-existing ones have figured out how to add sketches and expose them to end users.”

A new database gets a name

With this project becoming a full fledged database, it needed a name. And what better way to describe it than tapping into an adjacent interest: gaming. 

It was the Druid class, with its shapeshifting abilities that first inspired Eric, along with Druid-the-database’s distributed system. Eric explains, “[Druid] follows something that at the time was called service-oriented architecture. Now, people have put the word ‘micro’ in front of service, and they relabeled the entirety of service-oriented architectures to micro services. But it follows a service oriented architecture, where each service does one thing good. And for anyone who’s a gamer, if you’re playing MOBAs or MMOs, you get together with other people and form a team. And in that team, there’s some people who take damage. There are some people who heal damage, there are some people who deal damage. And by coming together in that group, you can take on these really big monsters that no one person could take on on their own. And that was the idea of the service orientation of Druid.  

The Druid character is the one who can shapeshift between any of those roles. Each process kind of fits a role, forms a team, goes in and takes out the big bad monster.”

A new database goes open source

There are generally two choices when you’re building something new in the data infrastructure space: keep it proprietary or open source the technology. Some in the data space have declared that open source will be wholly replaced by fully-proprietary cloud offerings as the preferred solutions for most developers but that has yet to be seen. Open source gives projects continued innovation by allowing many different developers to work on a project together, bringing in different perspectives, which fosters community and can lead to a more robust project or product.

Some of Eric’s thoughts on open source were shaped during his days at LinkedIn, where a former boss once said “The product is not actually infrastructure, the product is something else.”

Eric continues, “He described one of the major motivations of open source as avoiding myopia in the local engineering team and getting access to more requirements from other places. And so for us, what that meant was opening up. Going open source meant other people came in, they tried the infrastructure, they tried it in their use case, and they inevitably ran into some problem somewhere. Then they’d come talk with us” After talking through the issue, the team would make the necessary changes. “Through enough of those conversations, you start realizing, oh, this thing we have, it kind of works for a lot of different things, and it’s kind of cool, and you just kind of eventually get there just from all of the different inputs.”

But even with input and help from a newly formed community, the creation of Apache Druid and getting it to where it is today was not without its challenges. 

“If I knew then what I know now, the biggest thing I would do differently? Well, when we were building the infrastructure to run our product, we were confronted with how it has to scale. It has to scale out of the box we’re running on AWS. So, nodes have to be able to die, and we have to be able to deal with that. It has to self heal. We were dealing with all of these operational concerns that you really care about when you’re operating a product. What I have learned is that not everybody actually deals with scale. Most use cases are actually not massive scale. They’re kind of minimal scale. There was a quote at one point, someone jokingly said that big data is any data that doesn’t fit in Excel. And that’s actually kind of true when you look at the broad set of use cases.”

It’s at this moment I start contemplating the name of the podcast but Eric continues…

“The thing that everyone deals with is understanding the value of something quickly. And so the initial intentions of building the infrastructure were entirely to make something that worked well for us in a massively scaled product. And that meant that it was a distributed system. It was a distributed system from the beginning. There were actual design choices made that said, no, the thing that’s deployed should just work and be production ready no matter what. And so we front loaded a lot of adoption friction in making people set up something that would be production ready to even just kick the tires. An open source project doesn’t gain adoption through making someone think about what it means to be production ready on the project before they even know what it does. An open source project is adopted through very quick kicking of the tires. Just download a thing. Someone wakes up on the weekend, they got 30 minutes, they want to download something, try something out, just see if it works for them.

And so if I could do one thing differently know, knowing that we were going open source with the project, I would have made those decisions differently and organized designed things a little bit more for a quick out of box, kicking the tires value proposition rather than basically putting a distributed system in front of people from the very beginning and requiring them to basically make something that will scale up infinitely from the very early stages.”

A new database in present day

Fast forward to today: Druid has been around for about ten years now. Thousands of companies are using it to build analytics applications. But what’s next for Druid? 

Eric explains: “There are a couple of things I find especially exciting. One of the things that I think has been great for the project overall is the adoption of SQL. Druid started in the NoSQL kind of world and the primary query language was these big JSON objects and all that. But I think it was less about not wanting to use SQL as a way to query things and more about other things that were bundled with SQL. Adopting and embracing SQL has been great. And I’m excited that we’ve redone our ingestion system to work with SQL. You write SQL to get data in, get it out. And there’s more coming along that path around embracing SQL and what it means for processing. I think it’ll be great for the adoption of the project and usability on top of that.”

There are a number of use cases popping up that Druid is uniquely suited for.  “In my role at Imply, I get to talk with customers a lot about what they’re trying to do, what’s not working, what is working, what they wish could be tweaked a little bit. And those conversations really get me excited for the degree of specialization that you can do inside of a domain. And so while we’re embracing the generic capabilities of SQL, there’s also some things that I think are uniquely capable inside of Druid to enable us to really specialize and work towards certain domains and certain problem domains and solve things in that regard. 

There are two general areas that I can talk about a little bit now and not be totally hand-wavy. One of them is in the networking / telecommunications space. I’ve had a number of communications with these people who are driving the adoption of this new data format called Yang. It’s an interesting format because it’s a data format that works both for control messages, meaning you can send messages to devices to ask them to change something about their configuration or take some action etc., but also a format for telemetry about what’s going on in the devices. And the conversations have made me realize that for them, control and telemetry, it’s kind of the same thing. There’s an event that causes an action to happen. That action that happened causes some other events to then happen, and you want some sort of tight control loop between them where there’s back and forth communication. But with this sort of control loop, you always need some way to observe what’s going on.

You need some visibility into what’s happening. At some point in time, a decision is going to be made and someone is going to be like, ‘Why did that happen? What happened here?’ And you’re going to need that visibility to look into things. Or also you need the ability to kind of step in and be like, ‘No, we need to take this action now’ and seeing that convergence in that space of the control with the telemetry. Working with the team, we can try to figure out what we can do to better visualize, what we can do to better pull that together, to make it just clear and readily apparent to the operators what’s going on and what the next actions are. That’s new and coming that I’m pretty excited about.” 

A new database in a crowded marketplace

At the time of this writing, there are over 300 databases on the market. More are being built to tackle the use cases of today and of the future. This includes the real-time analytics space that Druid is a part of. But Eric sees this as validating. 

“One way you can see it is just as a confirmation that what you’re building, maybe you’re not insane, maybe there is a need for it. But also, I guess if no one else tried to go after the same thing, that means that no one else sees the same problem, which in the grand scheme of things probably means the problem doesn’t actually exist. The fact that other people are also seeing the same problem and trying to chase after it means that it’s a legitimate thing. It kind of legitimizes things to a certain degree. And so I think it’s great from that aspect also. Just more people trying to go after the same thing. It results in a better outcome for everybody. And I don’t want to go all like Silicon Valley and we’re solving world peace through Uber for cats or something.”

Honestly, a ride share application for pets wouldn’t be the craziest idea. But Eric sees the growth of the data and analytics space as a good omen for future innovation. 

“Humanity is good at identifying something to make better and then making it better and then seeing where humanity has ended up… at the end, we’re trying to make things better for everybody, even with some small part. And so if you think about it in that macro sense, more people kind of going after the same general space, there’s a higher likelihood that we’re going to do good overall because something is going to come out of it that’s meaningful.”

So how does Druid stack up against all the other players in the data and analytics space? It’s no surprise that Eric considers Druid the top choice. 

“Of course, I think we’re the best. And like I was mentioning earlier, some things are unique to us and what we can do and how we can build in stuff that drives towards these use cases and drives towards optimization in specific uses. I think it’s really exciting to me. And looking back on it, the other thing that I personally want to make sure we never lose focus on is ‘what are people actually doing?’ because it’s really easy to go off and build something just generically. But when you’re focusing on what people are actually doing, you get to something that has a real nugget of value at its core. And I’m really excited about us doing that and kind of driving the industry forward.”

In the coming months, Tales at Scale will be taking on real-time data, Apache Druid use cases, integrations and ecosystem, and more. For more about what’s new and next make sure to like and subscribe:

Spotify: https://open.spotify.com/show/6KAKYLJvCVegsFfKvbfDnt?si=f58bd652ab2d47d2

Apple Podcasts: https://podcasts.apple.com/us/podcast/tales-at-scale/id1655951714