文档介绍：文档名
部门结构
运维团队（负责管理维护集群的正常运行）
数据仓库团队（根据业务部门的要求进行数据统计和查询）
成都研究院（负责底层，包括源代码修改和按上层部门要求开发Map-Reduce程序，比如一些UDF）
文档名
部门结构
运维团队（负责管理维护集群的正常运行）
数据仓库团队（根据业务部门的要求进行数据统计和查询）
成都研究院（负责底层，包括源代码修改和按上层部门要求开发Map-Reduce程序，比如一些UDF）
Hadoop在淘宝和支付宝的应用
从09年开始。用于对海量数据的离线处理，例如对日志的分析，也涉及内容部分，结构化数据
主要基于可扩展性的考虑
规模从当初的3-4百节点增长到今天单一集群3000节点以上，2-3个集群
支付宝的集群规模也达700台，使用Hbase，个人消费记录，key-value型
对Hadoop源码的修改
改进Namenode单点问题
增加安全性
改善Hbase的稳定性
改进反哺Hadoop社区
管理模式
集团统一管理
Hadoop运维团队
Hadoop开发团队
数据仓库团队（Hive）
准实时的流数据处理技术
从Oracle, Mysql日志直接读取数据
部分数据源来自应用消息系统
以上数据经由Meta+Storm的流数据处理，写入HDFS，实现实时或准实时的数据分析
数据装载到Hive进行处理，结果写回Oracle和Mysql数据库
淘宝数据魔方
架构图
架构图
架构分为五层，分别是数据源、计算层、存储层、查询层和产品层。
数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。
在数据源层实时产生的数据，通过淘宝主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到Hadoop集群“云梯”，是计算层的主要组成部分。在“云梯”上，。
一些对实效性要求很高的数据采用“云梯”来计算效率比较低，为此做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。
架构图
“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。
针对前端产品设计了专门的存储层。在这一层，有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集***rom。
Myfox
数据查询过程
Myfox
节点结构
Prometheus
Prom的存储结构
Prometheus
Prom查询过程
glider
glider的技术架构
glider
缓存控制体系
量子恒道
Oceanbase
Oceanbase
分布式的结构化存储系统，采用强schema的形式，其数据是分布在多个数据节点上，并将读写数据做了完全的隔离。
OB的数据节点分两种，一类是基准数据节点(!ChunkServer)，存储引擎是基于SSTABLE 。 一个是增量数据节点(!UpdateServer)，存储引擎是基于Btree(内存中的memtable)和SSTABLE(major-freeze-dump)的。
基准数据：从开始至某个时间点的全量数据，是静态数据，在到下一个时间点合并之前，该部分数据不会发生变更。
增量数据：是指从某个时间点至当前范围内新增的数据，增量数据会因为应用的各种修改操作(insert,update,delete)发生变更。
整体数据分布
数据演进过程
sstable的总体数据格式
sstable中data block的排列规则
sstable中的schema排列规则
******@Baidu
日志的存储和统计;
网页数据的分析和挖掘;
商业分析，如用户的行为和广告关注度等;
在线数据的反馈，及时得到在线广告的点击情况;
用户网页的聚类，分析用户的推荐度