Elasticsearch vs. Hadoop For Advanced Analytics

A Tale of Two Platforms Elasticsearch 是卓越的文档索引以及全文检索工具。其基于JSON的DSL(Domain Specific query Language)简单而又强大(我觉得比SQL还差得远,好在近期新的版本发布了Elastic SQL :),使得其成为web app中集成搜索引擎的事实上的标准。那么作为analytics 后端是否胜任呢? 我们是否真的找到了一个“Hadoop”杀手呢? 首先来回忆一下一个高级“分析”系统一般都是如何构建的。开始的时候,你的app可能只需要像“mixpanel”或者“Google Analytics”这样的功能就够了,随着系统发展,产品经理的问题变得越来越难以回答: “What's the completion rate for femail Chinese users in my newly defined cohort X through the revamped user action funnel Y?” 这一问题需要cohort X的用户数据被摄取、标记出来后,再执行自定义查询来回答。为解答此问题,你需要开始收集访问日志数据,构建一个完全的“分析流水线”。经过一番调研后你会发现,有不少已有的解决方案是构建于Hadoop基础之上的,但是越来越多的开发者开始考虑使用Elasticsearch来做这件事情。怎么会这样的?一个搜索引擎真的会适合“分析”工作么? Elasticsearch For Analytics Elastic的ELK分析套件,包括Logstash(负责搜集服务器端日志)、Kibana(可视化窗口)在web分析应用中,得到了很多应用,因为: 1. 首先你非常容易运行起一个Elasticsearch实例 2. Elasticsearch 基于JSON的查询语言比Hadoop的MapReduce要容易操作的多 3. 对于应用开发者,Elasticsearch是工具箱中的一个已有工具,而Hadoop套件可能需要他们去全新的学习 这些原因,导致那些需要快速启动、运行分析需求解决方案的,会更倾向于选择Elasticsearch。但是一个搜索引擎,用他们执行“数据摄取”、数据分析工作,比起像Hadoop这样的具备高度扩展能力的分布式数据处理平台,其表现如何呢? Streaming Ingestion(流式数据摄取) 很多团队,会被Elasticsearch

DPA 试用版

授权说明(License Rights and Restrictions) www.skyatlas.net授予您内部使用本程序的非排他性,不可转让的有限许可,受本协议中规定的限制,仅用于开发,测试,原型设计和演示您的应用程序,且仅限于您的应用程序尚未用于任何数据处理,业务,商业或生产目的,也不用于任何其他目的。您可以允许您的承包商使用本程序,前提是他们代表您行使本协议中授予的许可权利,并进一步规定您有责任在此类使用中遵守本协议。您将与您的承包商签订书面协议,严格限制其使用本程序的权利,并以与本协议相同的程度保护Skyatlas的知识产权。您可以在合理需要的范围内制作本程序的副本,以行使本协议中授予的许可权利。您可以制作一份程序副本以进行备份。 此外,您不可以: 删除或修改任何程序标记或任何Skyatlas或许可方所有权的通知;以任何方式向任何第三方提供本程序(除本协议中规定的代表您的承包商外);使用程序提供第三方培训;转让本协议或分发,给予或转让本程序或其中的权益给任何第三方,除非本承包商协议明确允许(上述内容不得解释为限制您可能另行拥有的权利)持牌第三方技术);导致或允许逆向工程(除非法律要求互操作性),程序的反汇编或反编译;和在未经Skyatlas事先同意的情况下披露任何计划基准测试的结果。本程序可能包含源代码,除非本协议中出于其他目的明确许可(例如,根据开源许可证授权),否则仅为参考目的提供源代码,并且不得修改。 Skyatlas保留本协议未明确授予的所有权利。如果您希望将本程序或您的应用程序用于本协议明确许可之外的任何其他目的,您必须根据允许此类使用的单独协议从Skyatlas或Skyatlas经销商处获得有效的程序许可。但是,您承认本程序可能不适合生产使用和/或Skyatlas可能不会将本程序的版本用于生产或其他目的;您使用本程序进行的任何开发或其他工作均由您自行承担风险。 所有权skyatlas或其许可方保留本计划的所有权和知识产权。 第三方技术本程序可能包含或要求使用随程序提供的第三方技术。 Skyatlas可能会在程序文档,自述文件或与此类第三方技术相关的通知文件中向您提供某些通知。第三方技术将根据本协议的条款许可给您,或者,如果在程序文档中指定,则根据单独条款向您发送自述文件或通知文件。您根据单独条款使用单独许可的第三方技术的权利不受本协议的任何限制。但是,为清楚起见,尽管存在通知,但未经单独许可的第三方技术的第三方技术应被视为本程序的一部分,并根据本协议的条款许可给您。 如果同意上述协议,您可以下载DPA 试用版本软件。如有商业使用需求,请联系skyatlas.net.link:Database Performance Analyzer for Oracle.

The Future of Data Management Solutions is Autonomous

