基于私有/公有云的数据分析平台实例分析

一、私有云数据分析平台：DAP_1

DAP_1是2010-2012年期间开发的一个基于私有云的可视化数据分析工具。它的出现是基于明确的产品需求的，目标用户是就职于专业数据分析部门的数据科学家（data scientist）。

Datascientist的日常工作内容包括：和客户沟通，了解数据分析需求；获取样本（或全部）数据，清洗、统计、建模，得出insights；生成数据分析报告（一般为数据可视化报告）向客户进行展示。这个过程可以是一次，也可能是多次迭代，总之最后要交付一个观点，数据的运算结果就是支持这种观点的结论。虽然data scientist使用的工具是很广泛的，但就当时而言，我们的目标客户是那些使用SQL在数据库上进行演算的DS。

2010年，大数据方兴未艾，当年的大多数公司还是用数据库存储数据的，而R，Python等语言当年并没有今天这么火热，也没有这几年来那么算法库做支持。鉴于当时的业界环境，DAP_1的设计并非针对大数据，而是针对数据库中存储数据的运算。在这样的需求范围明确下来以后，存储层当然是采用数据库。

但是，当时DAP_1提出了一个databaseprovision的概念¬——让用户通过很简单的操作，就可以创建一个虚拟的数据库，用于存放自己的已有数据和所有新生成数据。这一做法主要是针对data scientist的一个很强烈的需求：他们每天面对的是一大堆“脏”数据(dirtydata)，有迫切的愿望对其进行清洗，但是不同目的的清洗会剔除这些原始数据中不同的部分，所以，需要备份这些数据，在同一个数据库操作不仅麻烦而且还容易出错，另外还无法掌控别人的访问权限，故而需要不断创建新数据库。

控制层的功能主要放在对于用户和资源的管理上，而非数据分析算法。这是因为，目标用户是data scientist，算法这块可以放心的交给用户自己去做。DAP_1对他们提供了SQL接口，允许他们通过写SQLquery来处理数据。而不同data scientist之间共享数据，共同操作某一部分数据，向他人展示他们的结果，恰恰是他们的需求所在。所以，DAP_1的用户管理（权限、角色），资源管理（允许用户建立、参与项目，在项目中创建、暴露数据库等）是重点。

数据展示层，提供了dashboard和多种可视化图表，用户可以通过选择database/table/column创建各种例如柱状图、折线图、热点图之类的，这部分和现在很多的图形化分析工具类似。

整个系统是分布式部署的，不过相较于现在的分布式存储运算系统要简单得多。因为数据量和运算量都相对小，作为web service部署。各个节点独立运行，用户的job是被提交到单个节点，独立完成。分析算法的运算性能由底层数据库性能和用户的SQL脚本优化度决定。

这个系统完成了1.0，作为公司常规产品出售，有客户买去以后安装到自己企业的内部cluster上（私有云），作为内部工具使用。

我个人对它的评价是：目标明确，需求落实充分，但是目标客户群太小，尤其是在这个“大数据”已经逐步成为咒语的时代，没有搭上“大数据”的顺风车，或许会存在一段时间，但无法popular。

二、公有云数据分析平台：DAP_2

DAP_2是继DAP_1之后的产品，开发周期在2012-2014年间。当时，”BigData”在硅谷已经成为热词，并已经开始登陆中国。DAP_2也算是应时而生。和DAP_1完全相反，它是部署在公有云上的，面向小白用户（binary users）的，“大”数据分析平台。

DAP_2的存储层是HDFS/HBase，它需要用户首先导入（import）自己的数据到DAP_2存储中，之后会运行若干算法，自动生成报告，以图形化的方式展示给用户。

在数据导入这部分，它有一个亮点：自动解析用户数据，自动区分dimension 和measure 数据，比如说，用户导入一个csv文件，它可以自动解析出其中的列哪些是数值型的（measure），哪些是非数值型的（dimension），然后针对各个dimension计算各个measure的若干metrics（min，max，count，avg，middle， etc.)，并进行聚合（aggregation）。

换句话说，也就是能够对用户输入数据进行自动的schema提取，用户的数据是很广泛的，可能是database导出的csv，也可能是产品日志这类版结构化数据，甚至是非结构化的。即使是csv，也可能没有header，没有数据类型，或者数据半途变更类型，DAP_2的Parser部分对这些全部能够解析。

这里不得不插一句: 虽然时至今日，Hadoop/Spark的盛行已经直指分结构化数据的直接分析，但是在实际工业界进行中的数据分析工作，为了达到准确和高效的目的，主要还是以对结构化数据进行计算为主的。即使源数据是非结构化的，在进入正式的分析过程之前，也要进行专门的数据处理工作，先对源数据进行分column和schema提取的工作。而这部分工作，目前在实践中，还是由人工来完成的，消耗相当大。例如，某大型软件企业，现在每天耗费上百人工做这类数据处理的工作。

而在DAP_2的设计理念中，这部分工作，靠Parser的自动运行就可以完成了。不得不说其设计者颇具前瞻性。

数据导入后，每份数据的schema被存储在hdfs中。之后所有的处理过程，都是处理的结构化数据，虽然其具体存储形式是HBase中的KV pair ——以笔者所知，当前真正在运行的大数据处理分析系统大都是这么做的。

除了统计分析和聚合（aggregation）之外，DAP_2的控制层还提供了SQL和R接口，允许用户自己定制专门的算法。不过这里有个很大的弱点，R是采用RHive直接结成到hadoop的mapreduce 框架下的，也就是说，用户虽然可以写R程序，但不过是用R语言书写map reduce程序而已，而不能做到正常书写R程序那样透明，这一点，就导致了R接口的基本不可用。

