Alternatives to Dremio logo

Alternatives to Dremio

Presto, Apache Drill, Denodo, AtScale, and Snowflake are the most popular alternatives and competitors to Dremio.
117
347
+ 1
8

What is Dremio and what are its top alternatives?

Dremio—the data lake engine, operationalizes your data lake storage and speeds your analytics processes with a high-performance and high-efficiency query engine while also democratizing data access for data scientists and analysts.
Dremio is a tool in the Big Data Tools category of a tech stack.
Dremio is an open source tool with GitHub stars and GitHub forks. Here’s a link to Dremio's open source repository on GitHub

Top Alternatives to Dremio

  • Presto
    Presto

    Distributed SQL Query Engine for Big Data

  • Apache Drill
    Apache Drill

    Apache Drill is a distributed MPP query layer that supports SQL and alternative query languages against NoSQL and Hadoop data storage systems. It was inspired in part by Google's Dremel. ...

  • Denodo
    Denodo

    It is the leader in data virtualization providing data access, data governance and data delivery capabilities across the broadest range of enterprise, cloud, big data, and unstructured data sources without moving the data from their original repositories. ...

  • AtScale
    AtScale

    Its Virtual Data Warehouse delivers performance, security and agility to exceed the demands of modern-day operational analytics. ...

  • Snowflake
    Snowflake

    Snowflake eliminates the administration and management demands of traditional data warehouses and big data platforms. Snowflake is a true data warehouse as a service running on Amazon Web Services (AWS)—no infrastructure to manage and no knobs to turn. ...

  • Segment
    Segment

    Segment is a single hub for customer data. Collect your data in one place, then send it to more than 100 third-party tools, internal systems, or Amazon Redshift with the flip of a switch. ...

  • Apache Spark
    Apache Spark

    Spark is a fast and general processing engine compatible with Hadoop data. It can run in Hadoop clusters through YARN or Spark's standalone mode, and it can process data in HDFS, HBase, Cassandra, Hive, and any Hadoop InputFormat. It is designed to perform both batch processing (similar to MapReduce) and new workloads like streaming, interactive queries, and machine learning. ...

  • Databricks
    Databricks

    Databricks Unified Analytics Platform, from the original creators of Apache Spark™, unifies data science and engineering across the Machine Learning lifecycle from data preparation to experimentation and deployment of ML applications. ...

Dremio alternatives & related posts

Presto logo

Presto

393
1K
66
Distributed SQL Query Engine for Big Data
393
1K
+ 1
66
PROS OF PRESTO
  • 18
    Works directly on files in s3 (no ETL)
  • 13
    Open-source
  • 12
    Join multiple databases
  • 10
    Scalable
  • 7
    Gets ready in minutes
  • 6
    MPP
