对历史大数据,进行实时交互式查询(秒级)?

如果我的HDFS有10T的数据(原数据),并准备把它们做成实时的交互式查询(秒级)?请问有什么比较好的方案?
    1> spark sql 与 impala 哪个更合适?
    2> 我的10T原数据,是否需要做结构初始化?是否需要存储到类似Hbase这样的数据库?(我用spark操作hbase还是花费了不少启动spark的时间)
    3> 像这种针对比较大的历史数据做实时操作,是直接操作HDFS文件数据好,还是操作类似Hbase这样的key-velue好?
    4> 因为是原数据,是否需要类似机器学习这样的训练,把数据处理一下?
    5> 补充:我现在用spark on yarn的模式批处理这些数据(某区域部分)做查询,时间很慢,spark任务启动就耗费不少时间,无法达到10秒内出查询结果。
拜谢!

李扬 - Apache Kylin committer & PMC member, Sr. Architect of eBay CCOE

赞同来自: fish 依韵

10T级别的数据,光扫描一遍就不止10秒。所以不可能直接在元数据上查询,必需先构建索引。   大数据索引主流也就两种,应该都能满足需求。 - 数据立方体 (MOLAP Cube) [1] - 倒排索引 (Inverted Index) [2]   如果需求比较简单,而且不太会变,自己开发完全没问题。建索引用MR或者Spark都可以,差不了太多。   如果不想自己开发,或者需求很多,不想长期自行开发,可以考虑采用分析工具。常用的开源工具ElasticSearch, Pinot, Druid都是走倒排索引的路子,Kylin走的是数据立方体的路子。   [1] http://webdataanalysis.net/web-data-warehouse/data-cube-and-olap/ [2] https://zh.wikipedia.org/wiki/%E5%80%92%E6%8E%92%E7%B4%A2%E5%BC%95  

fish - Hadooper

赞同来自: 依韵

看样子是个olap的需求?只能有spark跟impala两个选择么? druid或者pinot或者kylin? 如果启用parquet等列式存储方式之后,spark的性能是否能达到需求? 如果对实时性要求比较高的,直接的hdfs文件(甚至是文本文件),肯定不适合。 “因为是原数据,是否需要类似机器学习这样的训练,把数据处理一下”,这句话怎么理解?是否需要机器学习与业务相关。  

fish - Hadooper

赞同来自: 依韵

或者自己做个简单的版本,自己写个mapreduce,计算每个关键词出现在hdfs中的文件名和偏移量,把结果放到redis或者hbase这样的kv系统中,请求来时,先查kv,得到结果再到hdfs文件中seek➕read获取数据。

依韵

赞同来自:

QQ截图20151124184325.jpg
数据格式如图: 比如里面这句: ST Post: orderseq[11510160004524883077]ordernum[2015101600144933] transnum[09181201510167497239]  有可能“11510160004524883077”会变成用户的查询条件,也有可能“2015101600144933”、“09181201510167497239”变成查询条件。   查询结果:要查到的关键字所在数据行,加上该数据行下面20行数据,去作为查询结果数据。   所以,我觉得普通数据清洗没法做,这个问题机器训练是否能解决?

fish - Hadooper

赞同来自:

就这这样的简单查询么? 那就是做个搜索倒排索引啊,不是olap也不是机器学习。   看看Elastic Search。

要回复问题请先登录注册