抄一些大数据技术总结

作者：夏然
链接：https://www.zhihu.com/question/41541395/answer/172981131
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

使用Mysql，PostgreSQL等关系型数据库，不仅用于业务查询（OLTP），也做统计分析，一般是在现有业务数据库上直接做一些分析需求。这种方式在数据量增长之后就会遇到性能问题，特别是分析查询会对业务查询产生极大影响。可以考虑把数据导入IndexR做分析，即把业务数据库和分析数据库分开。ES，Solr等全文搜索数据库用于统计分析场景。这类数据库最大的特点是使用了倒排索引解决索引问题。对于统计分析场景通常没有特别优化，在大数据量场景下内存和磁盘压力比较大。如果遇到性能问题，或者数据量撑不住了，可以考虑使用IndexR。Druid，Pinot等所谓时序数据库。在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，从我们的使用经验来看运维比较困难，灵活性和扩展性不够，比如缺乏Join、子查询等。在保存大量历史数据情况下需要的硬件资源相对昂贵。这种场景下可以考虑使用IndexR直接替换，不用担心业务实现问题。Infobright，ClickHose等列式数据库。列式数据库本身非常适合于OLAP场景，IndexR也属于列式数据库。最大的区别在于IndexR是基于Hadoop生态的。离线预聚合，建Cube，结果数据存放于HBase等KV数据库，如Kylin等。这种方式在只有多维分析场景且查询比较简单的情况下非常有效。问题就在于灵活性不足（flexibility），无法探索式分析，以及更复杂的分析需求。IndexR可以通过表配置达到预聚合的效果，并且聚合是实时，没有延迟的；可以保留原始数据或者高维度数据，通过表路由决定具体的查询表。为了解决大数据量的即时分析问题，上层使用Impala，Presto，SparkSQL，Drill等计算引擎来做查询，存储层使用开源数据格式比如Parquet，基于Hadoop生态。这类架构和IndexR很相似。IndexR的优势在于更有效的索引设计，更好的性能，并且支持实时入库，秒级延迟。我们在相同环境下与Parquet格式做过查询性能对比，IndexR的查询速度提升在3~8倍以上。之后IndexR经历了很大的性能优化，估计会有更好的表现。Kudu，Phoenix等既支持OLTP场景，又为OLAP场景优化等开源产品。通常很难两者兼顾，建议分成实时库和历史库，针对不同数据特点采用不用的存储方案。内存数据库。贵。。

作者：Madeline Watson
链接：https://www.zhihu.com/question/41541395/answer/161847551
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

前面三个系统基本就是一个execution engine让你用类似sql的语言或者jdbc去查询存在hdfs上面的数据。你可以选择数据在hdfs上面的储存格式（最简单的csv，json，或者更高级的parquet之类的columnar format）。区别：hive基本没有in memory caching，predicate push down的优化也一般。presto和spark sql新一些，caching和query optimistization比hive好，benchmark快很多。spark sql是spark这个平台的一部分，所以除了query以外，可以直接在spark这个平台上轻松写负责的data pipeline，减轻integration的麻烦。presto本身只是sql execution engine，做data pipeline的时候还是要用spark之类的。不过如果很多人同时查询的话，presto更快一些。BI工具（tableau之类的）可以直接链接spark sql和presto。Druid号称能在几秒的时间里处理billion 行。这个实践基本是能做到的。不过druid的问题是要它不能理解sql or jdbc，而是要用它自己一套语言写query。所以用起来非常麻烦，周边BI的支持非常差，我知道只有airbnb的superset支持druid。当然druid最新版0.10加了experimental的sql。是不是成熟还有待观察。