分析市场(Analytics )的数据管理解决方案随着云的地位的巩固而不断发展,Hadoop的使用案例得到澄清,逻辑数据仓库的采用不断扩大,中国供应商(aliyun,腾讯)向国外拓展。在这种动态背景下,本报告将帮助您找到适合您业务的合适供应商。 市场定义/描述 我们将分析数据管理解决方案(DMSA)定义为支持和管理一个或多个文件管理系统(通常是数据库)中的数据的完整软件系统。 DMSA包含特定的优化以支持分析处理。这包括但不限于支持关系模型处理,非关系型处理(如图形处理)以及机器学习和编程语言(如Python和R)。数据不一定存储在关系结构中,并且可以有多个模型使用 - 例如关系,XML,JSON,键值,文本,图形和地理空间。 虽然传统的数据仓库用例仍然是大多数组织的分析计划的基础,但他们也有兴趣管理和处理日益多样化的内部和外部数据格式。因此,完整的DMSA必须能够适应多种数据类型。这些可能包括交互和观测数据 - 例如物联网(IoT)传感器 - 以及非关系数据,如文本,图像,音频和视频数据。 相关角色和技能的广度和范围也在不断扩大,因为组织正在参与新的使用案例,这些案例可以更全面地了解来自越来越多来源的数据。 我们定义了DMSA的四个主要用例,它们反映了数据和用例的多样性(另请参见注释1): 传统的数据仓库 实时数据仓库 与上下文无关的数据仓库 逻辑数据仓库(LDW) 我们的定义还指出: • DMSA不是特定的类别或类型的技术。 • DMSA可以由许多不同的技术组合而成。但是,任何产品或服务组合的核心都必须能够通过开放式访问工具通过标准API(如开放数据库连接(ODBC),Java数据库连接(JDBC),代表性状态传输( REST)和对象链接和嵌入数据库(OLEDB)访问。 • DMSA必须为独立的前端应用程序软件提供数据可用性,包括隔离工作负载需求的机制以及在受管数据实例中控制最终用户访问的各种参数。 • DMSA必须对其正在使用的数据进行管理控制。这意味着它必须控制数据如何被持久,访问,管理和保护。 • DMSA有许多不同的交付模式,例如独立DBMS软件,认证配置或参考体系结构,数据库平台即服务(dbPaaS)产品和数据仓库设备。这些是在我们对每个供应商的分析中一起评估的。 魔力象限:  供应商的优势和注意事项  Actian 总部位于美国加利福尼亚州帕洛阿尔托市的Actian为分析工作负载提供Actian Vector分析平台,Actian Vector in Hadoop,Actium X提供用于联合操作和分析处理。 Actian Vector分析平台还可以通过自带许可证模式或通过亚马逊机器映像(AMI)部署在亚马逊网络服务(AWS)和Microsoft Azure上,以实现社区支持的免费版本。 优势 • 对DMSA的再投资:由于战略和路线图的变化,Actian没有出现在魔力象限的2017年版本中。但是,在引入新的领导力后,现在正在重新投资Vector技术以满足分析需求。 • 性能:Actian Vector是一个面向列的内存DBMS,它使用矢量处理来执行查询。参考客户对该技术的性能表示赞赏。 • 物有所值:许多参考客户都称赞Actian的性价比。在我们的参考客户调查中,Actian比其他类别的价值更高。 注意事项 • 云支持:Actian尚未提供强大的云平台即服务(PaaS),即使云正在快速成为标准部署选项。这限制了Actian解决潜在客户群的能力。然而,Actian最近发布的AMI社区版以及计划在2018年为多种云平台上的Vector提供完全托管的企业PaaS选项的计划应该能够满足这种需求。

DPA在电信计费系统故障诊断案例

3月20日中午,电信客户的计费系统故障,所有操作响应缓慢,应用无法正常运行。现场DBA已经迅速将应用连接转移到RAC集群的另一节点,恢复应用服务,我们使用DPA来回看事故现场,此时离故障发生,已经一小时了…… 回溯负载情况,如下图   问题最严重时,实例堵塞了近700个连接操作…针对此时间段,进一步点击、下钻分析当时系统发生了什么 系统先是每分钟4~5次堵塞(像是咳嗽),到了13:40后,就处于长时间“梗”住的状态,对于外部业务来说,数据库实例已不可用了。   利用DPA,继续下钻,查看堵塞原因: 1654#会话导致80个会话被堵塞,这80个会话的等待事件是 sga:allocation forcing component growth,这80个会话中的一些会话又堵塞了一些其他会话,如下图 266号会话堵塞了3个会话,这三个会话的等待事件都是cursor:pin s wait on x,这个等待事件一般都是跟sql parse相关,所以,现场工程师开始查看oracle 自己的ADDM报告,说是解析有问题,建议应用分析解决问题…被误导了   至此,DPA下钻后清晰显示,堵塞的根源是1654号会话,DPA显示是MMAN进程,它堵塞了80个会话,这些会话又堵塞了更多其他会话,是一个3级的堵塞关系,幸好DPA以“树型”显示方式,把这种多层级堵塞关系显示的非常清晰。 结论:Oracle MMAN进程进行过于频繁的SGA内存组件(本例中是share pool)resize操作,导致了问题…   这张图中显示的share pool内部情况,看官能看出异常么?   “划一条线1美元,知道在哪里划线9999美元”。 至此,后续我们如何解决这个问题的就不再讨论了,解决问题从来不是难事,难的是发现问题。 后记: 从DPA的负载雷达上,我们看到在系统出现问题之前的一小段时间内,系统负载不正常的降的很低,其后负载飙升上去…… 那段时间负载异常降低,说明了什么? 应用程序发生了什么…… 这些从Database Performance Analyzing层面,就无从知晓了。

REMS在性能诊断、分析场景下的实用

下午4点半,rems2发出cpu负载高的警报——使用率超过50%。不是演习、不是测试,真正的核心系统:两台aix上的一套Oracle 10g RAC。 很明显16:30之后,cpu负载上升,一直到17:00,使用率在50%处波动~ 同时网络流量,内存,交换分区都很平稳: 检查数据库对应时段的指标,逻辑IO明显的高阶运行,激活会话数升到35左右,物理IO与用户调用无对应跳阶: 接下来,很自然的就是Top Session显示,Top SQL分析了~ 很遗憾,咱是生产核心系统,这些都不允许贴出来了😄  好的监控、性能分析工具,随着你的心意、方向,有如低扭强大的机械马达——让你御风而行