正文
想要打通数据收集到数据分析业务的输出链路，那么你需要一个数据平台进行支撑，甚至后续你将持续开挖的数据核心价值，这些都是基于平台做的。
所以我们需要一个数据平台，而说到平台，则机器资源是绕不过去的一个问题。那么，如何去评估你的集群需要多少台机器呢？每个机器又是以一个什么样的角色存在的呢？
在评估之前，你首先应清楚了解到平台上需要承载的业务，包括内部的处理业务以及对外暴露的数据业务。
其次，你需要考虑后续的可扩展性，即后续数据量上涨的情况下，机器的横向扩展当然是没有问题的，但部分角色机器的资源需求是在纵向。
举个简单例子，Hadoop的datanode可以在横向上进行扩展，但是Namenode的资源需求则无法做到。
至于说如何进行机器资源评估，在了解自身业务需求的前提下，这里所说的业务需求，不单纯是业务范围，也意味着业务范围承载的数据量是什么情况。
在了解自身数据量的情况下，多查找其他公司的案例，与其他同行多交流沟通，借鉴其它公司的数据量与集群规模，来评估自身所需要的机器资源。
需要注意一点的是，对于电商行业，经常会出现节日性、活动性质的流量暴涨。
所以，你的机器资源一定是需要考虑这些实际场景负载的或对于这种场景，若你有其它的方案进行处理也OK。
上面说到第二个重点，那就是用户行为数据的上报。
了解数据上报以及埋点相关逻辑的朋友应该清楚，其实所谓的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）
虽然这两种框架都提供了系统的可扩展性和可容错性，但是它们的数据处理模型从根本上说是不一样的，处理模型则决定了它们的实时性。
Storm可以实现真正流式实时的处理数据，例如每次处理一条消息，这样延迟就可以控制在秒级以下，实时性很高。
而Spark Streaming的本质还是批量处理，只是这个批量是微批量，在短的时间窗口内进行数据实时处理，通常延迟在秒级左右，实时性相对较弱。
