亚马逊云BI产品QuickSight 深度解析

亚马逊的云BI服务QuickSight，旨在让他们的企业用户更加便捷、快速低成本的分析数据。在这款直接面向企业商业决策人员的工具发布之前，AWS上已经拥有了一整套大数据的解决方案——开发了数据从采集、存储到分析的全部工具，不仅有离线计算方案，也有流数据处理方案。

其大数据服务的整体架构如下：

数据采集（Collect）方面：AWS Direct Connect / AWS Import/Export / Amzon Kinesis

数据存储（Store）方面：Amazon S3 / Amazon RDS/Aurora / Amazon Glacier / Amazon DynamoDB / Amazon CloudSearch / Amazon Elasticsearch

数据分析（Analyze）方面：Amazon EMR / Amazon EC2 / Amazon Redshift / Amazon Machine / Amazon kinesis Analytics

这些服务能够解决企业大数据分析中的大部分问题：

Amazon RDS 解决管理数据库的困难与苦楚；

Amazon DynamoDB 解决SQL类数据库在大数据量下性能的问题；

Amazon EMR 解决Hadoop集群部署和管理的难题；

Amazon Redshif 大幅降低了数据仓库部署和使用的复杂度、减少了花费而且提升了效率；

Amazon Aurora 让用户可以低成本的享受拥有商用数据速度和可用性的数据库产品；

Amazon Kinesis 让实时数据的捕捉与分析变得不再困难。

应该说，亚马逊的AWS的大数据服务已经是非常的齐全，生态也很完善。那么这个时候推出Amazon QuickSight，是出于什么样的目的呢？

数据的采集和生产最终是为了决策

提到数据分析和可视化的BI工具，很多朋友可能会想到对用户非常友好的Tableau和QlikView。这两款产品直接面向决策段用户，让不懂底层数据逻辑，没有任何代码基础的用户，可以高效的用大数据分析业务，做出商业决策。它们解决了大数据的“最后一公里”问题——结果数据的整理、可视化和Insight共享。

大家可以再回头去看看刚才我列举的AWS的大数据服务，就会发现，现有的所有服务全部在数据采集、存储和计算端——均为工程师们处理海量数据提供服务的。然而这些都让数据变成成本，我的数据越多，我需要花费的钱越多。那么如何让数据产生价值呢？数据产生自业务，自然也得回归业务、驱动业务创造价值，从成本转变为生产资料，这才是产生数据、挖掘数据的唯一目标。

之前很多企业内部数据的使用方式一般有这几种：

1.产品/运营/市场将需求提给数据分析师/数据分析工程师/数据挖掘工程师/ETL工程师——统称人肉SQL手，由这些熟练操作数据库的人员完成数据的提取工作，之后结果数据反馈回业务方，业务方再对数据进行整理、制表、绘图并分析产生Bussiness Insight。

2.产品/运营/市场将需求提给公司的数据平台/数据中心，数据平台/数据中心的接口人/数据产品经理将需求统一整理和拆分，制作成固定的报表，定期发送邮件或者展示到前端中，供大家日常查询和使用。临时需求？请抽象成报表需求，否则请排期，谢谢合作！

3.产品/运营/市场将需求自己消化，实践人人都是数据分析师的伟大理念。人人都有Hive或者MySQL权限，人人都是SQL小能手，自力更生，丰衣足食。

这些方法，都可以生产数据进行决策，但是各有利弊：

第一种方式会产生大量的冗余需求，降低决策效率。实际工作情况中，特别是业务比较复杂、产品线较多的公司，因为业务人员对数据不清楚，SQL工程师对业务不了解，双方的信息差会让整体的数据提取效率变得非常低。在这种情况下，提需求的成本非常低——转脑袋的速度可比跑SQL的速度要快上许多。结果就是需求冗余，产生Insight的周期通常以天，周甚至月来计算。

第二种方式在产品初期有很好的效果，但是到产品中后期进入精细化运营的时候，效率就会急速下降。后期，大量的报表冗余，无人使用，却每天消耗服务器资源。在数据平台/数据中心的组织架构下，临时需求的解决流程长、速度慢，导致决策效率低下。业务方出于无奈，只能通过不断建报表的方式，满足自己的临时需求。

第三种方式非常适合创业型公司，但是不适合高速成长和大型公司。有产品设计能力同时有商业Sence，不仅能做日常决策，还能自己从数据库直接提取数据来辅助自己做决策——这种人才请联系我！这种人很难规模化的培养和招聘，而且在知识继承上非常的低效。导致公司在快速成长和精细化运营阶段，因为需要做决策的地方过多，而产生大量的精英人力浪费，最终拖累整个公司的决策效率和发展速度。

于是QuickSight应运而生。

Quicksight是整个AWS生态中离商业决策最近的服务，直接解决大数据应用的“最后一公里”问题。其在整个生态中的定位如下：

它不需要用户有代码能力，自动识别和整合各种不同的数据源，提供实时交互式的数据查询方式，并且自动进行数据可视化。最大程度降低了商业决策端用户使用大数据的成本，也有望解决业务方和数据中心方一直存在矛盾。

作为一项服务，QuickSight并不是传统的产品形态。它将数据作为一项服务，交付给使用方，使用方可以按需使用。这与提供整个解决方案的整合型产品完全不同，成本低、使用方便，而这也是云服务的特点和优势。

整个QuickSight服务分为QuickSight API和QuickSight UI两个部分——前者负责数据的连接、准备、转化和计算的工作，后者负责用户端的数据可视化与决策分享。与传统BI的内部循环不同，QuickSight的数据连接、准备、转化和计算的服务不仅可以连接AWS体系内的数据系统，也可以通过JDBC、Oauth等方式连接其他的数据源。在数据输出方面，除了QuickSight自带的UI进行可视化与分析之外，还可以连接Tableau、DOMO、TIBC与QlickView等数据分析和可视化产品，非常灵活。

官方给出的整体框架如下：

这些API中，Connectors，Data Prep和SPICE是核心。Connectors能够自动识别不同数据源并进行连接；Data Prep能够快速的将不同数据源的数据高效的准备好；SPICE则是一个基于内存的数据查询引擎，提供实时交互式的快速查询能力。

亚马逊官方对其的总结和描述如下：QuickSight是一个高效的、易用的、低成本的和基于云的商业决策服务。它可以让毫无代码基础的用户方便的进行可视化和高效的Ad-hoc查询功能进行数据分析，从海量数据快速获取商业决策。QuickSigh完美整合了AWS的数据存储系统、单独的数据文件和第三方数据源，同时能够在海量数据，高并发查询的情况下快速的得出分析结果。

下面我将会对QuickSight API和QuickSight UI的体验进行详细解读。

产品整体分为三个部分：

数据源整合工具Connector和Data Prep

基于内存的快速分析引擎SPICE

可视化工具QuickSight UI

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!