您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 大数据 > 正文

企业数据分析工作的任务、工具及挑战

发表于:2018-03-20 作者:佚名 来源:网络大数据

大数据时代,数据已经成为战略资源。掌握前沿科技的大型IT企业在数据分析和利用上走在了时代的前列。

笔者浸淫IT业十余年,对数据分析技术及其未来趋势有一定的了解和思考,在此与大家分享。

鉴于大型IT企业是数据分析工作的早期天使客户和许多具体技术、工具的发源地,我们主要针对大型IT企业来做一些分析。

企业数据分析工作的任务、工具及挑战

0. 澄清基本概念

为了不在后面讨论中因概念不清产生误解,我们首先给出几个定义:

  1. 大型IT企业:指对外提供IT相关的软硬件产品及服务的公司,员工至少在万人以上。
  2. 数据平台:指大型IT企业用来为自身服务为主,担负数据存储、处理、分析业务和软硬件综合。主要针对内部服务,不对外开发。
  3. 数据分析:此处的数据分析师广义的,包括一切基于数据得出的insights的行为,包括统计分析、机器学习建模和预测等。

1. 大型IT企业开展对内数据业务的驱动力

就目前而言,IT企业针对自身的数据分析业务可以分为广告和非广告两类。对大多数企业而言,除了广告之外的数据业务,并不能直接带来可以量化的收入。

但是,无论当前数据分析的结果为企业的现金流做了多少贡献。数据为王的思想已然占据了众多前沿企业间的头脑。数据是矿山,insights是金子,有了矿山才能有金子,有了矿山,终究会有金子。

因此,开发数据业务最主要的驱动力,实际是对数据业务未来前景的积极预估。

主要应用有(除广告之外):

  • 用户画像——越来越多的企业开始观众用户画像,毕竟知己知彼百战不殆,卖东西先得了解买主。
  • 客户保持——预测哪些现有客户可能弃用产品或服务,即使采取措施挽留之。
  • 产品使用分析——DAU,MAU,PV,UV,CTR等等,这些看起来都是些简单的统计数字,但却是反应产品被使用情况的重要指标。
  • 产品推荐、销量预测
  • 销售指标……等等

具体到某一种应用,看似并不复杂,有些有成熟的方法可以用来训练模型,还有些根本就是统计指标。似乎并不需要什么高深的算法背景。

但一旦涉及实际,就不像看起来那么简单了。即使是统计指标,也不像想象得那样,随便run几个sql query就能得出来。

对于大型分布式系统,不同模块的访问log都有可能分布在不同的cluster上,单纯收集每日全局log就是一个复杂工作,更别说之后的合并、去重、聚合等工作。

因此,大型企业的数据分析不是做个excel表,安装一个免费mysql能够解决的,而是需要专门的大型数据分析平台。

2. 数据分析平台通用架构

常见的数据分析平台,至少包括数据存储、处理和分析三个部分。

2.1 数据存储

数据存储不必解释,是一定必要的。但是如何备份是一个很重要的问题。 假设:某公司一年产生上千PB的数据。按照单纯数据的存储费用1美元/GB年计算,存1TB一年就是1000美元,一PB就是100万,1000PB就是10亿。如果就是简单的使用hadoop的默认配置,每份数据都存3份,那么,这个实际产生数据x 3的体量将有多大?有将有多大的cost?

这是存储层的挑战。为了解决这个问题,一方面从硬件层面力图降低存储介质的价格,比如近年来冷存储的提出,就是针对运维费用。另一方面就是寻找备份算法。例如,yahoo专门研发了一种图片存储算法,逻辑上是11个备份,但是size只有原size的1.x倍。

2.2 数据处理

数据处理传统上叫ETL、EDW,主要指数据的清洗、迁移和格式化。大数据平台,由于应用范畴不同,自然多种多样,源数据包括结构化数据和非结构化数据。但是如果数据真的是“大数据”(符合4V特征)的话,即使本身收集上来的数据是结构化的,也往往需要二次处理,转换format或schema。

数据处理层所需技术相对简单,然而挑战在于对于数据的理解。如果不知道这个收集上来的log文件里面要提取出多少字段,每个字段对应数据源中的哪个部分,则数据提取完全不能进行。这就要求进行数据处理的人必须同时具备对业务的了解。

2.3 数据分析

数据分析是数据中寻找价值的关键步骤。数据分析工作本身还处于初级阶段。除了一些简单的统计计算,大多数数据还是只能交给分析人员,进行没有特别针对性的探索,效果难以得到保证。

对于这些挑战,开展数据业务早的公司,相应的平台和技术是在针对自身业务的过程中慢慢发展起来,部分公司选择是将平台外包或者自己开发针对自身业务的定制功能。相对于前两者,数据分析师一个业务针对性更强的步骤,因此更难采用通用方法或手段解决,更加依赖企业自身的积累。

