对比这两套的时候考虑两点：

• 数据量：Spark一套潜在能处理的数据量大一些，但是多数业务需求远到不了Spark Streaming或者ELK的性能瓶颈
• 流处理计算复杂度：在复杂计算的场景下，Spark的API提供的表达能力更强一些，而且也比ELK的配置语言更容易进行充分的单元测试

与其将spark与elk 比较个天翻地覆，还不如握手言和，优势互补呢？

下面是我们将spark与lucene进行了结合，大家可以参考一下，让spark性能有质的提升，也让lucene功能更加完毕。

基于spark排序的一种更廉价的实现方案-附基于spark的性能测试

排序可以说是很多日志系统的硬指标（如按照时间逆序排序），如果一个大数据系统不能进行排序，基本上是这个系统属于不可用状态，排序算得上是大数据系统的一个“刚需”,无论大数据采用的是hadoop,还是spark，还是impala,hive，总之排序是必不可少的，排序的性能测试也是必不可少的。

有着计算奥运会之称的Sort Benchmark全球排序每年都会举行一次，每年巨头都会在排序上进行巨大的投入，可见排序速度的高低有多么重要！但是对于大多数企业来说，动辄上亿的硬件投入，实在划不来、甚至远远超出了企业的项目预算。相比大数据领域的暴力排序有没有一种更廉价的实现方式？

在这里，我们为大家介绍一种新的廉价排序方法，我们称为blockSort。

500G的数据300亿条数据，只使用4台 16核，32G内存，千兆网卡的虚拟机即可实现 2~15秒的 排序 （可以全表排序，也可以与任意筛选条件筛选后排序）。

一、基本的思想是这样的，如下图所示：

1.将数据按照大小预先划分好，如划分成 大、中、小三个块(block)。

2.如果想找最大的数据，那么只需要在最大的那个块里去找就可以了。

3.这个快还是有层级结构的，如果每个块内的数据量很多，可以到下面的子快内进行继续查找，可以分多个层进行排序。

4.采用这种方法，一个亿万亿级别的数据（如long类型），最坏最坏的极端情况也就进行2048次文件seek就可以筛选到结果。

<img src="https://i-blog.csdnimg.cn/blog_migrate/08b8524d4febca3bb2602519767060b1.png" data-rawwidth="867" data-rawheight="251" class="origin_image zh-lightbox-thumb" width="867" data-original="https://pic2.zhimg.com/v2-8a4e20c07a3a64df2dafc1a5921b7c91_r.png">

怎么样，原理是不是非常简单，这样数据量即使特别多，那么排序与查找的次数是固定的。

二、这个是我们之前基于spark做的性能测试，供大家参考

在排序上，YDB具有绝对优势，无论是全表，还是基于任意条件组合过滤，基本秒杀Spark任何格式。

测试结果(时间单位为秒)

<img src="https://i-blog.csdnimg.cn/blog_migrate/b64e0a81de9e5d6b1b6d30d5872e7732.png" data-rawwidth="847" data-rawheight="429" class="origin_image zh-lightbox-thumb" width="847" data-original="https://pic4.zhimg.com/v2-2d00349f4ddd2ebe24b0f2051631530f_r.png">

三、当然除了排序上，我们的其他性能也是远远高于spark，这块大家也可以了解一下

1、与Spark txt在检索上的性能对比测试。

注释：备忘。下图的这块，其实没什么特别的，只不过由于YDB本身索引的特性，不想spark那样暴力，才会导致在扫描上的性能远高于spark，性能高百倍不足为奇。

下图为ydb相对于spark txt提升的倍数

<img src="https://i-blog.csdnimg.cn/blog_migrate/bd6bbe431171cef63b68906fc2d738c9.png" data-rawwidth="802" data-rawheight="439" class="origin_image zh-lightbox-thumb" width="802" data-original="https://pic1.zhimg.com/v2-ec6e64b8f5cc8beef7ce6631e5e32410_r.png">

2、这些是与 Parquet 格式对比（单位为秒）