因为底层是HDFS，所以DAP_2和DAP_1相比，数据访问速度要慢得多，而DAP_2偏偏还是针对“大数据”的，和database 一般情况下MB级别的操作相比，DAP_2设计的一般数据流在GB级别。

为了应对这种情况，DAP_2采用了大量的队列，每个模块之间都是通过queue连接的，整体架构类似一个graph，顶点是各模块，边是队列，数据展示层和DAP_1类似，也是各种数据图+dashboard。

通过之前的描述，大家也能看到DAP_2这个产品，并不适合一次性大量导入数据，相反，它比较适合的应用场景是流式递增，或者小批量delta。这是因为，一开始，它的目标用户就是游戏公司和小电商，这些用户有每天的数据分析需求，分析需求本身一般相对简单，但是数据处理颇成问题，因为企业相对小，往往又没有专门的数据职位。这种公司选择在公有云中批量上传自己的数据每天获得实时报告，还是有可能的。

DAP_2这个产品，版本发布到1.1，曾经在美国亚马逊的ec2平台上部署过对外发布的beta版。最多的时候拥有十几家用户。很可惜，实践证明，真正的活跃用户只有2家，而且各自提出了自己的定制需求，当无法跟进用户的需求的时候，这两家用户也逐渐放弃使用了，最后，ec2的运营费都交不起了，至少撤下来。然后，就没有然后了，这个项目直接被公司取消了。

三、思考及展望

通过DAP_2这个项目，笔者产生了一个强烈的感觉：没有数据，就别谈数据分析！

指望用户上传数据是不现实的，因为分析结果无法保证。即使产生分析结果，也不能确保这些insights真的能够对用户的业务产生影响。而同时，暴露用户的私有数据确实百分之百的。在这种投入产出的对比之下，有多少用户会放心上传自己的数据？另外，不易使用也是一个问题，用户如果每天要做一次几十几百G的数据迁移，就算没有安全问题也要烦死了。

这种针对大量小用户的数据分析工具/平台——个人的意见——数据持有者才能建得起来。比如阿里可以建这样的平台，淘宝、阿里云，用户的数据本来就在他们的服务器上，他们提供分析工具或者算法，数据不用迁移，既不涉及新的安全隐私问题，也省了很多麻烦。而纯粹第三方公司提供这种平台，除非和数据持有者合作，否则，真的很不看好。

目前类似DAP_1或者DAP_2，或者DAP_1+DAP_2的数据分析工具有很多。大家如果作为用户，想要使用这类工具，首先考虑的一定是数据安全问题，如果被要求上传数据，最好先自行处理掉其中的敏感信息。如果作为开发者欲投身其中，恐怕首先要考虑一下:用户会考虑什么?这类工具，部署到公有云上，面对个人/小企业的部分智能化、傻瓜化，做成“云端的excel”是一个方向；面对大企业，基于私有云，针对企业定制，也是一个方向。后者比较有可能在接下来的几年中得到发展。

四、线上问答：

Q1：想请问一下无header的csv导入，如何关联分析字段的含义呢？后台有配置？

A1：根据规则，首先发现分割符，分出有多少column，然后根据column中值的采样情况，依据规则判断是日期、字符还是数字，规则当然可以定制.

Q2：如果公司需要，在私有云的分析中，如果将敏感信息去除，是否会极大影响分析结果？

A2：私有云的话局限公司内部，可以通过限制数据访问权限来规避隐私泄露，不用去除。

Q3：对DAP_2的parser自动解析挺感兴趣，解析出来的schema是如何保障正确的？还有现在很多的文档型数据，schema多种多样，不指定schema的结果就是数据可能很乱，甚至影响效率，这个DAP_2是否遇到这种情况？是怎么处理的？

A3：这个问题涉及到细节，DAP_2内部对于每一个data source，都对应成一个虚拟的table，这个table是具备唯一schema的，这个schema不是用户指定的，是Parser解析后自动生成的。

Q4：如果公司需要，在公有云的分析中，如果将敏感信息去除，是否会极大影响分析结果？

A4：你的意思是说如果公司需要把数据上传到公有云，然后。。。吧？去除信息在一定程度上可能会影响分析结果，比如把用户姓名性别和年龄去除了，就没法依据年龄做aggregation，什么都保留着就会暴露隐私，这是一个balance。

Q5： SQL+ Hadoop类产品是不是以后数据平台的方向？

A5：HDFS + SQL interface + high speed computing framework（例如spark）+streaming system + ML library 或enable R interface 大概是以后数据平台的方向。

Q6：总结下，第三方分析平台的原因：1，数据安全；2，数据分析结果没有保障（可能是不同业务不同的需求）。你感觉哪一方面更限制了数据分析平台的建设，是否还有其他因素？

A6：主要是安全性和方便性，如果要用户每天做一次几十几百G的数据迁移，就算没有安全问题也要烦死了。

Q7：那是不是可以这样去判断，未来几年可能还是处在大数据工具及局部应用的发展阶段。

A7：大数据应用目前还属于初级阶段，不过这不是一个单枪匹马可以杀入的行业，作为个人或者小团队创业，做公有云数据分析的可能性很低--个人看法，而为大公司提供产品，小团队又很难提供generic的tool；所以其实个人不太看好小团队开发数据分析平台。

Q8：小团队在大数据方面可以有哪些作为？

A8：小团队可以和大公司合作或者提供数据咨询服务，比如到某公司内部去在人家公司里面做公司内部数据的分析挖掘工作。