有了Tableau,为什么AWS还要做BI?

作者:刘洋
来源:https://zhuanlan.zhihu.com/p/24205976


今年十月,亚马逊发布了一个全新的云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生态中离商业决策最近的服务,直接解决大数据应用的“最后一公里”问题。其在整个生态中的定位如下:

有了Tableau,为什么AWS还要做BI?

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


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


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


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

有了Tableau,为什么AWS还要做BI?


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


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


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


产品整体分为三个部分:


  • 数据源整合工具Connector和Data Prep

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

  • 可视化工具QuickSight UI

有了Tableau,为什么AWS还要做BI?

数据整合方面:Connector 和 Data Prep


Connector毫无悬念的提供了与自己云服务中的数据无缝对接的功能。同时提供直接上传文件以及连接第三方数据应用方的数据,比如Salesforce、Google Analytics等。不过从之前体验PowerBI的第三方的数据连接功能来看,这类工具比较鸡肋——一个是连接很容易出错,其次是第三方应用的数据只有部分可以接入,第三数据更新也是个大问题。


数据分析中难度最大、最耗费资源的地方在于数据源的整合、数据的清洗与更新以及元数据管理,而QuickSIght使用自有体系内的数据可控性高,管理成本低,因此,如果没有使用亚马逊的服务,它后面提供的那些“炫酷”的能力,也许就只是镜中水月了。


Data Prep提供数据预处理能力:


  • 提供数据在内联变化(In-line transformation)和类型强制转换(type coercions)之后的数据预览;

  • 提供对字符串、日期、数字和运算逻辑的处理能力;

  • 数据处理的每一步规则都可以保存为模版,以便重复操作;

  • 支持Join、Filters、Hierarchies以及Attribute/Measures的操作;

  • 直接对接S3文件。


这里的Data Prep,我理解上类似于一个ETL的过程,不过这个过程被模块化、可视化,让我想起了Tableau的数据连接过程。


数据分析方面:提供SPICE快速分析引擎


SPICE全称是Supre-fast, Parallel, In-memmory optimized, Calculation Engine ——超快的、并行的、基于内存优化的计算引擎。


  • 2-4倍压缩列数据;

  • Compiled queries with machine code generation(不会翻译。。。);

  • Rich calculations(不会翻译。。。);

  • 类SQL查询语法;

  • 查询速度非常快;

  • 全部自有产权,不需要担心任何软件或者硬件的授权问题(只能编辑喝管理,并不开源)。


可视化工具QuickSight UI


QuickSight UI提供了一个类Tableau的可视化界面,从Demo中看,对用户非常友好。为了让用户能快速对结果数据进行可视化,它提供了一个AutoGraph的自动绘图功能。


AutoGraph能够自动识别数据类型——这里面Connector和Data Prep的功劳可能更大一些。借助SPICE的快速分析能力,它能快速的根据推荐的图表把结果数据算完,然后根据数据类型进行展示。用户还可以根据计算结果,快速的切换图表类型——从柱状图切到折线图等。

有了Tableau,为什么AWS还要做BI?


笔者没有体验过QuickSight UI的AutoGraph功能,但是接触过Tableau和Power BI的Suggestion功能。目前的产品,在简单的二维数据战线上表现不错,但是一旦维度变多,推荐出来的图表还是比较奇怪。如果绘图速度不是特别的快,还不如自己直接做。


总体来看,AutoGraph是一个把QuickSight的数据源处理和分析引擎进行了再包装的一个可视化产品,我觉得这个产品能够让看不见的数据处理部分让用户可以直观的感受到,是一个比较不错的特点。


为了迎合移动办公的趋势,QuickSight提供了iOS、Android双平台的Native应用。同其他的阉割版移动端不同,亚马逊宣称移动端和PC端拥有一样的体验(你想知道阉割版的话,可以去试试GA和Tableau的移动端)。


在团队协作方面,QuickSight提供了一个可编辑的Dashboard功能,允许用户直接将分析结果、截图,甚至是整个分析逻辑分享给同事,让同事不仅能够看到静态的保镖,还能看到动态的数据视图。

有了Tableau,为什么AWS还要做BI?
如想加入《数据产品经理会》群,请加 刘洋 微信:liuyangfjnu ,或直接微信关注【数据产品经理会】公众号。
上一篇:如何快速搭建一个数据分析平台?


下一篇:美妆视频小红唇如何打开大数据之门