pinot VS dbt-core

Apache Pinot: Tailored for providing ultra-low latency analytics at scale. Apache Pinot is widely used for real-time analytical solutions where rapid data insights and decision-making are critical.

Online analytical processing (OLAP) databases like Apache Druid, Apache Pinot, and ClickHouse shine in addressing user-initiated analytical queries. You might write a query to analyze historical data to find the most-clicked products over the past month efficiently using OLAP databases. When contrasting with streaming databases, they may not be optimized for incremental computation, leading to challenges in maintaining the freshness of results. The query in the streaming database focuses on recent data, making it suitable for continuous monitoring. Using streaming databases, you can run queries like finding the top 10 sold products where the “top 10 product list” might change in real-time.

Consume data into third party software (then let Open Search or Apache Spark or Apache Pinot) for analysis/datascience, GIS systems (so you can put reports on a map) or any ticket management system

There is indeed Spark support for writing new data into Pinot (https://docs.pinot.apache.org/basics/data-import/batch-inges...) as well as to query it (https://github.com/apache/pinot/blob/master/pinot-connectors...).

This does not run inside the Pinot cluster - you can use standard Spark execution engine to run this ingestion. In addition, Pinot also supports an out of the box ingestion capability from batch sources using the Minion framework (https://docs.pinot.apache.org/basics/components/cluster/mini...) that does not need any external component (like Spark)

StarTree | Onsite | Mountain View CA, Bangalore India | Site Lead, SRE, Software Engineers (Backend, Data Infrastructure, Platform), Staff Security Engineer Compliance and Governance

You can find all the job postings here: https://startree.ai/careers

My name is Peter Corless and I am the Director of Product Marketing at StarTree (https://startree.ai/). We are a Mountain View, California based company and aer now opening an engineering operation in Bangalore, India.

We make StarTree Cloud, an Online Analytical Processing (OLAP) database-as-a-service (DBaaS) for real-time, user-facing analytics, powered by Apache Pinot.

Apache Pinot (https://pinot.apache.org/) is a top-level Apache Software Foundation (ASF) project that came out of LinkedIn. A lot of the PMCs for the Apache Pinot project work at StarTree. It is also used at Uber, Stripe, DoorDash, Just Eat Takeaway (GrubHub), and a lot of other organizations.

Apache Pinot is known for its ability to provide high concurrency — hundreds of thousands of QPS — against petabytes of data. It uses the star-tree index to provide really fast responses measured in milliseconds.

We're past 100 employees and looking for people who want to help grow us to the next orders of magnitude.

Let me know if you have questions or interest.

But then you realize there are other databases out there focused specifically on analytical use cases with lots of data and complex queries. Newcomers like ClickHouse, Pinot, and Druid (all open source) respond to a new class of problem: The need to develop applications using endpoints published on analytical queries that were previously confined only to the data warehouse and BI tools.

Recently, we have been surveying some streaming database solutions and the primary target is Apache Pinot, which fits our needs from the description and is therefore the primary target.

There are many mainstream streaming databases, and Apache Pinot is the most popular one recently.

Apache Pinot

dbt integration was one of our major goals early on but we found that the interaction wasn't as straightforward as had hoped.

There is an open PR in the dbt repo: https://github.com/dbt-labs/dbt-core/pull/5982#issuecomment-...

I have some ideas about future directions in this space where I believe PRQL could really shine. I will only be able to write those down in a couple of hours. I think this could be a really exciting direction for the project to grow into if anyone would like to collaborate and contribute!

> Could you share more specific details? Happy to look over / revise where needed.

Sure thing! I'd say first off, the solutions may look different for a small company/startup vs. a large enterprise. It can help if you explain the scale at which you are solving for.

On the enterprise side of things, they tend to buy solutions rather than build them in-house. Things like Informatica, Talend, etc. are common for large enterprises whose primary products are not data or software related. They just don't have the will, expertise, or the capital to invest in building and maintaining these solutions in-house so they just buy them off the shelf. On the surface, these are very expensive products, but even in the face of that it can still make sense for large enterprises in terms of the bottom line to buy rather than build.

For startups and smaller companies, have you looked at something like `dbt` (https://github.com/dbt-labs/dbt-core) ? I understand the desire to write some code, but often times there are already existing solutions for the problems you might be encountering.

ORM's should typically only exist on the consumer-side of the equation, if at all. A lot of business intelligence / business analysts are just going to use tools like Tableau and hook up to the data warehouse via a connector to visualize their data. You might have some consumers that are more sophisticated and may want to write some custom post-processing or aggregation code, and they could certainly use ORM's if they choose, but it isn't something you should enforce on them because it's a poor place to validate data since as mentioned there are different ways/tools to access the data and not all of them are going to go through your python SDK.

Indeed in a large enough company, you are going to have producers and consumers that are going to use different tools and programming languages, so it's a little bit presumptuous to write an SDK in python there.

Another thing to talk about, and this probably mostly applies to larger companies - have you looked at an architecture like a distributed data mesh (https://martinfowler.com/articles/data-mesh-principles.html)? This might be something to bring to the CTO more than try to push for yourself, but it can completely change the landscape of what you are doing.

> More broadly is the issue of the gap of what you think the role is, and what the role actually is when you join. There are definitely cases where this is accidental. The best way I can think of to close the gap is to maybe do a short-term contract, but may be challenging to do under time constraints etc.

Yeah this definitely sucks and it's not an enviable position to be in. I guess you have a choice to look for another job or try to stick it out with the company that did this to you. It's possible there is a geniune existential crisis for the company and a good reason why they did the bait-and-switch. Maybe it pays to stay, especially if you have equity in the company. On the other hand, it could also be the case that it is the result of questionable practices at the company. It's hard to make that call.

I really dislike SQL, but recognize its importance for many organizations. I also understand that SQL is definitely testable, particularly if managed by environments such as DBT (https://github.com/dbt-labs/dbt-core). Those who arrived here with preference to python will note that dbt is largely implemented in python, adds Jinja macros and iterative forms to SQL, and adds code testing capabilities.

3). Data Build Tool Repository.

dbt Cloud rightfully gets a lot of credit for creating dbt Core and for being the first managed dbt Core platform, but there are several entrants in the market; from those who just run dbt jobs like Fivetran to platforms that offer more like EL + T like Mozart Data and Datacoves which also has hosted VS Code editor for dbt development and Airflow.

Ahh I misunderstood, yes column level lineage is useful. DBT prefers leveraging macros which sort of breaks this pattern. I think the DBT way would be to better separate fields into upstream models and use table tracking https://github.com/dbt-labs/dbt-core/discussions/4458

Here’s the PR, which includes a what/how/why: https://github.com/dbt-labs/dbt-core/issues/7158

I've attached a link to their documentation. DBT is becoming increasingly popular within the Data Engineering community with over 5k stars on github.