从0到1构建数据生态系列(二):拆解架构蓝图

  1. 云栖社区>
  2. 博客>
  3. 正文

从0到1构建数据生态系列(二):拆解架构蓝图

稀奇古怪 2017-05-17 13:49:00 浏览1727
展开阅读全文

一、结合业务需求拆解架构图

 

先把上一章已经讲过的架构图再贴一次:

 

20170510101959348.jpg

 

整体架构说明

 

从架构图中可以看出,在我们整个数据架构中,需要做的事情很多。随着数据的流向,从下到上,主要分三层:

 

  1. 第一层是数据收集层,负责基础数据的收集工作;

  2. 第二层是数据存储与处理层,负责数据存储、对数据进行深度处理、转换及价值的挖掘等;

  3. 最上层是应用层,基于下面的数据处理,进行价值转换;还有贯穿整个过程的监控以及任务调度相关的工作。

 

第一层中,主要有四个数据来源:用户行为埋点上报数据、服务日志的数据、后端的业务数据、互联网的公开数据。

 

第二层中,我们主要的核心框架是Hadoop的核心生态,基于HDFS的存储(本质上hive的存储也是基于HDFS),以及基于Spark部分实时处理的需求场景,主要是平台级的架构。当然,至于说具体的处理以及数据的加工、挖掘详细数据业务,后续其它章节再详述。

 

第三层中,我们直接面向的是业务方。一方面是数据生态中最基础最常见的的数据智能商业化分析,我们以excel封装成邮件日报周报的形式提供。另一方面是平台化的BI系统,以及高度自助性的数据自助查询系统。

 

在深度挖掘方面,推荐是一个大方向,基于数据的当代搜索也是数据生态的重要组成部分,同时还有业务画像、用户画像(绝对核心价值所在)等。除了以上这些,还有一些基于数据的推送服务、榜单数据、精准营销系统等,都是数据进一步有效应用,以及数据化价值的直接体现。

 

收回话题,在时间、人力有限,并且基础是0的前提下,事情解决的顺序就显得尤为重要了。
 

当前的业务需求

 

想要使用数据,前提是有数据。所以,我们第一个需要解决的问题是数据源,核心的驱动价值因素是我们的业务需求。

 

我们第一个业务需求就是从数据上洞察产品的运营效果,电商的各种数据运营需求,指导内容数据化运营、电商数据化运营以及通过数据改进产品。

 

跟业务强相关的基础数据是产品的业务数据库,这个是现成的,只要打通数据流通即可。与用户行为强相关的则是最直接的用户行为埋点上报数据,以及用户使用服务,在应用服务中留下的访问LOG。

 

基于服务日志LOG解析数据,一方面如果需要从服务LOG中清洗出有用数据,前提是服务中已经有意识的进行相关信息的LOG落地,这一点,很遗憾,当时并没有这个前瞻性。其次,从服务LOG中清洗数据的代价略高,且信息量有限。所以,在这个阶段中,我们并没有打算直接从服务LOG中清洗数据,因为在服务LOG中埋入数据收集点位,也是一个巨大的改造工程,但效果并不一定好。

 

我们将最快限度地打通业务数据库与数据中心的通道,然后以最快速度的对业务方提供可参考性的数据化日报。打通行为数据到数据应用的链路,结合用户行为数据,进一步优化数据化运营体系,以及为产品优化迭代提供数据支撑。构造最基础的数据中心平台,打通数据收集到数据分析应用的链路,为业务方、决策层提供数据化运营决策方案,为产品迭代提供最真实的数据反馈支撑。

 

这是我们数据部门第一个战略目标,像深度挖掘、推荐系统这些在这时通通不要想太多,饭需要一口一口的吃!

 

之所以需要拆分阶段目标,依然是投入与产出比的问题!

 

当有一个大目标时,我们需要把目标进行拆分,进一步拆分为阶段可实施、成果可见的阶段性目标,在这里同样适用。

 

并且,记住,你的老板是不懂技术的,他才不会管你的平台又建设到什么程度,集群又搭建了多少台,他只会问,这都一两个月了,你们数据怎么还没有给公司带来价值啊?!(哈哈,有点黑BOSS的感觉了)

 

不过这肯定是现实,不同位置上的人关注的核心重点不一样。可能你需要关注整体的进度,而业务层只关心你的产出给他带来什么帮助。是的,拆解大目标有利于我们快速入手启动项目;成果阶段化,更具有鼓励性,成就感;最后就是阶段性目标的实现情况更容易量化你的效率。

 

从人力的需求评估角度上说,也是有道理的,只有随着你的体系一步一步完善,你才知道哪个环节真正的缺人,缺什么人,这点很关键。不过最本质的问题,还是投入与产出比。

 