<img src="https://i-blog.csdnimg.cn/blog_migrate/1066bfc63539e5881084f66eb36353f7.png" data-rawwidth="582" data-rawheight="257" class="origin_image zh-lightbox-thumb" width="582" data-original="https://pic1.zhimg.com/v2-670b183631360e958fb0347923b95114_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/f3142f3aa2a5e909761174e668570da3.png" data-rawwidth="578" data-rawheight="282" class="origin_image zh-lightbox-thumb" width="578" data-original="https://pic3.zhimg.com/v2-d2fd38051e709a11495e9e4f657c866a_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/4a82e1ed4bde0ba7010d1c485e24d9f1.png" data-rawwidth="588" data-rawheight="251" class="origin_image zh-lightbox-thumb" width="588" data-original="https://pic3.zhimg.com/v2-66423dd2c7b14c9119321fb267ece292_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/70ba185dfaeed7fa2b6b16bf7bf9124f.png" data-rawwidth="591" data-rawheight="267" class="origin_image zh-lightbox-thumb" width="591" data-original="https://pic1.zhimg.com/v2-e55d1b752ca15a68df737c869c9dccd0_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/4a82e1ed4bde0ba7010d1c485e24d9f1.png" data-rawwidth="588" data-rawheight="251" class="origin_image zh-lightbox-thumb" width="588" data-original="https://pic3.zhimg.com/v2-66423dd2c7b14c9119321fb267ece292_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/a4bd1465574adc1d28de601ef4c5753a.png" data-rawwidth="583" data-rawheight="254" class="origin_image zh-lightbox-thumb" width="583" data-original="https://pic4.zhimg.com/v2-f25f4fbebc9f68065cdae74b9b1e0a7f_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/da86d6db4fa67949f4d47576e7e71c80.png" data-rawwidth="581" data-rawheight="241" class="origin_image zh-lightbox-thumb" width="581" data-original="https://pic4.zhimg.com/v2-f34eb3476a936651924676950f7e953f_r.png">
<img src="https://i-blog.csdnimg.cn/blog_migrate/86b96dfa514cbcb55569df22bbc2154a.png" data-rawwidth="580" data-rawheight="266" class="origin_image zh-lightbox-thumb" width="580" data-original="https://pic3.zhimg.com/v2-488409cddce1def4b7709f01b4a1093a_r.png">

3、与ORACLE性能对比

跟传统数据库的对比，已经没啥意义，Oracle不适合大数据，任意一个大数据工具都远超oracle 性能。

<img src="https://i-blog.csdnimg.cn/blog_migrate/abb1f2e6ce832558028c4882367db24f.png" data-rawwidth="702" data-rawheight="420" class="origin_image zh-lightbox-thumb" width="702" data-original="https://pic4.zhimg.com/v2-abf665afa10fab37fee1d9505214f1e7_r.png">

4.稽查布控场景性能测试

<img src="https://i-blog.csdnimg.cn/blog_migrate/f9654fe50b111af4a0d50d03cc9313a6.png" data-rawwidth="666" data-rawheight="349" class="origin_image zh-lightbox-thumb" width="666" data-original="https://pic2.zhimg.com/v2-691e92dcb3a49e4a32126a3dd7a44f79_r.png">

四、YDB是怎么样让spark加速的？

基于Hadoop分布式架构下的实时的、多维的、交互式的查询、统计、分析引擎，具有万亿数据规模下的秒级性能表现，并具备企业级的稳定可靠表现。

YDB是一个细粒度的索引，精确粒度的索引。数据即时导入，索引即时生成，通过索引高效定位到相关数据。YDB与Spark深度集成，Spark对YDB检索结果集直接分析计算，同样场景让Spark性能加快百倍。

<img src="https://i-blog.csdnimg.cn/blog_migrate/cfd1ad875d10dd72738f796cb8b9f576.png" data-rawwidth="690" data-rawheight="361" class="origin_image zh-lightbox-thumb" width="690" data-original="https://pic2.zhimg.com/v2-2c6106f29375369c380167a23a50426d_r.png">

五、哪些用户适合使用YDB？

1.传统关系型数据，已经无法容纳更多的数据，查询效率严重受到影响的用户。

2.目前在使用SOLR、ES做全文检索，觉得solr与ES提供的分析功能太少，无法完成复杂的业务逻辑，或者数据量变多后SOLR与ES变得不稳定，在掉片与均衡中不断恶性循环，不能自动恢复服务，运维人员需经常半夜起来重启集群的情况。

3.基于对海量数据的分析，但是苦于现有的离线计算平台的速度和响应时间无满足业务要求的用户。

4.需要对用户画像行为类数据做多维定向分析的用户。

5.需要对大量的UGC（User Generate Content）数据进行检索的用户。

6.当你需要在大数据集上面进行快速的，交互式的查询时。

7.当你需要进行数据分析，而不只是简单的键值对存储时。

8.当你想要分析实时产生的数据时。

ps: 说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。

视频地址 （看不清的同学可以进入腾讯视频 高清播放）

https://v.qq.com/x/page/q0371wjj8fb.html

https://v.qq.com/x/page/n0371l0ytji.html

感兴趣的读者也可以阅读YDB编程指南 http://url.cn/42R4CG8 。也可以参考该书自己安装延云YDB进行测试。

应付常见的日志摘要和分析是没问题的，上PB级的数据量也不是难事。
ELK简单、轻量、易扩展倒是真的，但数据容量，二次抽洗，以及周边生态，还是没有Hadoop来得好。
elk在掌握简单的正则以后即可对任意数据进行抽取（要求半格式化数据），处理同样的数据spark还需要学一门编程语言。