您的位置首页  电子商务  分析

什么数据库最适合数据分析师

  • 来源:互联网
  • |
  • 2017-09-11
  • |
  • 0 条评论
  • |
  • |
  • T小字 T大字
什么数据库最适合数据分析师  您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能…

原标题:什么数据库最适合数据分析师

  您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

  在“史前”单体巨兽型应用时代,配置管理不是什么大不了的事情,但今天在微服务架构中,配置管理已发生性的变化,但业内对这一块的前沿探索一直处于秘而不宣的状态,如果我们对这块没有过深入的思考和实践,我们很难真正理解为什么 Spring Cloud 会提出 Configuration Service 的概念。在面向分布式的微服务系统中,如何通过更高效的配置管理方式,帮助微服务系统架构持续“无痛”的...

  在“史前”单体巨兽型应用时代,配置管理不是什么大不了的事情,但今天在微服务架构中,配置管理已发生性的变化,但业内对这一块的前沿探索一直处于秘而不宣的状态,如果我们对这块没有过深入的思考和实践,我们很难真正理解为什么 Spring Cloud 会提出 Configuration Service 的概念。在面向分布式的微服务系统中,如何通过更高效的配置管理方式,帮助微服务系统架构持续“无痛”的...

  本期主要内容:重磅开源KSQL:用于Apache Kafka的流数据SQL引擎 ;洞悉流程!微服务与事件协同;Kafka设计解析: 流式计算的新贵 Kafka Stream;软件架构图的艺术;从金属巨人到深度学习,人工智能(极)简史;人工智能那些事儿;Google研究人员提出在移动设备上运行神经网络的新技术

  灵活和对意见保持的体系适用于各种规模的组织。本文可谓是一本关于如何打造价值观驱动型文化的规则手册,而这种文化不仅可以帮助新企业落地,而且还可以鼓励创新、主人翁心态、诚实反馈和全面沟通,从而使企业保持长期的竞争优势。

  作为最流行的敏捷框架,Scrum的发展早于DevOps;正因如此,Scrum(及其他敏捷框架)实践过度专注于广义上被定义为软件交付的开发方面,而忽视了运维方面。

  数据分析师都想使用数据库作为数据仓库处理并操作数据,那么哪一款数据库最合适分析师呢?虽然网上已经有很多对各种数据库进行比较的文章,但其着眼点一般都是架构、成本、可伸缩性和性能,很少考虑另一个关键因素:分析师在这些数据库上编写查询的难易程度。最近,Mode的首席分析师Benn Stancil发布了一篇文章,从另一个角度阐释了哪一款数据库最适合数据分析师。

  Benn Stancil认为数据分析工作不可能一蹴而就,分析师在使用数据库的过程中阻碍他们速度的往往不是宏观上的性能,而是编写查询语句时的细节。例如,在Redshift中如何获取当前时间,是NOW()、CURDATE()、CURDATE、SYSDATE 还是WHATDAYISIT。在Mode公司,分析师每天都会使用各种不同的语言编写几千个查询,运行在Mode编辑器里的查询超过百万个,而Benn Stancil就是从这些数据出发,对MySQL、PostgreSQL、Redshift、SQL Server、BigQuery、Vertica、Hive和Impala这八款数据库进行了比较。

  首先,Benn Stancil认为查询错误是否容易解决是衡量数据库的一个最基本指标。数据库提供的错误信息(通常是语法错误、函数名错误、逗号错位等)最能表明该系统是否会对数据分析师造成极大的感。通过对8种数据库查询错误频率的比较,Benn Stancil发现Vertica和SQL Server错误率最高,MySQL和Impala最低,如图所示:

  但是,对于该结果Benn Stancil认为可能有点不严谨,因为Impala、MySQL和Hive是开源的免费产品,而Vertica、SQL Server和BigQuery不是,后三者的用户通常是有充足分析预算的大型企业,其较高的错误率很有可能是由于使用更深入而不是语言“更难用”。

  除了错误率之外,Benn Stancil还讨论了复杂性。虽然不同语言其查询长度、查询复杂性和语言复杂性之间的关系盘根错节,要界定清楚很难,但可以间接使用查询长度作为度量的指标,因为一门语言之所以简单很有可能是因为它简洁。这八种数据库查询长度的统计结果如下:

  如果说单纯地比较最终的长度有失偏颇,那么可以看看随着分析的逐步深入,查询逐渐变复杂的过程中,其修改次数与长度之间的关系:

  该图显示,经过20次左右的编辑之后,查询长度通常会变为之前的2倍,而在100次编辑之后,长度会变为之前的3倍。那么在修改的过程中,其编辑次数与出错的比率又是什么样子的呢?

  此外,Benn Stancil认为分析师的技能也很重要。他对使用多个数据库并且在每个数据库上至少运行了10个查询的分析师进行了统计,计算了这些分析师在每个数据库上的查询错误率,并根据统计结果构建了下面的矩阵:

  该矩阵展示的是顶部数据库与左边数据库相比其错误率的差别,数值越高表现就越差。例如,Hive和BigQuery交叉处的“20.2”表示:对使用这两款数据库的分析师,其使用Hive的错误率要比使用BigQuery高20.2。最底部的Total行是结果总计,从中可以看出MySQL和PostgreSQL始终表现较好;Vertica跳跃最大,几乎是从最底部跳到了中游,打败了SQL Server 和Hive,这也暗示了Vertica的高错误率很可能是由于分析师的能力而不是语言本身。

  最后,Benn Stancil认为在分析的这8个数据库中,MySQL和PostgreSQL编写SQL最简单,应用也最广泛,但与Vertica和SQL Server相比它们的特性不够丰富,而且速度要慢。综合各方面的因素,Redshift或许才是最好的选择。

  给InfoQ中文站或者参与内容翻译工作,请邮件至也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群

  我们理解您使用ad blocker的初衷,但为了InfoQ能够继续以免费方式为您服务,我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单,感谢您的理解与支持。

免责声明:本站所有信息均搜集自互联网,并不代表本站观点,本站不对其真实合法性负责。如有信息侵犯了您的权益,请告知,本站将立刻处理。联系QQ:1640731186
友荐云推荐