我们在做任何一件事情的时候,都需要注意投入与产出的比例,在一定的时间段内、投入一定的精力、产出一定比例的成果。有这种价值观,处理事务才更有效率!

 

二、如何做机器需求的评估

 

想要打通数据收集到数据分析业务的输出链路,那么你需要一个数据平台进行支撑,甚至后续你将持续开挖的数据核心价值,这些都是基于平台做的。

 

所以我们需要一个数据平台,而说到平台,则机器资源是绕不过去的一个问题。那么,如何去评估你的集群需要多少台机器呢?每个机器又是以一个什么样的角色存在的呢?

 

在评估之前,你首先应清楚了解到平台上需要承载的业务,包括内部的处理业务以及对外暴露的数据业务。其次,你需要考虑后续的可扩展性,即后续数据量上涨的情况下,机器的横向扩展当然是没有问题的,但部分角色机器的资源需求是在纵向。

 

举个简单例子,Hadoop的datanode可以在横向上进行扩展,但是Namenode的资源需求则无法做到。

 

至于说如何进行机器资源评估,在了解自身业务需求的前提下,这里所说的业务需求,不单纯是业务范围,也意味着业务范围承载的数据量是什么情况。在了解自身数据量的情况下,多查找其他公司的案例,与其他同行多交流沟通,借鉴其它公司的数据量与集群规模,来评估自身所需要的机器资源。需要注意一点的是,对于电商行业,经常会出现节日性、活动性质的流量暴涨。

 

所以,你的机器资源一定是需要考虑这些实际场景负载的或对于这种场景,若你有其它的方案进行处理也OK。

 

三、使用Nginx做数据上报伪服务

 

上面说到第二个重点,那就是用户行为数据的上报。

 

了解数据上报以及埋点相关逻辑的朋友应该清楚,其实所谓的SDK,其本质也是一个接受数据上报的服务。直接往上报服务中丢数据,跟封装成工具SDK,本质的意义是一样的,我们需要提供一个对外的数据上报服务。上报什么数据,数据以什么格式上报,这个在下一章的“数据上报体系”部分详细阐述,这里只是对上报服务这块进行讲解。

 

那这意味着,我们需要为客户端或者H5的童鞋提供一个统一的上报服务接口,让他们在用户特定行为操作的时候。比如浏览了某个页面,操作了某个按钮等之类的操作,进行这种信息的收集统一上报。说白了,封装用户的行为数据,在适当时候调我们的接口,把用户的行为数据给我传过来。

 

那这看似就是一个后台服务,用于处理上报过来的数据。但是请注意,不管你是一个服务也好,伪服务也好,一般情况下绝不会直接把获取到的数据直接落地的,这是传统的思维路子。

 

要知道上报的业务流量是很大的,特别是你的点位足够丰满的情况下,在流量高峰期,你要是敢直接进行数据落地,它就敢直接把你的服务给搞死。一所以一般情况下,我们都会把数据丢给缓存,以解耦上报与落地两端的压力。

 

既然如此,在人力资源有限、项目时间有限的前提下,为何要花这么大的精力去维护一个服务呢?于是,有了伪服务设想。

 

我们直接使用Nginx对外伪装成一个Web服务,提供Restful API,但我们不对上报的内容做任何处理,直接落地成Nginx的日志,再通过Flume对日志进行监控,丢到Kafka中。这样我们就迅速地搭建起一个上报“服务”,提供给客户端童鞋以及H5的童鞋,制定好数据上报的规范,然后就可以坐等数据过来了。

 

关于数据的合理性校验、规范性校验、有效性校验、以及进一步的解析,我们都放到Spark Streaming这一层去做。其实当时也是调研过lua的,在Nginx这一层也是可以做到数据完整性以及有效性校验的,但为了不至于给Nginx端带来过大的负荷,我们把复杂的逻辑处理放到后端。

 

基于这种伪服务的设计,还有一个好处就是,即使后端链路出现故障,但我的原始数据是落到LOG中的,只要我进行数据的回溯,再通过LOG清洗出异常的部分就行了。这也是我们后续实时数据容错的核心依据所在,所以,重点推荐。

 

四、用Spark Streaming做实时数据清洗

 

紧接上面的上报,我们在后端一层使用Spark Streaming做数据校验、进一步清洗的。

 

如果业务对于实时性要求不高,我们完全是不必要做数据的实时链路,只需要周期性地把Nginx中的上报日志进行批量清洗入库即可。但是,一方面基于部分对实时性稍高(其实也不高,分钟级别),例如电商活动期间对数据的实时监控;另一方面来说,实时性的数据上报链路是最终的目标,为了业务的时效性,迟早是需要做的。

 

