hadoop应用案例

上传人:suns****4568 文档编号:89211262 上传时间:2019-05-21 格式:PDF 页数:39 大小:1.43MB
返回 下载 相关 举报
hadoop应用案例_第1页
第1页 / 共39页
hadoop应用案例_第2页
第2页 / 共39页
hadoop应用案例_第3页
第3页 / 共39页
hadoop应用案例_第4页
第4页 / 共39页
hadoop应用案例_第5页
第5页 / 共39页
点击查看更多>>
资源描述

《hadoop应用案例》由会员分享,可在线阅读,更多相关《hadoop应用案例(39页珍藏版)》请在金锄头文库上搜索。

1、HadoopHadoop应用案例应用案例 Hadoop集群在互联网企业的应用集群在互联网企业的应用 京东商城京东商城 百度百度 阿里巴巴阿里巴巴 京东商城京东商城 源起:为POP商家进行日志分析服务 瓶颈瓶颈 性能瓶颈:采用性能瓶颈:采用Oracle RACOracle RAC(2 2节点),节点),IBMIBM小型小型 机,由于数据量极大,无法满足时效要求机,由于数据量极大,无法满足时效要求 成本瓶颈:小型机再进行高配和节点扩展,价格成本瓶颈:小型机再进行高配和节点扩展,价格 太贵太贵 Hadoop集群作为解决方案集群作为解决方案 20多个节点的多个节点的Hadoop集群集群 数据定时从收集

2、服务器装载到数据定时从收集服务器装载到Hadoop集群(周期为天级或集群(周期为天级或 小时级)小时级) 数据经过整理(预处理)后放进数据仓库系统,数据仓库是数据经过整理(预处理)后放进数据仓库系统,数据仓库是 基于基于Hive架构的,使用架构的,使用Hive的主要原因是技术人员基本都是基的主要原因是技术人员基本都是基 于于Oracle数据库的技能,由于数据库的技能,由于Hive支持支持SQL查询,因而技能可查询,因而技能可 以平稳过渡以平稳过渡 数据仓库查询统计的结果会被导到数据仓库查询统计的结果会被导到hbase,然后和应用进行,然后和应用进行 连接,应用不与连接,应用不与hive直接连接

3、的原因,是基于效率的考虑。导直接连接的原因,是基于效率的考虑。导 出数据到出数据到hbase由自行开发的一段由自行开发的一段C程序完成。程序完成。 应用即应用即portal通过通过API与与hbase连接获取数据连接获取数据 遇到的挑战遇到的挑战 Hadoop集群比较顺利,反映集群比较顺利,反映Hadoop项目本项目本 身已经较有成熟度。但由于身已经较有成熟度。但由于Hadoop系统考虑用系统考虑用 户权限较少,而对于大规模公司,势必要实施户权限较少,而对于大规模公司,势必要实施 多级权限控制。解决的方法是通过修改源代码多级权限控制。解决的方法是通过修改源代码 加上权限机制加上权限机制 Hba

4、se极不稳定,反映在某些数据导入导出极不稳定,反映在某些数据导入导出 连接过程里会丢失数据。判断为源代码连接过程里会丢失数据。判断为源代码bug, 通过修改源代码解决通过修改源代码解决 总体来说,总体来说,HadoopHadoop项目很成功,现在整个项目很成功,现在整个EDWEDW (企业数据仓库系统)都基于(企业数据仓库系统)都基于HadoopHadoop。集群已经。集群已经 发展到发展到200200节点。之前传闻的购买节点。之前传闻的购买Oracle Oracle ExadataExadata实际是用于下单交易系统,并非实际是用于下单交易系统,并非HadoopHadoop 项目失败。项目失

