快乐的猪头 » 日志 » 大规模数据处理
大规模数据处理
flyzhang 发表于 2008-05-28 12:08:19
根据我的经验和对US某大型网站的资料阅读，认为大规模数据处理主要可以分为两部分：
- 基于任务的数据文件处理
- 基于流的数据文件处理
- 基于任务的数据文件处理
1. 关系型数据库群
– Share Everything
• Oracle RAC
• 目前广泛的应用在各大网站Web数据流分析体系中
• 个人观点
– 该模型适合性能要求非常高的OLAP操作
– Share Nothing
• PostgreSQL+PL/Proxy+PGBouncer
• Skype的应用
• 优点：
– 应用和数据库服务器结构独立。
– 负载均衡，失败恢复对于程序是透明的
• 缺点：
– 不能在数据分区间进行join和其它数据库操作
• 个人观点
– 该模型适合性能要求非常高的OLTP操作
2. Map-Reduce模型
• 计算模型
– “分”而“治”之
• 先把数据分成独立互不干涉的原子单元，独立对其进行处理，从而可以让计算能够高度并行
• 根据处理结果，按照“key”聚类后进行“规约”计算
– Functor编程类比
• STL (C++)或者Java中对容器进行排序或者查找，在调用sort或者search算法的时候，需要实现的Comparator（）就是一个 Functor，编程人员可以不用关心排序、查找的具体逻辑和算法，只需要根据自己要求定义好Comparator就可以完成排序、查找的任务了
– Map，Reduce/Combine
• 数据存储模型
– 分布式文件系统
• 构建于现有单机操作系统的文件系统上
• 通过对大文件的二次切分，然后将切分后的文件分布到系统节点上
• 将切分和分布的meta信息管理起来，实现一个文件读写的代理接口来提供分布式的文件服务
• Hadoop实现
– HDFS
– Map/Reduce
• 向SQL的语义融合
– Pig
– HBASE
• 模型的局限性
– 不能提供实时的操作
• Hadoop实现还不能提供分布式的流服务，只能通过独立任务提交的方式完成
- 基于流的数据文件处理
• 生产流水线
– 数据的前期处理（主要是ETL和简单聚集操作）和生产流水线操作非常类似：
• 数据单元间的处理是独立的
• 对于处理的每一阶段，都是一个独立且固定的生产工序
• 基于流的数据收集
– Apache+Spread 基于广播的实时收集方式
StreamDB
– 流数据库的目的
• 近实时的进行大量数据的聚集操作，并展现
– 一个实现
• 基于PG 7.4 的Stream Database ：TelegraphCQ（from 伯克利大学）
- 我们面临的问题
• 缺乏大吞吐量、高扩展性的“单元数据块流”的并行独立处理框架，个人认为可以和OLTP需求类比
• 缺乏大吞吐量的OLAP工具
• 个人观点
– 大规模的数据处理可以分为三个阶段：
• 上下文无关的单元数据块处理+简单聚集汇总处理
• 复杂的数据块间的关联分析和关系抽取
• 对抽样数据集进行复杂的数据挖掘
– 可选择的工具：
• Hadoop或pgCluster
• RDB（Oracle RAC, postgreSQL……）
• 专业的数据挖掘工具（SPSS、SAS等）
– 核心：
数据仓库模型和计算在不同技术间的合理分布：
通用的分布式处理框架完成计算繁重但相对固定的算法，关系型数据库完成计算量适中但逻辑复杂并更新频繁的算法
相关日志:
收藏:
QQ书签
del.icio.us
订阅:
Google
抓虾