CONS OF PRESTO
    Be the first to leave a con

    related Presto posts

    Ashish Singh
    Tech Lead, Big Data Platform at Pinterest · | 38 upvotes · 3M views

    To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

    Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

    We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

    Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

    Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

    #BigData #AWS #DataScience #DataEngineering

    See more
    Eric Colson
    Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 6.1M views

    The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

    Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

    At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

    For more info:

    #DataScience #DataStack #Data

    See more
    Apache Drill logo

    Apache Drill

    71
    170
    16
    Schema-Free SQL Query Engine for Hadoop and NoSQL
    71
    170
    + 1
    16
    PROS OF APACHE DRILL
    • 4
      NoSQL and Hadoop
    • 3
      Free
    • 3
      Lightning speed and simplicity in face of data jungle
    • 2
      Well documented for fast install
    • 1
      SQL interface to multiple datasources
    • 1
      Nested Data support
    • 1
      Read Structured and unstructured data
    • 1
      V1.10 released - https://drill.apache.org/
    CONS OF APACHE DRILL
      Be the first to leave a con

      related Apache Drill posts

      Denodo logo

      Denodo

      40
      120
      0
      Data virtualisation platform, allowing you to connect disparate data from any source
      40
      120
      + 1
      0
      PROS OF DENODO
        Be the first to leave a pro
        CONS OF DENODO
          Be the first to leave a con

          related Denodo posts

          Manish Bhoge
          Solution Architect at Oracle Financial Software Services · | 3 upvotes · 23.4K views
          Shared insights
          on
          DenodoDenodoPrestoPresto

          We are evaluating Presto against the Denodo to build the virtualization layer on top of the Cloudera Data warehouse. We have customer and transaction data in the Cloudera data warehouse, and we want to build the virtualization layer on top of the multiple datasets and Cloudera DW.

          See more
          AtScale logo

          AtScale

          25
          83
          0
          The virtual data warehouse for the modern enterprise
          25
          83
          + 1
          0
          PROS OF ATSCALE
            Be the first to leave a pro
            CONS OF ATSCALE
              Be the first to leave a con

              related AtScale posts

              Snowflake logo

              Snowflake

              1.1K
              1.2K
              27
              The data warehouse built for the cloud
              1.1K
              1.2K
              + 1
              27
              PROS OF SNOWFLAKE
              • 7
                Public and Private Data Sharing
              • 4
                Multicloud
              • 4
                Good Performance
              • 4
                User Friendly
              • 3
                Great Documentation
              • 2
                Serverless
              • 1
                Economical
              • 1
                Usage based billing
              • 1
                Innovative
              CONS OF SNOWFLAKE
                Be the first to leave a con

                related Snowflake posts

                I'm wondering if any Cloud Firestore users might be open to sharing some input and challenges encountered when trying to create a low-cost, low-latency data pipeline to their Analytics warehouse (e.g. Google BigQuery, Snowflake, etc...)

                I'm working with a platform by the name of Estuary.dev, an ETL/ELT and we are conducting some research on the pain points here to see if there are drawbacks of the Firestore->BQ extension and/or if users are seeking easy ways for getting nosql->fine-grained tabular data

                Please feel free to drop some knowledge/wish list stuff on me for a better pipeline here!

                See more
                Shared insights
                on
                Google BigQueryGoogle BigQuerySnowflakeSnowflake

                I use Google BigQuery because it makes is super easy to query and store data for analytics workloads. If you're using GCP, you're likely using BigQuery. However, running data viz tools directly connected to BigQuery will run pretty slow. They recently announced BI Engine which will hopefully compete well against big players like Snowflake when it comes to concurrency.

                What's nice too is that it has SQL-based ML tools, and it has great GIS support!

                See more
                Segment logo

                Segment

                3.1K
                932
                275
                A single hub to collect, translate and send your data with the flip of a switch.
                3.1K
                932
                + 1
                275
                PROS OF SEGMENT
                • 86
                  Easy to scale and maintain 3rd party services
                • 49
                  One API
                • 39
                  Simple
                • 25
                  Multiple integrations
                • 19
                  Cleanest API
                • 10
                  Easy
                • 9
                  Free
                • 8
                  Mixpanel Integration
                • 7
                  Segment SQL
                • 6
                  Flexible
                • 4
                  Google Analytics Integration
                • 2
                  Salesforce Integration
                • 2
                  SQL Access
                • 2
                  Clean Integration with Application
                • 1
                  Own all your tracking data
                • 1
                  Quick setup
                • 1
                  Clearbit integration
                • 1
                  Beautiful UI
                • 1
                  Integrates with Apptimize
                • 1
                  Escort
                • 1
                  Woopra Integration
                CONS OF SEGMENT
                • 2
                  Not clear which events/options are integration-specific
                • 1
                  Limitations with integration-specific configurations
                • 1
                  Client-side events are separated from server-side

                related Segment posts

                Julien DeFrance
                Principal Software Engineer at Tophatter · | 16 upvotes · 3.2M views

                Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

                I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

                For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

                Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

                Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

                Future improvements / technology decisions included:

                Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

                As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

                One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

                See more
                Robert Zuber

                Our primary source of monitoring and alerting is Datadog. We’ve got prebuilt dashboards for every scenario and integration with PagerDuty to manage routing any alerts. We’ve definitely scaled past the point where managing dashboards is easy, but we haven’t had time to invest in using features like Anomaly Detection. We’ve started using Honeycomb for some targeted debugging of complex production issues and we are liking what we’ve seen. We capture any unhandled exceptions with Rollbar and, if we realize one will keep happening, we quickly convert the metrics to point back to Datadog, to keep Rollbar as clean as possible.

                We use Segment to consolidate all of our trackers, the most important of which goes to Amplitude to analyze user patterns. However, if we need a more consolidated view, we push all of our data to our own data warehouse running PostgreSQL; this is available for analytics and dashboard creation through Looker.

                See more
                Apache Spark logo

                Apache Spark

                2.9K
                3.5K
                140
                Fast and general engine for large-scale data processing
                2.9K
                3.5K
                + 1
                140
                PROS OF APACHE SPARK
                • 61
                  Open-source
                • 48
                  Fast and Flexible
                • 8
                  One platform for every big data problem
                • 8
                  Great for distributed SQL like applications
                • 6
                  Easy to install and to use
                • 3
                  Works well for most Datascience usecases
                • 2
                  Interactive Query
                • 2
                  Machine learning libratimery, Streaming in real
                • 2
                  In memory Computation
                CONS OF APACHE SPARK
                • 4
                  Speed

                related Apache Spark posts

                Conor Myhrvold
                Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 11.2M views

                How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

                Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

                Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

                https://eng.uber.com/distributed-tracing/

                (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

                Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

                See more
                Eric Colson
                Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 6.1M views

                The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

                Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

                At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

                For more info:

                #DataScience #DataStack #Data

                See more
                Databricks logo

                Databricks

                484
                741
                8
                A unified analytics platform, powered by Apache Spark
                484
                741
                + 1
                8
                PROS OF DATABRICKS
                • 1
                  Best Performances on large datasets
                • 1
                  True lakehouse architecture
                • 1
                  Scalability
                • 1
                  Databricks doesn't get access to your data
                • 1
                  Usage Based Billing
                • 1
                  Security
                • 1
                  Data stays in your cloud account
                • 1
                  Multicloud
                CONS OF DATABRICKS
                  Be the first to leave a con

                  related Databricks posts

                  Jan Vlnas
                  Developer Advocate at Superface · | 5 upvotes · 432.8K views

                  From my point of view, both OpenRefine and Apache Hive serve completely different purposes. OpenRefine is intended for interactive cleaning of messy data locally. You could work with their libraries to use some of OpenRefine features as part of your data pipeline (there are pointers in FAQ), but OpenRefine in general is intended for a single-user local operation.

                  I can't recommend a particular alternative without better understanding of your use case. But if you are looking for an interactive tool to work with big data at scale, take a look at notebook environments like Jupyter, Databricks, or Deepnote. If you are building a data processing pipeline, consider also Apache Spark.

                  Edit: Fixed references from Hadoop to Hive, which is actually closer to Spark.

                  See more
                  Vamshi Krishna
                  Data Engineer at Tata Consultancy Services · | 4 upvotes · 249.8K views

                  I have to collect different data from multiple sources and store them in a single cloud location. Then perform cleaning and transforming using PySpark, and push the end results to other applications like reporting tools, etc. What would be the best solution? I can only think of Azure Data Factory + Databricks. Are there any alternatives to #AWS services + Databricks?

                  See more