3. 数据分析平台开源框架

3.1 开源框架

目前,就国内而言,谈到数据分析相关的开源框架,总不能忽略下面三个:

  • hadoop:batch,mapReduce
  • storm:streaming
  • spark:batch + streaming

这些开源框架的共同特点是把重点放在并行计算框架上,关注的是job latency, load balance和fault recovery,对于资源分配、用户管理和权限控制几乎不考虑。它们基于的假设是:所有用户都一样,平权,所有用户都能用所有的机器以最快的可能完成所有工作。

3.2 开源框架的局限

而在大型企业内部,不同部门,同一部门的不同job,绝对不是平权的。不同部门之间,也有很多私密的数据,不让别人访问。不同用户的权限也是不一样的。对于计算资源的需求,因为不同job的优先级不同,也要求予以区别。

在这种需求之下,催生了一些第三方,专门提供hadoop等开源框架的资源、权限管理产品或者服务。hadoop在升级到2以后,也考虑一些数据隔离的问题。

但其力度,恐怕难以满足大多数大型企业的要求。这也是使用开源框架的无奈。使用开源产品的商业发行版,也是一种办法。不过始终是不如企业原生系统在这方面的支持。

3.3 企业原生框架

确实也有些企业独立开发了全自主(不基于开源产品)的仅限于内部使用的分布式数据处理平台。在用户管理,数据访问权限,存储、运算资源管理等方面很下功夫。

例如:要求每个用户在提交job前必须先申请token,有多少token,就有多少计算量。不同数据存储路径之间的权限完全单独管理,使用者也要实现申请权限。

但是开发这样的系统意味着企业必须具备非常强大的研发能力,并能承担得起巨大的人力等资源的消耗。而且相对于开源系统已经实现的功能,难免有重复造轮子之嫌,即使是大型企业,也很少选取这种方案。

4. 大型IT企业数据业务的挑战

4.1 通用挑战:意识、技术和人才

4.1.1 意识

意识主要是指决策层的思想意识——数据对于企业发展是否真的必要?这一点在很多管理者脑子里还是存疑的,他们目前所处状态很多是:听说数据这东西有用,人家都在搞,所以我们也要搞,至于是不是真有用,搞出来看看再说。

如果只是采用游戏或者试探态度,必然影响发展进程。但这也是没办法的事情,所有新事物都必须经历这一过程。

4.1.2 技术

技术指目前数据分析的技术,基本是采用新框架逆流支持旧接口的策略。曾经有一篇文章,名叫《NoSQL?NO,SQL》,说的就是这个。包括spark回头支持SQL,也是如此。

明明我们分析的是非结构化数据,但是因为高阶算法的问题,却连mapReduce都放弃了,索性回到SQL时代。为了让更多人用的舒服,不去开发针对非结构化数据的新方法,而是反过来,向下兼容结构化。个人认为这是一种逆流。这样做则永远无法避免巨大的数据处理工作。

4.1.3 人才

“数据科学家”这个词大家肯定都知道。可是,这个职位其实很模糊,不同公司,甚至同一公司的不同部门之间对这一职位的定义相差甚远。有些数据科学家是学数学的博士,有些是以前做BI的,有些是PM转行的,水平参差不齐。

所以,恐怕在相当长的时期里,这会是一个门槛低,要求高的职位。很难短时间内批量涌现出优秀者。

4.2 特有挑战:产品align

产品align是说每个产品的数据分析结果可以互相对比,也就是要求其定义和实现都一致。对于一个产品众多的大企业而言,要求不同产品、流水线的分析报告具有可比性,这是一个很常见的需求。但是由于现在大多数企业中数据分析不是由一个部门统一管理,各个产品部门各自为战,结果导致在align的过程中互相牵制,进而拉低了所有产品的分析水平。

这样的挑战有赖于企业总体数据策略的制定和执行。而整体策略的制定和执行又有赖于前面所说的三点通用挑战,环环相扣,显然不能一蹴而就。

5. 大企业数据工作的发展趋势

早期的数据分析工作,在实践层面基本采用批处理模式。随着业务的发展,对于其实时或者准实时(NRT)的需求越来越多。提供latency极短的增量分析和流式服务是众多企业数据分析工作的当务之急。

从长远考虑,真正拥有数据的是大企业,未来,大企业在数据的分析利用上,也必将全面胜出小企业。

不过,处于不同成熟阶段的大公司突破点各不同。有些技术先行,在分析方法和工具上成为领军。另一些则倾向数据管理和治理,在管理层面上,在策略、条例的制定上为整个社会提供先进经验。