基于spark SQL之上的检索与排序对比性能测试
发布网友
发布时间：2022-04-29 22:52
共3个回答
热心网友
时间：2022-04-08 00:48
之前做过一年的spark研发，之前在阿里与腾讯也做了很久的hive，所以对这方面比较了解。
第一：其实快多少除了跟spark与hive本身的技术实现外，也跟机器性能，底层操作系统的参数优化息息相关，不能一概而论。
第二：hive 目前应该还是业界的主流，毕竟快与慢很多时候并非是至关重要的，对于一个生产系统来说，更重要的应该是稳定性，spark毕竟还算是比较新兴的事务，快确实快，但是稳定性上距离hive相差甚远。关于spark我们也修复了很多关于内存泄露的BUG，因为您问的是性能，所以不过多介绍（可以跟我要YDB编程指南，里面有我对这些BUG的修正）
第三：关于性能，我测试的可能不够全面，只能在排序与检索过滤上提供我之前的基于YDB的BLOCK sort测试报告供您参考（百度上贴word太费劲，您可以跟我要 word文档）。
排序可以说是很多日志系统的硬指标（如按照时间逆序排序），如果一个大数据系统不能进行排序，基本上是这个系统属于不可用状态，排序算得上是大数据系统的一个“刚需”,无论大数据采用的是hadoop,还是spark，还是impala,hive，总之排序是必不可少的，排序的性能测试也是必不可少的。
有着计算奥运会之称的Sort Benchmark全球排序每年都会举行一次，每年巨头都会在排序上进行巨大的投入，可见排序速度的高低有多么重要！但是对于大多数企业来说，动辄上亿的硬件投入，实在划不来、甚至远远超出了企业的项目预算。相比大数据领域的暴力排序有没有一种更廉价的实现方式？
在这里，我们为大家介绍一种新的廉价排序方法，我们称为blockSort。
500G的数据300亿条数据，只使用4台 16核，32G内存，千兆网卡的虚拟机即可实现 2~15秒的 排序 （可以全表排序，也可以与任意筛选条件筛选后排序）。
一、基本的思想是这样的，如下图所示：
1.将数据按照大小预先划分好，如划分成 大、中、小三个块(block)。
2.如果想找最大的数据，那么只需要在最大的那个块里去找就可以了。
3.这个快还是有层级结构的，如果每个块内的数据量很多，可以到下面的子快内进行继续查找，可以分多个层进行排序。
4.采用这种方法，一个亿万亿级别的数据（如long类型），最坏最坏的极端情况也就进行2048次文件seek就可以筛选到结果。
怎么样，原理是不是非常简单，这样数据量即使特别多，那么排序与查找的次数是固定的。
二、这个是我们之前基于spark做的性能测试，供大家参考
在排序上，YDB具有绝对优势，无论是全表，还是基于任意条件组合过滤，基本秒杀Spark任何格式。
测试结果(时间单位为秒)
三、当然除了排序上，我们的其他性能也是远远高于spark，这块大家也可以了解一下
1、与Spark txt在检索上的性能对比测试。
注释：备忘。下图的这块，其实没什么特别的，只不过由于YDB本身索引的特性，不想spark那样暴力，才会导致在扫描上的性能远高于spark，性能高百倍不足为奇。
下图为ydb相对于spark txt提升的倍数
2、这些是与 Parquet 格式对比（单位为秒）
3、与ORACLE性能对比
跟传统数据库的对比，已经没啥意义，Oracle不适合大数据，任意一个大数据工具都远超oracle 性能。
4.稽查布控场景性能测试
四、YDB是怎么样让spark加速的？
基于Hadoop分布式架构下的实时的、*的、交互式的查询、统计、分析引擎，具有万亿数据规模下的秒级性能表现，并具备企业级的稳定可靠表现。
YDB是一个细粒度的索引，精确粒度的索引。数据即时导入，索引即时生成，通过索引高效定位到相关数据。YDB与Spark深度集成，Spark对YDB检索结果集直接分析计算，同样场景让Spark性能加快百倍。
五、哪些用户适合使用YDB？
1.传统关系型数据，已经无法容纳更多的数据，查询效率严重受到影响的用户。
2.目前在使用SOLR、ES做全文检索，觉得solr与ES提供的分析功能太少，无法完成复杂的业务逻辑，或者数据量变多后SOLR与ES变得不稳定，在掉片与均衡中不断恶性循环，不能自动恢复服务，运维人员需经常半夜起来重启集群的情况。
3.基于对海量数据的分析，但是苦于现有的离线计算平台的速度和响应时间无满足业务要求的用户。
4.需要对用户画像行为类数据做*定向分析的用户。
5.需要对大量的UGC（User Generate Content）数据进行检索的用户。
6.当你需要在大数据集上面进行快速的，交互式的查询时。
7.当你需要进行数据分析，而不只是简单的键值对存储时。
8.当你想要分析实时产生的数据时。
ps: 说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。
热心网友
时间：2022-04-08 02:06
desc，降序
热心网友
时间：2022-04-08 03:41
大索引技术大数据的未来
一、大索引技术，大数据的未来
YDB并没有采用堆积机器，靠大内存和SSD硬盘的方式来提升计算速度。YDB采用索引技术,
在RDBMS中索引的概念大家一点都不陌生，但是在大数据里大家似乎没有听过，YDB将索引创建在HDFS中，通过索引技术，将大数据分门别类整理好，就像是一个新华字典的目录，通过目录可以快速到相关数据，避免了暴力的扫描，从而提升查询速度。
1.当大数据使用上大索引后有什么好处？
l索引技术大幅度的加快数据的检索速度。
l索引技术可以显著减少查询中分组、统计和排序的时间。
l索引技术大幅度的提高系统的性能和响应时间，从而节约资源。
2.这个大索引系统应该什么样？
l数据规模超大：万亿甚至十万亿。
l数据时效性高：数据从产生到能够查询到结果这个间隔1~2分钟。
l查询响应要快：从万亿规模的数据里，查询到相关数据，响应时间为毫秒或者几秒。
l支持容灾：要能够支撑可靠的容灾，并且保证良好的数据的准确性。
l能够与现有的大数据系统进行较好的融合，方便系统之间的交互（数据导入导出）
3.传统索引的缺点
传统的关系型数据库的索引目前存在如下几个问题，是需要改进的。
l索引存储在本地硬盘
首先是分散在机器的每个硬盘上，索引不容易管理，容灾与高可用的实现代价较高。
其次是索引的迁移成本以及单机硬盘的容量制约了其索引规模和大小。
最后是如果是通过冗余（”master/slave”或者”双写”）等方式实现数据容灾，数据一致性的设计难度较大。
本地硬盘往往并不可靠，如果存在“坏点”问题，某一时刻读取到的某段数据其中有一个byte的值是异常的，操作系统并不能及时的发现，但是也有可能引起整个索引的指针异常，查询到的数据不准确。
l表的管理、索引、调度曾混杂在一起，集群规模上不去
索引数据、计算资源掺杂在一起，调度系统管理的事情太多，既要管理索引，又要管理心跳，也要维护容灾，导致调度系统的机器规模上不来。同一个计算资源只分配给固定的索引数据导致计算资源太多的浪费。
l对硬件要求太高
数据必须长期持久的滞留在内存中，否则无法快速的加载和查询数据，对硬件要求较高一般都是需要大内存（128G以上）以及SSD硬盘，百亿规模的数据甚至需要数百台机器来支撑快速的查询，对于万亿规模的数据来说成本太高.
4.基于YDB的大索引的特点
随着基于Hadoop Yarn技术的趋于成熟，以及在HDFS中的索引技术的成熟和性能的提升，低延迟的万亿规模的索引技术有了希望。
lYarn本身是一套完美的任务调度系统，他解决了Hadoop1.0版本JobTracker调度的不足，调度延迟时间大大缩小，并且适合实时的即席任务调度，启动的任务是可以长久的持久化运行，并且有很好的容灾机制。
l索引可以直接存放在HDFS中，通过HDFS来解决数据的容灾问题，让业务能更专注索引的实现。索引直接存储在HDFS上，通过HDFS来实现数据的高可用，这样程序的设计复杂性就会减少很多，不再担心本地硬盘的问题（是否损坏，是否已满，硬盘损坏时迁移时间过长），也不用担心各种网络的问题，理论上HDFS上有多大的空间，我们就可以存储多少索引，不再受限于本地磁盘大小的*，数据规模可以很容易的水平拓展。
l易于使用与部署，在任意节点启动YDB。服务直接在Yarn上启动，Yarn自动部署与分发，不在需要集群一台一台的配置。
l将索引数据与计算资源的分开，不再交叉的放在一起，分别管理，划清界限，减少程序设计复杂度。计算资源的管理直接交给Yarn来处理，从而提升集群的规模。
l一个计算资源不再固定的负责一个索引，而是根据实际的计算需要，处理不同的索引，这比之前一个资源(CPU+内存)固定的分配给一个索引利用率会高很多，因为并不是每次检索和查询都需要扫描全部的数据，有些数据根本就不需要或者很少去查，就没必要让他们长期的占用一个资源。
l索引的管理将会充分的放权，采用HDFS的目录形式的层次结构，便于管理，外部可以自由的配置索引的存储目录，根据不同业务的需要，索引可以按照时间进行打散，按照时间进行目录分区，也可以按照某些用户ID进行hash，也可以按照某些业务来管理配置不同的生命周期。
lYDB是一个细粒度的、精确粒度的索引。数据即时导入，索引即时生成，通过索引高效定位到相关数据。YDB与Spark深度集成，Spark直接对YDB检索结果集分析计算，同样场景让Spark性能加快百倍
l这个版本的YDB除了可以单独对外提供服务，也会更加的开放，对外提供索引服务，提供了很多拓展功能，现有的Hive以及Spark可以很方便的通过类似InputFormat或RDD的方式直接使用大索引。同时可以方便的与HDFS，Hbase，Hive，进行交互，也可以通过自定义实时的消费Kafka，MetaQ等消息队列的数据。
试想下，Spark在利用上这个大索引后，一个万亿规模的数据，几秒钟就返回结果，而且还支持很多的复杂查询，是不是很值得期待呢 。
