大数据平台架构

　　五个层次：

　　数据采集层：离线采集（hadoop），实时采集（flume+kafka），网络采集（爬虫）

　　数据处理：批处理（hadoop，MPP），实时处理（流处理）

　　数据分析：主要包含了分析引擎，如数据挖掘，机器学习，深度学习

　　数据访问：主要是实现读写分离，将偏向应用的查询等能力与计算机能力剥离，包括实时查询，多维查询，常规查询

　　数据应用：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销，客服投诉，基站分析，对外有基于位置的客流，基于标签的广告应用

　　数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理

　　企业级的爬虫中心，不仅需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘。已经有开源的组件，如solr，lucent，Nutch,ES

　　数据采集平台，至少要达到以下三个要求：

　　1多样化数据采集：支持对表，文件，消息等多数据的实时采集（flume，kafka）和批量数据分布式采集（sqoop）

　　2可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽开发

　　3统一调度管控能力：可支持hadoop的多种技术组件（mapreduce，spark，hive），关系型数据库，shell脚本

　　数据处理层

　　Hive做简单的离线海量数据分析计算是它擅长的，相对应的，复杂的关联交叉运算其速度很慢

　　Hadoop到了X000台集群的规模也快撑不住了，当前很多企业的数据量都应该快超过这个数量，除了像阿里等自身研发能力的企业（odps），是否也要走按业务拆分hadoop集群的道路。如浙江移动已经拆分了固网，移网，创新等多个hadoop集群

　　Hadoop的spark很适合机器学习的迭代，但能否大规模的应用于数据库关联分析，能否一定程度替代MPP，还需要实践来验证

　　IBM stream处理能力超过storm不是一点半点

　　数据分析层

　　Python更偏向工程，比如对分词啥的直接支撑，R的绘图能力异常强大，但他们原来都以样本统计为主，因此大规模数据的支撑有限。分布式挖掘环境，spark是一种选择，建议采用spark+scala

　　也许未来的机器学习也会形成高低搭配，高端用户用spark，低端用户用spss

　　深度学习，tensorflow是个选择

　　数据开放层

　　有的直接将hive作为查询输出

　　Hbase很好用，基于列存储，查询速度毫秒级，但读取数据只支持通过key读取，因为要设计好rowkey

　　Redis是k-v数据库，读写速度比hbase更快，但hbase是基于内存的，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术

　　Kylin当前算是基于hadoop/spark的多维分析的杀手级工具，应用场景很多

　　数据应用层

　　大数据架构越上层越不稳定，因为 变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图

　　标签查询：基础画像，位置行为，上网行为，习惯偏好，社交行为

　　位置雷达：客流监控，选址雷达，引客雷达，交通检测，对外api

　　风险控制：信用评估，验真查询，客户找回，天盾反欺诈

　　喜从天降：大转盘手机投放，大转盘宽带投放，大转盘（b端）投放

　　洞察报告：终端洞察，风险洞察，会展洞察，城市经济地图，线下商业

　　数据管理层：

　　大数据平台的管理应有应有管理和系统管理之分

　　从系统管理的角度看，公司将大数据平台纳入统一的云管理平台管理。

　　对于大数据平台商业版本，企业面对的是合作伙伴的服务跟不上，因为发展太快。

　　对于开源版本，企业面临的是自身运维能力和技术能力的挑战，对于自主能力实际要求更高