10 ms·
BlazingSQL – GPU SQL Engine Now Runs Over 20X Faster Than Apache Spark
- aocsa 8y agoexcellent work!
- ris 8y agoThe source being where?
- felipe_aramburu 8y agoMost of the execution kernels that we use are in https://github.com/rapidsai/cudf https://github.com/rapidsai/cudf . The engine itself is not open source though it is free to use and we have a dockerhub link which is pretty convenient. https://hub.docker.com/r/blazingdb/blazingsql/ https://hub.docker.com/r/blazingdb/blazingsql/ Conda works too but its still a bit painful and we are working on making that a bit more user friendly.
- wazokazi 8y agoIs there support for loading data from Parquet files?
- roaramburu 8y agoThere is, this demo is done with CSV's b/c we can't read Apache Parquet files with strings yet (changing very very very soon). You can check out how here: https://docs.blazingdb.com/docs/database-administration#section-apache-parquet https://docs.blazingdb.com/docs/database-administration#sect...
- dominotw 8y agohttps://www.youtube.com/watch?v=tUIrR_mj9fQ&index=4&list=PLSE8ODhjZXjbjOyrcqgE6_lCV6xvzffSN https://www.youtube.com/watch?v=tUIrR_mj9fQ&index=4&list=PLS... cmu talk series
- paulsutter 8y agoBetter headline, "Apache Spark Is Very Slow". Only 1 megabyte per second per node? (3.8GB/(8 nodes*500 seconds)) Even with single core nodes, that's utterly feeble (pro tip, please state the kind of node you're using) Seems fishy that the benchmark is small enough to fit into GPU RAM as well
- twtw 8y agoPro tip: justify why dividing data set size by time to solution and saying number is small is a good analysis. Let's try imagenet training. Intel's best time is 3h25m on 128 nodes. Imagenet is ~150 gb. (150 GB)/(3 hr * 3600 sec/hr * 128 nodes) = less than one megabyte per second per node! Caffe is slow! CPUs are slow! Or bs metrics are bad? https://dawn.cs.stanford.edu/benchmark/ImageNet/train.html https://dawn.cs.stanford.edu/benchmark/ImageNet/train.html
- jmalicki 8y agoIntel's run wasn't 3:25 per epoch, which is the difference. A simple ETL should be one linear scan over the data, with maybe some merges, nothing I saw here seemed more complex than that?
- paulsutter 8y agoThis is ETL processing, not training a neural network. If their (undisclosed) actual task is not parallelizable in Spark, the comparison is even sillier so let's be generous and assume it is.
- felipe_aramburu 8y agoThe GPU workload is used in feeding XGBOOST to perform classification. We are omitting this timing on purpose because the training time on purpose becuase SPARK took 1000's of times longer for this part of the workflow. You can see the workflow for yourself and see how the task is quite parallelizable.
- 8y ago
- dswalter 8y agoI couldn't find any license information for BlazingSQL. Where is that available?
- roaramburu 8y agoSorry, didn't have it available easily. You can see it here: https://www.blazingdb.com/#/eula https://www.blazingdb.com/#/eula Our open source code (the compute kernels, GPU DataFrame, etc.) is part of RAPIDS AI. You can see source and license here: https://github.com/rapidsai/cudf https://github.com/rapidsai/cudf
- hbogert 8y agoNow an experiment with 4 gpu nodes. Horizontal scaling matters as well, which is not shown here. Furthermore, using less than 16gb of data.. why would you use these frameworks in the first place? It is common knowledge that a grep and sort on 100gb is faster than Hadoop, however 100tb is a different story
- felipe_aramburu 8y agoUncoordinated distributed is coming soon. We have been building this tool with distribution in mind and right now are finishing up our first distributed version of BlazingSQL which we will be releasing just before GTC ~March 15th. We have already distributed using dask which you can do RIGHT now with blazingsql but we felt it would not be fair to make a comparison between distributed blazingsql which is user managed and something like spark which happens under the hood. We will be releasing distributed numbers early March where we can show differences between BlazingSQL and larger spark clusters where the distribution is handled by the engine instead of the user.
- PeterZaitsev 8y agoHi, Apache Spark is easy target to beat. I would be much more interested looking at comparison to ClickHouse :)
- felipe_aramburu 8y agoDo you have an example of workloads that are easy to reproduce using clickhouse so we can see how much effort it would be to make a comparison? We are always happy to test against other tools!
- bicubic 8y agoI mean it has pretty full-featured sql support, so you can probably reproduce your current scenario with it?
- felipe_aramburu 8y agoAnd you think https://tech.marksblogg.com/billion-nyc-taxi-rides-clickhouse-cluster.html https://tech.marksblogg.com/billion-nyc-taxi-rides-clickhous... for example is something that can be considered fast? It takes the user 55 minutes just to load its data into a state so that it can be "queryable". After importing then they spend 34 more minutes making the data into a columnar representation. Alright so 89 minutes in and we still haven't run queries. Oh but its not distribute yet. Darn I have to run some non standard sql commands like CREATE TABLE trips_mergetree_x3 AS trips_mergetree_third ENGINE = Distributed(perftest_3shards, default, trips_mergetree_third, rand()); Ok can I query my data yet? No you have to move it into this distributed representation and that takes 15 more minutes. Oh ok... And now? Yes you can run your queries but they aren't really very fast. SELECT cab_type, count(*) FROM trips_mergetree_x3 GROUP BY cab_type; Can take 2.5 seconds on a 108 cpu core cluster for only 1.1BN rows? Thats not fast. That's particularly slow given that requires you to ingest and optimize your data. Maybe you want to show us an example of some simple tests you have run with blazing and clickhouse. As I read it now its not worth our time to look into becuase its so very different from what we are trying to offer which is: Connect to your files wherever you have them ETL quickly Train / Classify Move on!
- budde 8y agoYeah, this is really, really far from an apples-to-apples comparison. First of, the test dataset size is trivially small for usecases where big data systems are typically applied. I don't know why you'd introduce all the complexity and overhead of a distributed mapreduce framework to ETL a dataset that would fit in memory on consumer-grade hardware. It's not exactly fair to compare a framework running on a single node to one where you've artificially introduced multiple nodes and network overhead for a dataset that would easily fit on one. You'll also notice a pretty stark difference between the level of detail provided for the BlazingSQL test set up and the Spark one, which (unless I'm missing something) is lacking any code or configuration details. I've dipped my toes in the big data space long enough and seen enough "${FANCY NEW FRAMEWORK} beats ${INDUSTRY-STANDARD FRAMEWORK} by 123x!!" posts to recognize this as a gigantic red flag. How you manage partition sizes, order and choice of operations, and tuning parameters can make orders-of-magnitude level differences to your performance. Maybe the future of frameworks like this will be on the GPU. I'm just not seeing any evidence of it yet. Right now, Spark fills the space where you can throw globs of memory at TB- to PB-scale problems. I could very well be wrong, but I don't see how this is going to be cost-effective on GPUs given the current cost of memory there.
- felipe_aramburu 8y ago1. You don't have to fit your whole workload on the GPU you can process it in batches like you would for a workload that doesn't fit into memory on a non gpu solution. You don't need PB of GPU memory to run PB workloads. 2. The dataset is trivially small because this is a new engine built for the rapids eco system and it is limited for the time being to a single node. We are releasing our distributed version for GTC (mid March) and will be able to give you more reasonable comparisons. This is a similar path of development to our pre Rapids engine which went from single node to distributed in about a month because we have built this engine to be distributed. Right now we are finishing up UCX integration which is the layer we will be using to communicate between all the nodes. 3. You can always try it out. Its own dockerhub (see links in this post) and if you want to run distributed workloads right now you can manage that process using dask by handling the splitting up of the job yourself. In a few weeks you will be able to have the job split up for you automatically without need for the user to be aware of the size of the cluster or how to distribute data across it.
- heavenlyblue 8y agoSo how's the string support on BlazingSQL?
- lmeyerov 8y agoThe reason our team (graphistry) is working w/ the BlazingDB team is q's like this. BlazingSQL subsumes RAPIDS / cudf... which now includes the GPU-optimized nvstrings lib. And instead of a hacky grad student's GPU string lib, this is Nvidia's. We initially bet on OpenCL... but had to write almost everything ourselves. We then switched to GOAI, despite having to write much of Apache Arrow[JS], among other things. I love q's like that now that more and more pieces are falling into place with best-of-class tech. That's a big deal for our users, and helps our small punch above our weight for helping them. 2019 will be fun!
- felipe_aramburu 8y agoComing in the current sprint. We have a PR open agaisnt CUDF that brings string support to many of the CUDF algorithms. We will be using this branch in the meantime in our engine while we wait for the PR to be accepted.
- bithavoc 8y agoHow different is BlazingSQL to Uber's AresDB[0]? [0]https://eng.uber.com/aresdb/ https://eng.uber.com/aresdb/
- felipe_aramburu 8y agoIn lots of ways. AresDB has ingestion. Users take their data and say here make a table from this, persist that data the way I want you to great now I can query it and go along my merry business. I see lots of nice fancy optimizations in there. The kinds of things a small company like Blazing can only marvel at! I also see a completely different use case. We don't want to ingest data into Blazing. That is NOT our cup of tea. We will make tools to help you persist data quickly. Working on it. But we want to read data the way YOU store it without asking you to duplicate it into our system and requiring significant effort from the user. You have files. Great we can read them, query them, do all kinds of acrobatics on them and don't need you to store redundant copies of what you already had. The files are stored in S3 or HDFS and other file systems. Great, we have built connections to interface with those file systems and you can query directly from them. A user should be able to get blazing's docker container. Register a filesystem with the engine, and start querying their files within minutes of having launched the container. When we don't do this we fail. It does not seem to me that AresDB is trying to do this but I could be completely wrong and if you think so please tell me why! BlazingDB is meant to be connected to other tools in the rapids eco system. You interact with it through python. You can 0 copy IPC the data to any other tool in the rapids eco system. Want to a power a dashboard, sure, but this isn't the use case that we are optimizing for. We don't have a JDBC connection. We don't connect to tableau. Blazing Focuses on Interpreting rather than JITing. Instead of focusing on trying to make the most performant compiled code possible by JITing exactly what we want we pay a process cost that reduces I/O. We convert Logical Plans into physical execution plans that are suitable for a SIMD architecture whose optimization centers around minimizing materializations and global memory accesses. We tried JIT but couldn't find a way to compile plans in less than a few hundred nano seconds at which point the overhead of compiling superseded that of interpreting operations in a kernel.
- continuations 8y agoSo I saw this on their website: "SQL on RAPIDS, the open-source GPU data science framework" So is BlazingSQL open source? If it is where is the source code & what license is it? Also where is the source code for RAPIDS? And what license is it?
- twtw 8y agoBit of a lmgtfy question, but here you go: https://github.com/rapidsai https://github.com/rapidsai https://github.com/rapidsai/cudf/blob/branch-0.6/LICENSE https://github.com/rapidsai/cudf/blob/branch-0.6/LICENSE
- georgewfraser 8y agoSpark is not a very fast SQL engine. A more appropriate comparison would be something like Redshift or Snowflake. This GitHub repo [1] contains the source code to run TPC-DS on 5 data warehouses; it would be great to add BlazingDB. [1] https://github.com/fivetran/benchmark https://github.com/fivetran/benchmark
- michelpp 8y agoThere is also GPU support for PostgreSQL using an extension called pg-strom https://github.com/heterodb/pg-strom https://github.com/heterodb/pg-strom Not sure how it compares to this tool, but it uses a GPU to do both high density analytics, by loading data straight from disk to the gpu with dma avoiding the cpu entirely to do the work, or by using the GPU as a prefilter to remove lots of candidate rows and then letting the CPU do the core query on much fewer rows.
- felipe_aramburu 8y agoPG-Strom is a great way to make postgres faster. Nice. But if the purpose is here to build very fast and responsive system which is interacting with other gpu tools well then snap I don't see how it can compete. The old school way of, run this query, get my results, read those results using something like jdbc, is too slow. You can literally take out the "run this query" portion and it will still be slower than what we believe needs to exist to power GPU accelerated workloads. We are trying to keep up with the pace of hardware improvements that NVIDIA has been churning out. Moving a result set from Postgres ==> "wherever I need to be" by performing copies and making allocations for that data is a cost we want to save people from.
- moocowtruck 8y agolink to the source ? i couldn't find it on the page
- felipe_aramburu 8y agohttps://github.com/rapidsai https://github.com/rapidsai is the source for the rapids tools. BlazingSQL itself is not open source though it is free to use.
- m0zg 8y agoMolasses is fast compared to Apache Spark. Compare to something like Redshift or Google BigQuery, and on a much larger dataset.
- jarjar12 8y agoKeep up the great work. Don’t listen to others.
- techie128 8y agoI am generally not critical of people posting benchmarks. Neither am I trying to rain down on your parade but seriously you do not use Apache Spark to process 3.8G or 15.6G of data. It is too trivial.
- felipe_aramburu 8y agoI do not disagree with you. We are going to be publishing much larger benchmarks soon. Before we could start building BlazingSQL we had to work on CUDF in the rapids eco system. There was alot of work that went into building all of the primitives that were needed for both our sql engine and all of the other wonderful tools that are now leveraging CUDF. We have to start somewhere and if you think we should compare against something else please tell us what you think we should compare ourselves to! We are already looking into some of the other tools that have been mentioned here in the comments.
- mastrsushi 8y agoDon't SQL engines typically run on servers which lack GPU's? That pretty much kills the entire hardware demographic of enterprise SQL users.
- felipe_aramburu 8y agoThe purpose of blazing is to accelerate GPU workloads. SQL is just a language we provide users as an interface for performing complex transformations in the rapids eco system. rapids.ai We aren't targeting enterprise sql users specifically. We are targeting people using GPUs that want to accelerate the process of making information available to those gpus by leveraging the GPUs for the process of parsing (CSV), decompressing (Parquet) and then transforming data to make it suitable for machine learning, classifying etc.
- hyperpallium 8y agoSELECT colA + colB * 10, sin(colA) — cos(colD) FROM tableA GPUs excel at parallel trigonometry computation.
- einpoklum 8y agoOnly if your data is already on the GPU. Otherwise, this little computational work is swamped by the cost of I/O back and forth to main memory.
- cavisne 8y agoUber and others seem to be having success with GPU accelerated big data workloads but it’s hard to see how this would work in a cloud environment. Nvidia price descrimination works for ML/rendering tasks that almost mandate GPUs but it would significantly reduce the value for generic workloads
- felipe_aramburu 8y agoWhat makes it hard to work in a cloud environment? The on demand nature of it? The fact that you only pay for the time you are using it? The ease of scaling or deployment? It would be helpful if you could qualify some of these statements.
- fulafel 8y agoTo save time from anyone else curious, BlazingSQL requires a Nvidia GPU and Linux. (https://blazingdb.com/#/documentation https://blazingdb.com/#/documentation)
- thanatos_dem 8y agoWhat’s going on with that first graph? The scale changes from 1500” to 3000”, but Spark’s bar sizes stay the same. Did Spark have a 2x slow down between the tests? It seems pretty misleading.
- thestephen 8y agoFurther down in the article: In our original demo, we ran a V100 GPU against 8 CPU nodes. The new T4 GPUs cut our cost in half, which meant we reduced the Apache Spark cluster to 4 CPU nodes in order to maintain price parity. Even with the reduced GPU memory, the whole workload ran significantly faster.
- einpoklum 8y agoActually, what you should normalize is operating costs, so probably power consumption is the better figure to normalize by. ... on the other hand, that's more difficult to measure, and TDP figures are not what really happens.