使用ElasticSearch作为大数据平台的实时OLAP框架 - 推酷
使用ElasticSearch作为大数据平台的实时OLAP框架
关键字：elasticsearch、olap
一直想找一个用于大数据平台实时OLAP（甚至是实时计算）的框架，之前调研的Druid（druid.io）太过复杂，整个Druid由5、6个服务组成，而且加载数据也不太方便，性能一般，亦或是我还不太会用它。后来发现使用ElasticSearch就可以满足海量数据实时OLAP的需求。
ElasticSearch相信大家都很熟悉了，它在搜索领域已经有了举足轻重的地位，而且也支持越来越多的聚合统计功能，还和YARN、Hadoop、Hive、Spark、Pig、Flume等大数据框架兼容的越来越好，比如：可以将ElasticSearch跑在YARN上，还可以在Hive中建立外部表映射到ElasticSearch的Index中，直接在Hive中执行INSERT语句，将数据加载进ElasticSearch。
所谓OLAP，其实就是从事实表中统计任意组合维度的指标，也就是过滤、分组、聚合，其中，聚合除了一般的SUM、COUNT、AVG、MAX、MIN等，还有一个重要的COUNT(DISTINCT)，看上去这些操作在SQL中是非常简单的统计，但在海量数据、低延迟的要求下，并不是那么容易做的。
ElasticSearch本来就是做实时搜索的，过滤自然不是问题，现在也支持各种聚合以及Pipeline aggregations（相当于SQL子查询的功能），而且ElasticSearch的安装部署也非常简单，一个节点只有一个服务进程，关于安装配置可参考：
本文以两个业务场景的例子，看一下ElasticSearch是如何满足我们的需求的。
例子1：网站流量报告
在我们的报表平台有这样一张报表，用于查看每个网站每天的流量指标：
其中，维度有：天、小时、网站，指标有： PV 、UV 、访问次数、跳出率、平均停留时间、回访率等。另外， 还有一张报表是地域报告，维度多了省份和城市，指标一样。目前的做法是将可选的维度组合及对应的指标先在Hive中分析好，再将结果同步至MySQL，供报表展现。
真正意义上的OLAP做法，我是这样做的：在Hive分析好一张最细粒度为visit_id（session_id）的事实表，字段及数据如下：
然后将这张事实表的数据加载到ElasticSearch中的logs2/sitelog1211中。查看数据：
curl -XGET 'http://localhost:9200/logs2/sitelog1211/_search?pretty'
&took& : 1015,
&timed_out& : false,
&_shards& : {
&total& : 10,
&successful& : 10,
&failed& : 0
&hits& : {
&total& : 3356328,
&max_score& : 1.0,
&hits& : [ {
&_index& : &logs2&,
&_type& : &sitelog1211&,
&_id& : &AVGkoWowd8ibEMoyOhve&,
&_score& : 1.0,
&_source&:{&cookieid& : &8F97E0F6945A&,&siteid& : &633&,&visit_id& : &feaa25e6--b7ed-6fa45f11ff42&,&pv& : 2,&is_return_cookie& : 0,
&is_bounce_visit& : 0,&visit_stay_times& : 34,&visit_view_page_cnt& : 2, &region& : &浙江&,&city& : &绍兴&}
该天事实表中总记录数为 3356328 。
接着使用下面的查询，完成了上图中网站ID为1127，日期为的流量报告：
curl -XGET 'http://localhost:9200/logs2/sitelog1211/_search?search_type=count&q=siteid:1127&pretty' -d '
&size&: 0,
&aggs& : {
&pv& : {&sum& : { &field& : &pv& } },
&uv& : {&cardinality& : {&field& : &cookieid& ,&precision_threshold&: 40000}},
&return_uv& : {
&filter& : {&term& : {&is_return_cookie& : 1}},
&aggs& : {
&total_return_uv& : {&cardinality& : {&field& : &cookieid& ,&precision_threshold&: 40000}}
&visits& : {&cardinality& : {&field& : &visit_id& ,&precision_threshold&: 40000}},
&total_stay_times& : {&sum& : { &field& : &visit_stay_times& }},
&bounce_visits& : {
&filter& : {&term& : {&is_bounce_visit& : 1}},
&aggs& : {
&total_bounce_visits& : {&cardinality& : {&field& : &visit_id& ,&precision_threshold&: 40000}}
基本上1~2秒就可以返回结果：
&took& : 1887,
&timed_out& : false,
&_shards& : {
&total& : 10,
&successful& : 10,
&failed& : 0
&hits& : {
&total& : 5888,
&max_score& : 0.0,
&hits& : [ ]
&aggregations& : {
&value& : 5859
&visits& : {
&value& : 5889
&return_uv& : {
&doc_count& : 122,
&total_return_uv& : {
&value& : 119
&bounce_visits& : {
&doc_count& : 5177,
&total_bounce_visits& : {
&value& : 5177
&value& : 10820.0
&total_stay_times& : {
接着是地域报告中维度为省份的指标统计，查询语句为：
curl -XGET 'http://localhost:9200/logs2/sitelog1211/_search?search_type=count&q=siteid:1127&pretty' -d '
&size&: 0,
&aggs& : {
&area_count& : {
&terms& : {&field& : &region&,&order& : { &pv& : &desc& }},
&aggs& : {
&pv& : {&sum& : { &field& : &pv& } },
&uv& : {&cardinality& : {&field& : &cookieid& ,&precision_threshold&: 40000}},
&return_uv& : {
&filter& : {&term& : {&is_return_cookie& : 1}},
&aggs& : {
&total_return_uv& : {&cardinality& : {&field& : &cookieid& ,&precision_threshold&: 40000}}
&visits& : {&cardinality& : {&field& : &visit_id& ,&precision_threshold&: 40000}},
&total_stay_times& : {&sum& : { &field& : &visit_stay_times& }},
&bounce_visits& : {
&filter& : {&term& : {&is_bounce_visit& : 1}},
&aggs& : {
&total_bounce_visits& : {&cardinality& : {&field& : &visit_id& ,&precision_threshold&: 40000}}
因为要根据省份分组，比之前的查询慢一点，但也是秒级返回：
&took& : 4349,
&timed_out& : false,
&_shards& : {
&total& : 10,
&successful& : 10,
&failed& : 0
&hits& : {
&total& : 5888,
&max_score& : 0.0,
&hits& : [ ]
&aggregations& : {
&area_count& : {
&doc_count_error_upper_bound& : 0,
&sum_other_doc_count& : 2456,
&buckets& : [ {
&key& : &北京&,
&doc_count& : 573,
&value& : 568
&visits& : {
&value& : 573
&return_uv& : {
&doc_count& : 9,
&total_return_uv& : {
&value& : 8
&bounce_visits& : {
&doc_count& : 499,
&total_bounce_visits& : {
&value& : 499
&value& : 986.0
&total_stay_times& : {
&value& : 24849.0
&key& : &山东&,
&doc_count& : 368,
&value& : 366
&visits& : {
&value& : 368
&return_uv& : {
&doc_count& : 9,
&total_return_uv& : {
&value& : 9
&bounce_visits& : {
&doc_count& : 288,
&total_bounce_visits& : {
&value& : 288
&value& : 956.0
&total_stay_times& : {
&value& : 30266.0
这里需要说明一下，在ElasticSearch中，对于去重计数（COUNT DISTINCT）是基于计数估计（ Cardinality ），因此如果去重记录数比较大（超过40000），便可能会有误差，误差范围是0~2%。
例子2：用户标签的搜索统计
有一张数据表，存储了每个用户ID对应的标签，同样加载到ElasticSearch中，数据格式如下：
curl -XGET 'http://localhost:9200/lxw1234/user_tags/_search?&pretty'
&took& : 220,
&timed_out& : false,
&_shards& : {
&total& : 10,
&successful& : 10,
&failed& : 0
&hits& : {
&total& : 820165,
&max_score& : 1.0,
&hits& : [ {
&_index& : &lxw1234&,
&_type& : &user_tags&,
&_id& : &222&,
&_score& : 1.0,
&_source&:{&sex& : &女性&,&age& : &27到30岁&,&income& : &&,&edu& : &本科&,
&appcategory& : &娱乐类|1.0&,&interest& : &&,&onlinetime& : &9:00~12:00|1.0&,&os& : &IOS|1.0&,
&hobby& : &游戏|28.57,房产|8.57,服饰鞋帽箱包|28.57,互联网/电子产品|5.71,家居|8.57,餐饮美食|5.71,体育运动|14.29&,&region& : &河南省&}
每个用户都有性别、年龄、收入、教育程度、兴趣、地域等标签，其中使用_id来存储用户ID，也是主键。
查询1：SELECT count(1) FROM user_tags WHERE sex = ‘女性’ AND appcategory LIKE ‘%游戏类%';
curl -XGET 'http://localhost:9200/lxw1234/user_tags/_count?pretty' -d '
&filter& : {
{&term& : {&sex& : &女性&}},
{&match_phrase& : {&appcategory& : &游戏类&}}
返回结果：
&count& : 106977,
&_shards& : {
&total& : 10,
&successful& : 10,
&failed& : 0
查询2：先筛选，再分组统计：
SELECT edu,COUNT(1) AS cnt
FROM user_tags
WHERE sex = '女性'
AND appcategory LIKE '%游戏类%'
GROUP BY edu
ORDER BY cnt DESC
查询语句：
curl -XGET 'http://localhost:9200/lxw1234/user_tags/_search?search_type=count&pretty' -d '
&filter& : {
{&term& : {&sex& : &女性&}},
{&match_phrase& : {&appcategory& : &游戏类&}}
&aggs& : {
&edu_count& : {
&terms& : {
&field& : &edu&,
&size& : 10
返回结果：
&took& : 479,
&timed_out& : false,
&_shards& : {
&total& : 10,
&successful& : 10,
&failed& : 0
&hits& : {
&total& : 106977,
&max_score& : 0.0,
&hits& : [ ]
&aggregations& : {
&edu_count& : {
&doc_count_error_upper_bound& : 0,
&sum_other_doc_count& : 0,
&buckets& : [ {
&key& : &本科&,
&doc_count& : 802670
&key& : &硕士研究生&,
&doc_count& : 16032
&key& : &专科&,
&doc_count& : 1433
&key& : &博士研究生&,
&doc_count& : 25
&key& : &初中及以下&,
&doc_count& : 4
&key& : &中专/高中&,
&doc_count& : 1
从目前的调研结果来看，ElasticSearch没有让人失望，部署简单，数据加载方便，聚合功能完备，查询速度快，目前完全可以满足我们的实时搜索、统计和OLAP需求，甚至可以作为NOSQL来使用，接下来再做更深入的测试。另外，还有一个开源的SQL for ElasticSearch的框架Crate（crate.io），是在ElasticSearch之上封装了SQL接口，使得查询统计更加方便，不过SQL支持的功能有限，使用的ElasticSearch版本较低，后面试用一下再看。
您可以关注lxw的大数据田地 ，或者
，随时接收博客更新的通知邮件。
转载请注明：lxw的大数据田地 &
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致ElasticSearch 导入数据的一个坑，肯定不止我一人中招
· Ruby China
今天使用 ES 时，碰到一个坑，估计其他同学或许也会碰到，特此分享一下。
step 1 Model
BetOrder 是一个订单的 model，搜索时我打算使用 term query。我把 mapping 设置为
index: 'not_analyzer' ，故意不分词，以便精确搜索。
Gem 用的是
# model/bet_order.rb
# Set up index configuration and mapping
# Searching tokens exactly
settings do
mappings do
indexes :title,
index: 'not_analyzed'
indexes :nickname,
index: 'not_analyzed'
indexes :user_key,
index: 'not_analyzed'
indexes :out_trade_no, index: 'not_analyzed'
indexes :trade_no,
index: 'not_analyzed'
indexes :buyer_email,
index: 'not_analyzed'
step 2 导入数据
BetOrder.import
step3 悲剧了，导入数据后 mapping 不对
然后是debug 呀，debug。。。。。
翻来覆去的找，没找到原因，最后去翻了翻 elasticsearch-rails 的源码，原来导入数据的时候需要加上参数 force: true,才会根据 mapping 创建索引。
BetOrder.import force:true
源码地址：
问题解决，上一个正常 mapping
顺便请教一个问题：为什么第一次 import 数据时，作者不根据 model 中定义的 mapping 创建。这算不算一个bug？
昨天也遇到这个, 这应该算是文档没写清楚吧 , 我学得按照model定义创建 mapping。另外，想请教下有没有用中文分词，用的哪个？谢谢
可以先BetOrder.__elasticsearch__.create_index!来创建索引，这个时候会按照map来配置。然后可以index各个document。
直接导入没有具体测试，确定import前没有建立index mapping哦。
model里面我是直接用
mapping do
settings do
mappings do
不知具体什么区别？
我测过了，直接 import 时创建的 mapping 是错误的。
中文分词我用的 mmseg_analyzer，效果还不错。
分词以前一直用mmseg，从sphinx到es。不过最近代码里面产品只需要sql like的程度就够，还没有去配置分词。
这个问题之前我也遇到过，还是得读源码。另外使用ik进行处理性能不高，会出现HTTP timeout。后来换成mmseg了。
问下，mapping时比如标签列表tags: [''abc','def']去存储，
当index not_analyzed时候，可以用filter查询查找到
当默认string analyzed时候，可以query match来，这个时候用filter搜索不到
如何让他可以filter又可以在搜索时候被match到，是怎么mapping的
我也被坑了，3q
后方可回复, 如果你还没有账号请点击这里 。
共收到 8 条回复<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&用elasticsearch和kibana 进行简单的实时数据报表分析
用elasticsearch和kibana 进行简单的实时数据报表分析
& & &elasticsearch公司已经渐渐把ES变成为实时分析的工具，相比solr，es在实用产品化上确实领先很多。ES公司主推的ELK套件就是完成实时日志分析的完整解决方案，其中的kibana是一个简易报表工具，完全针对es进行开发，同类型产品几乎没有竞争者；logstash是日志拉取采集的工具，有很多同类产品，比如flume,
ELK的配置安装网上有挺多资料了，我在这并不想介绍如何部署这套工具，而是讲讲在使用elasticsearch&#43;kibana的心得。由于日志类型数据也是个跟业务有关系的事，所以未必需要使用logstash。 当然它的功能完整，也可以学习它的配置进行数据采集，但我估计很多时候也可以自己修改已有采集工具，甚至使用storm进行数据传输。
elasticsearch
elasticsearch是一个基于lucene全文检索引擎，索引采用倒排方式。由于不用索引缺失字段，加上追加式增加记录，因此数据建倒排据时性能很强，另外查询时候是进行倒排链的交集并集计算，也是非常高效。因此除了传统信息检索领域，我认为这也是ES能用来实时日志统计的原因。报表数据的生成就是一次单表级常规的查询后，进行count或者简单的聚合；当然这里的查询也不支持表关联这么复杂的。
ES的功能配置不少，很多功能需要按需现查手册。ES本身是schema-free的，不建index也能存进数据，只是字段处理方式都默认了而已。但为了方便kibana展示，以及性能存储优化，需要关注一下index结构的设计。由于kibana推荐数据日存，所以在es这端建议用template来配置mapping。例如这个
&template&: &log-*&,
&settings& : {
&number_of_shards& : 1,
&number_of_replicas& : 0
&mappings&: {
&_all&: { &enabled&: false },
&dynamic_templates&: [
&string_template& : {
&match& : &*&,
&mapping&: { &type&: &string&, &index&: &not_analyzed& },
&match_mapping_type& : &string&
&properties& : {
&message& : { &type& : &string&, &index& : &analyzed& },
&@timestamp& : { &type& : &date&, &index& : &not_analyzed& }
template会识别所有以log-开头的index都使用这套mapping, dynamic_templates是对不同字段进行特殊处理。
最好设置一个date类型字段，报表多半需要一些按时间进行的展示；string类型只能做count,
如果要做sum avg等计算需要用number类型；目前Kibana还提供了经纬数据展示，你需要geo_point类型得以支持。
数据采集的方式很多，logstash就是做这个的，和大多数工具一样，他们兼顾转发和收集的功能，但Logstash有个好处是解析过程也是可以配置，你需要去研究一下用法。
自己写代码提交到es也可以，可以用es客户端，或者http提交json，如果是批量提交需要用bulk接口， 如果是批量索引，每个doc完成以后还要多空一行，否则可能只能索引到头一个。
kibana目前出到4了，提供了完整的web服务，不像3那样还要部署到容器。4代的报表功能拆分得更细。
首先需要在setting界面设置读取的index, 前缀&#43;* 匹配所有，如果index里没有数据也不能匹配上。
discover界面可以搜索数据，选择展示的字段。
visualize界面是设置展示效果的，目前支持饼图、柱状图、线图、报表等多种：Y轴设置统计&#20540;，可设置一到多个Y轴。 X轴设置数据划分方法，还可以对X进行组合，各种指标需要亲自摸索才能做出好看的效果。
配置好discover和visualize之后记得保存，用来组合生成dashboard，到这里一个简易的报表界面就完成了。
开始玩的时候，发现kibana找不到数据，不知道是哪弄错了，把时间范围扩大才查到，才知道遇到的问题，本来打算跟着改kibana的配置，好像没成功，最后还是把时间增加了时区：&T10:01:02&#43;08:00&，
所以我建议采集部分要自己处理。
elasticsearch&#43;kibana能帮助你轻松完成一个实时日志报表的功能。这两个工具都是只需要修改配置便可以直接启动，部署非常便捷，es还可以下head和kopf插件来管理。你只需要关注如何根据自己业务进行合适的数据&#26684;式设计和数据采集。
我的热门文章
即使是一小步也想与你分享后使用快捷导航没有帐号？
查看: 1230|回复: 15
Elasticsearch 能够存储的数据量一般有多大？
金牌会员, 积分 1605, 距离下一级还需 1395 积分
论坛徽章:8
Elasticsearch 能够存储的数据量一般有多大？
金牌会员, 积分 1605, 距离下一级还需 1395 积分
论坛徽章:8
自己先灌水，为了万恶的作业
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
看集群了 我们单位集群20台& &每天数据1亿多条 每条处理18s
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
忘了补充一句 每条记录都是几百k
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
所以其实主要是你集群的大小 和整个集群的配置和优化&&原来我们用mongo现在准备用es
金牌会员, 积分 1771, 距离下一级还需 1229 积分
论坛徽章:16
兄弟，分布式存储，你想存多少就存多少，关键在于你的shards分配是不是
金牌会员, 积分 1771, 距离下一级还需 1229 积分
论坛徽章:16
兄弟，分布式存储，你想存多少就存多少，关键在于你的shards分配是不是
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
注册会员, 积分 187, 距离下一级还需 13 积分
论坛徽章:10
能存多少数据根据应用来看吧，如果服务器资源足够的情况下存几十T上百T都不是问题
注册会员, 积分 150, 距离下一级还需 50 积分
论坛徽章:5
估计至少图片G的量 分布式的 达到PB级
高级会员, 积分 624, 距离下一级还需 376 积分
论坛徽章:4
@齐慧强，看集群了 我们单位集群20台& &每天数据1亿多条 每条处理18s。
这个速度怎么这样慢啊，按道理一般查询速度在3秒之内才可以接受啊。你们是查询什么样的数据了。
扫一扫加入本版微信群}