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

随着“大数据”概念的火爆,各色(大)数据分析平台一时之间也是风气云涌,更兼与云计算结合,成为一个个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”是一个方向;面对大企业,基于私有云,针对企业定制,也是一个方向。后者比较有可能在接下来的几年中得到发展。

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

原文发布于微信公众号 - 悦思悦读(yuesiyuedu)

原文发表时间:2015-12-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏鹅厂网事

海量服务器运营平台的进化之路

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

37360
来自专栏EAWorld

万达网络科技的DevOps平台架构解析

目录: 一、万达DevOps平台建设历程 二、平台架构解析 三、建设过程中的难点分享 四、总结 一、万达DevOps平台建设历程 我们从2017年2月份开始帮助...

41950
来自专栏鹅厂网事

变更管理点滴分享

互联网企业的变化节奏太快,流程和工作效率都需要兼顾,对变更活动潜在的风险无形中会放大,导致故障几率会成倍增长。

289100
来自专栏云计算D1net

解锁云计算数据管理的四个关键因素

根据预测,到2020年,83%的公司将采用公共云。垂直行业的许多公司都已经开始了云计算之旅,并将在未来几年内将其业务迁移到云平台中。许多人的目标是利用最新的软件...

13910
来自专栏大数据文摘

数据分析:怎样辨别渠道作弊

45260
来自专栏云计算D1net

从云计算到边缘:驯服应用供应链的复杂性

为了满足数字世界中快速变化的客户需求,IT部门必须帮助他们的组织保持行业领先,并保持在预算范围内。例如,为了使IT能够提高敏捷性,并提高服务和创新的交付速度,他...

11900
来自专栏WeTest质量开放平台团队的专栏

WeTest适配测试报告2.0化繁为简,为你而来

曾经有一个适配测试报告摆在你的面前,而你可能苦于找不出最重要的问题在哪;如果您能给我们一次机会,我们会对您说四个字“不爽来试”。

16330
来自专栏直播软件开发把

微信小程序开发定制硬货分享—不怕神对手,就怕猪队友!

张小龙表曾说。“小程序真正的入口在二维码上,未来更多希望小程序的启动是扫二维码实现。” 这一点让很多行业都很适用。

13410
来自专栏互联网杂技

语音交互中的“等待体验”研究

回顾人机交互发展史,人类先后经历了基于命令行的CLI 时代,基于鼠标键盘的GUI时代,基于触摸的初级NUI时代。后面每一个阶段比前一个阶段更自然,学习成本更低,...

38080
来自专栏移动开发平台

移动开发即服务,腾讯云移动开发平台打造开发新模式

互联网“下半场”,移动App开发对于质量、效率的要求更加苛刻。传统移动开发的模式是移动开发者手动集成所需的各种移动服务,和后台服务紧耦合去打造精品移动应用。在传...

2.8K80

扫码关注云+社区

领取腾讯云代金券