21–30 of 38 posts
This actually looks pretty useful. I'm adjacent to you (DL on hadoop/spark competing more with the just launched amazon sagemaker among other things) and was curious about your go to market strategy. Like us you're kind of strattling the line between the hadoop ecosystem and GPUs. Mesos does this as well. It seems like most folks in the GPU space still don't get Hadoop or S3 as a data source yet though (despite it be…
straddling
This actually looks pretty useful. I'm adjacent to you (DL on hadoop/spark competing more with the just launched amazon sagemaker among other things) and was curious about your go to market strategy. Like us you're kind of strattling the line between the hadoop ecosystem and GPUs. Mesos does this as well. It seems like most folks in the GPU space still don't get Hadoop or S3 as a data source yet though (despite it be…
People in the GPU space and slow storage systems like hadoop and S3) To caveat, I saw slow compared to something like storing your queryable data in system memory. The answer is that your clients are not normally GPU people. They are aware of GPUs and know they can be used for certain things but real clients normally have lots of data and they don't fire up a million instances to let it sit in a $10/GB storage soluti…
Re: Kinetica. They are doing visualization as well as things like machine learning.
I like your guys' approach a lot better. I see a clear bridge from the mass market commodity storage to something useful actually leveraging GPUs. That's why I commented. Best of luck to you!
I would love to see performance numbers for a GPU data warehouse on a benchmark like TPCDS. My concern is that GPUs are very fast for a few operations, but that these operations aren't the bottleneck for realistic queries, so the overall performance will not be good. I did a TPCDS-based benchmark on Redshift-vs-Snowflake-vs-BigQuery a few weeks ago [1], it could probably be run by BlazingDB without too much trouble s…
Great to see more competition in GPU+DW space! Some questions: 1. How does BlazingDB compare to MapD ? 2. How do you skip ingest - are you using Apache Arrow like Dremio as an efficient data representation format? 3. Do you have any benchmarks, or maybe where would you see BlazingDB on this list? http://tech.marksblogg.com/benchmarks.html using same hardware as MapD ? 4. Can you run your solution in a cluster? :)
1) We are focused on the data lake. We love MapD, they are doing kick ass stuff, we are focused more on operating on information from disk and from cloud storage services like s3 or hdfs implementations. 2) We read parquet files into our own caching system. We often use arrow apis though do not rely on arrow for our data representation. 3) We have made client side benchmarks but have not performed a standardized repl…
Earlier quoted context omitted.
1) We are focused on the data lake. We love MapD, they are doing kick ass stuff, we are focused more on operating on information from disk and from cloud storage services like s3 or hdfs implementations. 2) We read parquet files into our own caching system. We often use arrow apis though do not rely on arrow for our data representation. 3) We have made client side benchmarks but have not performed a standardized repl…
Could you elaborate on the GPU + data lake part? Memory transfer lag to and from GPU is significant in comparison to GPU computing power. Data lake may mean mutliple heterogeneous data sources with or without schema. How is coping with it helped by a GPU?