由于我们需要在后端的处理环节中,对数据的有效性、规范性做校验,并且做进一步的属性解析,例如通过IP解析地理位置之类的,因此承载的业务逻辑还是蛮复杂的。

 

所以,我们打算引入一个实时处理框架来做这件事。关于实时框架这块,我想,熟悉的朋友都会想到两个:Storm与Spark Streaming。在这里跟大家分享我之前翻译过的一篇文章《Storm与Spark Streaming的对比》。(英文原文:http://xinhstechblog.blogspot.com/2014/06/storm-vs-spark-streaming-side-by-side.html

 

0? 数据处理模型、数据延迟性

 

虽然这两种框架都提供了系统的可扩展性和可容错性,但是它们的数据处理模型从根本上说是不一样的,处理模型则决定了它们的实时性。

 

Storm可以实现真正流式实时的处理数据,例如每次处理一条消息,这样延迟就可以控制在秒级以下,实时性很高。而Spark Streaming的本质还是批量处理,只是这个批量是微批量,在短的时间窗口内进行数据实时处理,通常延迟在秒级左右,实时性相对较弱。
 

数据保护、容错能力

 

在数据容错能力方面,SparkStreaming做的比Storm好一些,它的容错是通过状态记录去实现的(译者注:熟悉spark的童鞋都知道,spark会将所有的处理过程状态都以log的形式记录下来,即血统,出现错误的时候,可以根据血统进行数据的恢复)

 

而Storm则不一样,Storm对每一条数据进行处理标记,从而进行跟踪数据的处理情况,它只能保证每条数据被处理一次,但实际情况是,在发生错误时,这条数据是被处理多次的。

 

这意味着,更新多次时可能会导致数据不正确。

 

而Spark的批处理特点,能够保证每个批处理的所有数据只处理一次,保证数据不会在恢复的时候错乱(批处理重新执行)。

 

Storm提供的Trident库虽然能够保证在数据容错时只被处理一次,但它很大程度上依赖于事务的状态更新,并且这个过程相对较慢,更甚者,这个过程是需要用户自己去实现。(译者注:Spark的数据安全性是毋庸置疑的,虽然当年Storm能够从多个开源实时处理框架中脱颖而出,ack/faild机制的功劳巨大,但是跟Spark比,数据容错能力还是差了一筹)

 


\

 

 

所以,如果你的业务场景对实时性要求比较高,同样对数据容错也有所要求,那么Storm将是一个很好的选择。当然,如果你希望对每次实时处理的过程进行掌控,那么Spark Streaming提供的状态记录会清楚地描述出数据处理的过程,并且数据的容错能力也很不错。

 

框架实现以及编程API

 

假如你想深入源码中研究,你需要清楚的是:Storm是由Clojure编写的,而Spark Streaming则是Scala。

 

Storm是由BackType和Twitter开发的,而Spark Streaming则是由UC Berkeley开发的。

 

在语言支持上,Storm提供了Java API,同时也支持多语言。(译者注:在多语言的支持上,虽然支持,但是通常除了Clojure、Java、Python等几种语言,其它语言进行开发还是很困难的,最常用应该是Java)Spark Streaming支持Scala、Java、Python等几种语言。

 

批处理框架集成

 

(译者注:这点是针对于Spark Streaming来说的)

 

Spark Streaming一个很大的优势就是,它是基于Spark框架上做的,这样的话,熟悉Spark操作的人就能很轻松的像进行其它批处理操作一样,进行操作Spark Streaming。这意味着你不用进行额外的编写处理代码,更为便捷。

 


\

 

 

实际生产应用

 

Storm开源得比较早,自2011年起,推特就在使用Storm了,其后更多的公司使用它。Spark Streaming是一个比较新的项目,在2013年的时候,仅仅被Sharethrough使用(据作者了解)。

 

Storm是Hortonworks Hadoop数据平台中的数据流式处理的解决方案,而Spark Streaming出现在MapR的分布式平台和Cloudera的企业数据平台中。

 

此外,Databricks公司还专门为Spark提供技术支持,当然,其中也包括了Spark Streaming。

 

最后在依赖框架来说,Storm可以在Mesos上运行, 而Spark Streaming可以在YARN和Mesos上运行。

 


\

 

 

Storm比Spark Streaming更有实际应用的优势,但Spark有专门的公司维护它并且提供技术支持,包括它与Yarn的结合等。

 

总结

 

其实Storm在处理领域上还是有一定的差异的,Storm比较擅长实时性较高的数据处理,而Spark Streaming则偏向于内存处理(注意严格来说内存处理跟流式处理并不是完全一样的)。

 

在数据安全性方面,不作过多的评论,数据安全Storm虽然没有Spark streaming强大,但从目前来看已经够用了,要知道很多业务数据在这种场合下是允许丢失部分数据的。

 

关键点在于资源的管理,虽然最近发布的Storm 0.10.0-beta号称在资源管理上已经做了不小的优化,但在个人看来还远远不够。Spark Streaming依赖于Spark的环境,而Spark在Hadoop2.0时代以后,资源管理方面得到了巨大的提升,这侧面的衍生了大量类似Yarn的组件。

 

虽然Storm也可以运行在Yarn上,但目前并没有一个很稳定可用于生产环境的开源版本。所以,在资源管理方面storm还有很长的一段路要走。

 

在两者的选择上,从当前实际应用看,Storm已经越来越多的生产实例了,而Spark Streaming更多还处于预研或者试用阶段。

 

相对来说,在流式处理上,Storm有着不可比拟的优势,而在大批量内存处理的方面,则是Spark Streaming占着不小的优势。

 

所以具体使用方面,一般情况下Storm足够了,而Spark Streaming的话,慎用,毕竟任何开源的稳定性以及其价值,都是需要时间来检验的。

 

总之,Storm与Spark Streaming最本质的区分在于,Storm是真正实时处理,而Spark Streaming的处理本质则是微批处理。所以Storm能够将实时业务达到毫秒级,而Spark Streaming虽然也能达到亚秒级,但对于效率的影响会比较大,所以一般会用于秒级的数据处理。

 

目前就我们自身的业务需求来说,对于实时性并没有高到毫秒级的要求。

 

并且,为了维护系统平台的统一性(统一的平台架构,统一的YARN资源管理,同一个垂直生态),我们选择使用Spark Streaming作为我们数据清洗的入口。

 

使用Spark Streaming需要解决的一个问题就是,输出结果的高度碎片化。

 

正如上面所说,Spark Streaming其核心依然是Spark的路子,在微小的时间窗内,对微小批量的数据进行处理,达到类似实时的效果。

 

而其每一个批量处理之后都是以批量结果得以输出,于是,就会产生大量的碎片文件。

 

其实,解决这个问题也简单,那就是合并!进行周期性的文件合并,这点就不多说了。

 

既然说到了Spark Streaming,也就顺带着说一说Spark这个生态。

 

在很早以前,Hadoop、MapReduce经常会被人提到,但是随着Spark的兴起,已经越来越少人愿意使用MapReduce去批量处理数据了。

 

是的,Spark目前在Hadoop大生态中,已经形成一个比较完整的子生态:

  • 包括与数据查询分析关联的Spark SQL;

  • 实时处理领域的Spark Streaming;

  • 正常内存处理可以替代MapReduce的离线批量;

  • 还有集成大量机器学习包的MLlib;

  • 以及还有什么图形处理的什么鬼(好吧,那个不是我擅长的)。

 

在效率至上的数据时代,MapReduce说抛弃就被抛弃了(哈哈,其实也没有这么严重,只是越来越多人弃用MapReduce,这肯定是事实)。

 

在体系支撑上,Spark依然成气候,数据的常规SQL分析,数据的内存处理、实时处理,以及数据的深度挖掘等,全部一起打包,好用的不得了,所以越来越得人心,也是木有办法的事。

 

关于IP地理位置解析,这里也可以分享一下。

 

IPIP.NET提供的IP库实在是值得推荐的,没钱的可以使用它提供的免费版,有钱的主可以考虑使用使用付费版。

 

免费版没有想象中那么不堪,只是它提供的服务没有这么多,更新的频次少点而已,大部分能解析到市一级,至于省份这一级,那是妥妥的没问题。

 

五、结语

 

本章主要阐述如何从局部入手,拆解架构图,进行阶段性的任务执行。其中,详细讲解了部分核心重点,包括架构图的拆解、机器资源的评估、Nginx的上报伪服务、以及基于Spark Streaming的数据清洗等。

 

但是个人认为,方法论远比现成的方案有用,授人以鱼不如授人以渔!更重要的是中间阐述一些问题的思考方式、价值观,诸如拆解整体规划的思考、扩展预留的思考、方案选择的对比衡量等。希望本文能对你有所启发。

 

作者介绍 黄崇远

  • 毕业于哈工大,近6年大数据行业经验 ,目前于深圳一创业公司任职大数据主管,数据虫巢公众号及官网(www.mite8.com)创建者。

  • 原文发布时间为:2017-05-10

    本文来自云栖社区合作伙伴DBAplus

网友评论

登录后评论
0/500
评论
稀奇古怪
+ 关注