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

随着“大数据”概念的火爆，各色（大）数据分析平台一时之间也是风气云涌，更兼与云计算结合，成为一个个cutting edge startup的营销热点。笔者碰巧在多年前就参与过2个数据分析平台的研发工作，对于数据分析业务、平台建设等问题有些感想和思考，在此与大家共享。 一、私有云数据分析平台：DAP_1

DAP_1是2010-2012年期间开发的一个基于私有云的可视化数据分析工具。

它的出现是基于明确的产品需求的，目标用户是就职于专业数据分析部门的数据科学家（datascientist）。

Data scientist的日常工作内容包括：和客户沟通，了解数据分析需求；获取样本（或全部）数据，清洗、统计、建模，得出insights；生成数据分析报告（一般为数据可视化报告）向客户进行展示。这个过程可以是一次，也可能是多次迭代，总之最后要交付一个观点，数据的运算结果就是支持这种观点的结论。虽然datascientist使用的工具是很广泛的，但就当时而言，我们的目标客户是那些使用SQL在数据库上进行演算的DS。 2010年，大数据方兴未艾，当年的大多数公司还是用数据库存储数据的，而R，Python等语言当年并没有今天这么火热，也没有这几年来那么算法库做支持。鉴于当时的业界环境，DAP_1的设计并非针对大数据，而是针对数据库中存储数据的运算。在这样的需求范围明确下来以后，存储层当然是采用数据库。

但是，当时DAP_1提出了一个database provision的概念­——让用户通过很简单的操作，就可以创建一个虚拟的数据库，用于存放自己的已有数据和所有新生成数据。这一做法主要是针对datascientist的一个很强烈的需求：他们每天面对的是一大堆“脏”数据(dirty data)，有迫切的愿望对其进行清洗，但是不同目的的清洗会剔除这些原始数据中不同的部分，所以，需要备份这些数据，在同一个数据库操作不仅麻烦而且还容易出错，另外还无法掌控别人的访问权限，故而需要不断创建新数据库。 控制层的功能主要放在对于用户和资源的管理上，而非数据分析算法。这是因为，目标用户是datascientist，算法这块可以放心的交给用户自己去做。DAP_1对他们提供了SQL接口，允许他们通过写SQL query来处理数据。而不同datascientist之间共享数据，共同操作某一部分数据，向他人展示他们的结果，恰恰是他们的需求所在。所以，DAP_1的用户管理（权限、角色），资源管理（允许用户建立、参与项目，在项目中创建、暴露数据库等）是重点。 数据展示层，提供了dashboard和多种可视化图表，用户可以通过选择database/table/column创建各种例如柱状图、折线图、热点图之类的，这部分和现在很多的图形化分析工具类似。 整个系统是分布式部署的，不过相较于现在的分布式存储运算系统要简单得多。因为数据量和运算量都相对小，作为webservice部署。各个节点独立运行，用户的job是被提交到单个节点，独立完成。分析算法的运算性能由底层数据库性能和用户的SQL脚本优化度决定。

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

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

DAP_2是继DAP_1之后的产品，开发周期在2012-2014年间。当时，”Big Data”在硅谷已经成为热词，并已经开始登陆中国。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”是一个方向；面对大企业，基于私有云，针对企业定制，也是一个方向。后者比较有可能在接下来的几年中得到发展。

再多说一句，大数据应用目前固然还属于初级阶段，但这不是一个单枪匹马可以杀入的行业。作为个人或者小团队创业，做公有云数据分析的可能性很低。而如果是为大公司提供产品，小团队又很难提供通用工具（除非是针对某一家企业定制项目）。因此，个人不太看好小团队开发数据分析平台。