Apache HBase vs. Apache Spark vs. Presto

Hbase is well suited for large organizations with millions of operations performing on tables, real-time lookup of records in a table, range queries, random reads and writes and online analytics operations. Hbase cannot be replaced for traditional databases as it cannot support all the features, CPU and memory intensive. Observed increased latency when using with MapReduce job joins.

Incentivized

Well suited: To most of the local run of datasets and non-prod systems - scalability is not a problem at all. Including data from multiple types of data sources is an added advantage. MLlib is a decently nice built-in library that can be used for most of the ML tasks. Less appropriate: We had to work on a RecSys where the music dataset that we used was around 300+Gb in size. We faced memory-based issues. Few times we also got memory errors. Also the MLlib library does not have support for advanced analytics and deep-learning frameworks support. Understanding the internals of the working of Apache Spark for beginners is highly not possible.

Incentivized

Presto is for interactive simple queries, where Hive is for reliable processing. If you have a fact-dim join, presto is great..however for fact-fact joins presto is not the solution.. Presto is a great replacement for proprietary technology like Vertica

Incentivized

• Scalability. HBase can scale to trillions of records.
• Fast. HBase is extremely fast to scan values or retrieve individual records by key.
• HBase can be accessed by standard SQL via Apache Phoenix.
• Integrated. I can easily store and retrieve data from HBase using Apache Spark.
• It is easy to set up DR and backups.
• Ingest. It is easy to ingest data into HBase via shell, Java, Apache NiFi, Storm, Spark, Flink, Python and other means.

Incentivized

• Rich APIs for data transformation making for very each to transform and prepare data in a distributed environment without worrying about memory issues
• Faster in execution times compare to Hadoop and PIG Latin
• Easy SQL interface to the same data set for people who are comfortable to explore data in a declarative manner
• Interoperability between SQL and Scala / Python style of munging data

Incentivized

• Linking, embedding links and adding images is easy enough.
• Once you have become familiar with the interface, Presto becomes very quick & easy to use (but, you have to practice & repeat to know what you are doing - it is not as intuitive as one would hope).
• Organizing & design is fairly simple with click & drag parameters.

Incentivized

• There are very few commands in HBase.
• Stored procedures functionality is not available so it should be implemented.
• HBase is CPU and Memory intensive with large sequential input or output access while as Map Reduce jobs are primarily input or output bound with fixed memory. HBase integrated with Map-reduce jobs will result in random latencies.

Incentivized

• Memory management. Very weak on that.
• PySpark not as robust as scala with spark.
• spark master HA is needed. Not as HA as it should be.
• Locality should not be a necessity, but does help improvement. But would prefer no locality

Incentivized

• Presto was not designed for large fact fact joins. This is by design as presto does not leverage disk and used memory for processing which in turn makes it fast.. However, this is a tradeoff..in an ideal world, people would like to use one system for all their use cases, and presto should get exhaustive by solving this problem.
• Resource allocation is not similar to YARN and presto has a priority queue based query resource allocation..so a query that takes long takes longer...this might be alleviated by giving some more control back to the user to define priority/override.
• UDF Support is not available in presto. You will have to write your own functions..while this is good for performance, it comes at a huge overhead of building exclusively for presto and not being interoperable with other systems like Hive, SparkSQL etc.

Incentivized

There's really not anything else out there that I've seen comparable for my use cases. HBase has never proven me wrong. Some companies align their whole business on HBase and are moving all of their infrastructure from other database engines to HBase. It's also open source and has a very collaborative community.

Incentivized

Capacity of computing data in cluster and fast speed.

If the team looking to use Apache Spark is not used to debug and tweak settings for jobs to ensure maximum optimizations, it can be frustrating. However, the documentation and the support of the community on the internet can help resolve most issues. Moreover, it is highly configurable and it integrates with different tools (eg: it can be used by dbt core), which increase the scenarios where it can be used

Incentivized

1. It integrates very well with scala or python. 2. It's very easy to understand SQL interoperability. 3. Apache is way faster than the other competitive technologies. 4. The support from the Apache community is very huge for Spark. 5. Execution times are faster as compared to others. 6. There are a large number of forums available for Apache Spark. 7. The code availability for Apache Spark is simpler and easy to gain access to. 8. Many organizations use Apache Spark, so many solutions are available for existing applications.

Cassandra os great for writes. But with large datasets, depending, not as great as HBASE. Cassandra does support parquet now. HBase still performance issues. Cassandra has use cases of being used as time series. HBase, it fails miserably. GeoSpatial data, Hbase does work to an extent. HA between the two are almost the same.

Incentivized

Spark in comparison to similar technologies ends up being a one stop shop. You can achieve so much with this one framework instead of having to stitch and weave multiple technologies from the Hadoop stack, all while getting incredibility performance, minimal boilerplate, and getting the ability to write your application in the language of your choosing.

Incentivized

Presto is good for a templated design appeal. You cannot be too creative via this interface - but, the layout and options make the finalized visual product appealing to customers. The other design products I use are for different purposes and not really comparable to Presto.

Incentivized

• As Hbase is a noSql database, here we don't have transaction support and we cannot do many operations on the data.
• Not having the feature of primary or a composite primary key is an issue as the architecture to be defined cannot be the same legacy type. Also the transaction concept is not applicable here.
• The way data is printed on console is not so user-friendly. So we had to use some abstraction over HBase (eg apache phoenix) which means there is one new component to handle.

Incentivized

• Business leaders are able to take data driven decisions
• Business users are able access to data in near real time now . Before using spark, they had to wait for at least 24 hours for data to be available
• Business is able come up with new product ideas

Incentivized

• Presto has helped scale Uber's interactive data needs. We have migrated a lot out of proprietary tech like Vertica.
• Presto has helped build data driven applications on its stack than maintain a separate online/offline stack.
• Presto has helped us build data exploration tools by leveraging it's power of interactive and is immensely valuable for data scientists.

Incentivized