5、败。 大型企业成功应用大型企业成功应用HadoopHadoop,必须有源代码级别,必须有源代码级别 修改的技术力量。普通的程序员转型阅读修改修改的技术力量。普通的程序员转型阅读修改 HadoopHadoop源代码并不困难。源代码并不困难。 HiveSQLHiveSQL和和OracleOracle的的SQLSQL有一些差异,大约花一有一些差异,大约花一 周时间阅读周时间阅读ApacheApache的的Hive wikiHive wiki基本能掌握基本能掌握 部门结构部门结构 运维团队(负责管理维护集群的正常运行)运维团队(负责管理维护集群的正常运行) 数据仓库团队(根据业务部门的要求进行数据统计

6、数据仓库团队(根据业务部门的要求进行数据统计 和查询)和查询) 成都研究院(负责底层,包括源代码修改和按上层成都研究院(负责底层,包括源代码修改和按上层 部门要求开发部门要求开发MapMap- -ReduceReduce程序,比如一些程序,比如一些UDFUDF) Hadoop在淘宝和支付宝的应用在淘宝和支付宝的应用 从从09年开始。用于对海量数据的离线处理,例如对日志的分析年开始。用于对海量数据的离线处理,例如对日志的分析 ,也涉及内容部分,结构化数据,也涉及内容部分,结构化数据 主要基于可扩展性的考虑主要基于可扩展性的考虑 规模从当初的规模从当初的3-4百节点增长到今天单一集群百节点增长到今

7、天单一集群3000节点以上节点以上 ,2-3个集群个集群 支付宝的集群规模也达支付宝的集群规模也达700台,使用台,使用Hbase,个人消费记录,个人消费记录 ,key-value型型 对对Hadoop源码的修改源码的修改 改进改进Namenode单点问题单点问题 增加安全性增加安全性 改善改善Hbase的稳定性的稳定性 改进反哺改进反哺Hadoop社区社区 管理模式管理模式 集团统一管理集团统一管理 Hadoop运维团队运维团队 Hadoop开发团队开发团队 数据仓库团队(数据仓库团队(Hive) 准实时的流数据处理技术准实时的流数据处理技术 从从Oracle, MysqlOracle, M

8、ysql日志直接读取数据日志直接读取数据 部分数据源来自应用消息系统部分数据源来自应用消息系统 以上数据经由以上数据经由Meta+StormMeta+Storm的流数据处理,写入的流数据处理,写入 HDFSHDFS,实现实时或准实时的数据分析,实现实时或准实时的数据分析 数据装载到数据装载到HiveHive进行处理,结果写回进行处理,结果写回OracleOracle和和 MysqlMysql数据库数据库 淘宝数据魔方淘宝数据魔方 架构图架构图 架构图架构图 架构分为五层,分别是数据源、计算层、存储层、查询层架构分为五层,分别是数据源、计算层、存储层、查询层 和产品层。和产品层。 数据来源层,这

9、里有淘宝主站的用户、店铺、商品和交易数据来源层,这里有淘宝主站的用户、店铺、商品和交易 等数据库,还有用户的浏览、搜索等行为日志等。这一系列等数据库,还有用户的浏览、搜索等行为日志等。这一系列 的数据是数据产品最原始的生命力所在。的数据是数据产品最原始的生命力所在。 在数据源层实时产生的数据,通过淘宝主研发的数据传输在数据源层实时产生的数据,通过淘宝主研发的数据传输 组件组件DataX、DbSync和和Timetunnel准实时地传输到准实时地传输到 Hadoop集群“云梯”,是计算层的主要组成部分。在“云集群“云梯”,是计算层的主要组成部分。在“云 梯”上,每天有大约梯”上,每天有大约400

10、00个作业对个作业对1.5PB的原始数据按照的原始数据按照 产品需求进行不同的产品需求进行不同的MapReduce计算。计算。 一些对实效性要求很高的数据采用“云梯”来计算效率比一些对实效性要求很高的数据采用“云梯”来计算效率比 较低,为此做了流式数据的实时计算平台,称之为“银河”较低,为此做了流式数据的实时计算平台,称之为“银河” 。“银河”也是一个分布式系统,它接收来自。“银河”也是一个分布式系统,它接收来自TimeTunnel 的实时消息,在内存中做实时计算,并把计算结果在尽可能的实时消息,在内存中做实时计算,并把计算结果在尽可能 短的时间内刷新到短的时间内刷新到NoSQL存储设备中,供

11、前端产品调用。存储设备中,供前端产品调用。 架构图架构图 “云梯”或者“银河”并不适合直接向产品提供实时的数“云梯”或者“银河”并不适合直接向产品提供实时的数 据查询服务。这是因为,对于“云梯”来说,它的定位只是据查询服务。这是因为,对于“云梯”来说,它的定位只是 做离线计算的,无法支持较高的性能和并发需求;而对于“做离线计算的,无法支持较高的性能和并发需求;而对于“ 银河”而言,尽管所有的代码都掌握在我们手中,但要完整银河”而言,尽管所有的代码都掌握在我们手中,但要完整 地将数据接收、实时计算、存储和查询等功能集成在一个分地将数据接收、实时计算、存储和查询等功能集成在一个分 布式系统中,避免

12、不了分层,最终仍然落到了目前的架构上布式系统中,避免不了分层,最终仍然落到了目前的架构上 。 针对前端产品设计了专门的存储层。在这一层,有基于针对前端产品设计了专门的存储层。在这一层,有基于 MySQL的分布式关系型数据库集群的分布式关系型数据库集群MyFOX和基于和基于HBase的的 NoSQL存储集群存储集群Prom。 Myfox 数据查询过程数据查询过程 Myfox 节点结构节点结构 Prometheus Prom的存储结构的存储结构 Prometheus PromProm查询过程查询过程 glider gliderglider的技术架构的技术架构 glider 缓存控制体系缓存控制体系

13、 量子恒道量子恒道 Oceanbase Oceanbase 分布式的结构化存储系统,采用强分布式的结构化存储系统,采用强schemaschema的形式,其数据的形式,其数据 是分布在多个数据节点上,并将读写数据做了完全的隔离。是分布在多个数据节点上,并将读写数据做了完全的隔离。 OBOB的数据节点分两种,一类是基准数据节点的数据节点分两种,一类是基准数据节点 (!ChunkServer)(!ChunkServer),存储引擎是基于,存储引擎是基于SSTABLE SSTABLE http:/en.wikipedia.org/wiki/SSTablehttp:/en.wikipedia.org/w

14、iki/SSTable的。的。 一个是增量一个是增量 数据节点数据节点(!UpdateServer)(!UpdateServer),存储引擎是基于,存储引擎是基于Btree(Btree(内存中内存中 的的memtable)memtable)和和SSTABLE(majorSSTABLE(major- -freezefreeze- -dump)dump)的。的。 基准数据:从开始至某个时间点的全量数据,是静态数据基准数据:从开始至某个时间点的全量数据,是静态数据 ,在到下一个时间点合并之前,该部分数据不会发生变更。,在到下一个时间点合并之前,该部分数据不会发生变更。 增量数据:是指从某个时间点至当

15、前范围内新增的数据,增量数据:是指从某个时间点至当前范围内新增的数据, 增量数据会因为应用的各种修改操作增量数据会因为应用的各种修改操作 (insert,update,delete)(insert,update,delete)发生变更。发生变更。 整体数据分布整体数据分布 数据演进过程数据演进过程 sstable的总体数据格式的总体数据格式 sstable中中data block的排列规则的排列规则 sstable中的中的schema排列规则排列规则 HadoopBaidu 日志的存储和统计日志的存储和统计; 网页数据的分析和挖网页数据的分析和挖 掘掘; 商业分析,如用户的商业分析,如用户的

16、行为和广告关注度等行为和广告关注度等; 在线数据的反馈,及在线数据的反馈,及 时得到在线广告的点击时得到在线广告的点击 情况情况; 用户网页的聚类,分用户网页的聚类,分 析用户的推荐度及用户析用户的推荐度及用户 之间的关联度。之间的关联度。 挑战挑战 分布式计算技术分布式计算技术2.0 HDFS2.0 1.01.0所面临的问题所面临的问题 集群规模大,集群规模大,NamenodeNamenode响应变慢响应变慢 NamenodeNamenode单点,切换时间太长单点,切换时间太长 没有数据压缩没有数据压缩 NamespaceNamespace过于耗用资源过于耗用资源 HDFS2.0可用性可用性 HDF

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 高等教育 > 其它相关文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号