| « | may 2026 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | |
|
公告 |
| 暂无公告... |
| Blog信息 |
|
blog名称:
日志总数:32
评论数量:9
留言数量:-1
访问次数:113172
建立时间:2008年12月3日 |
| |
|
 大规模数据处理漫谈【1】 
软件技术, 电脑与网络
liangbin 发表于 2009/6/6 7:38:43 |
|
大规模数据处理是什么？ 大规模数据处理我认为就是在有限的机器资源的情况下，通过软件和硬件共同完成的G以上级别的数据计算和存储。 北大已经开了这么课程，可见重要性。 http://net.pku.edu.cn/~course/cs402/CC_Syllabus-0.3.pdf
大规模数据处理有哪些应用场合？ （1）搜索引擎，搜索引擎需要存储数10亿的有效网页，并进行快速的全文检索，这是最主要的战场。 （2）数据挖掘，日志分析，商业智能等，业务上产生的大规模日志需要进行有效地加工和分析，使用传统的通用结构化查询数据库已经很难满足特定的业务需要。 （3）科学计算，一般是那些复杂的大数据量的并行计算场合。 如何掌握大规模数据处理的各种技术？ （1）理解使用的机器和操作系统。 （2）理解业务的特性。 （3）将特定机器和特定业务发挥到极致的计算程序。
首先我们看一下我们平常使用的机器（下面进入细节） 磁盘和文件系统 现代磁盘一般被抽象为一个线性的块数据组，在顺序访问块的情况下，可以认为寻道时间是某个固定值（大约10ms左右），传输时间大约是10-100ms/MB,磁盘的外延到内延的访问速度线性递减，外延部分是读写最高效的部分。 多个盘块可以通过RAID 0的方式组在一起，在寻道时间不变的情况下，大大提高了传输数据量（可以看做是并发的磁盘访问），但是RAID 0没有冗余，数据不安全，中间计算过程使用比较适宜。RAID 0可以有硬件和软件的方法，使用硬件的方法在使用时节省更多的ＣＰＵ时间。 大规模数据处理的场合，以处理日志为例，一般均为顺序处理，通常采用异步，直接ＩＯ的方法进行处理，异步的磁盘访问在内核２.? 一些其他的技巧，在大规模数据处理的过程中，基本的模型是read process write。整个过程中总是有读有写的，因此读写分离很重要，读盘和写盘不要是同一个盘，可以用iostat命令实时查询当前磁盘使用状况。 磁盘和文件系统，不同机器参数都不同，可以采用hdparam等方法进行检测和优化。必须充分了解所使用机器的特性，能够估计出执行程序大致的耗时，才可能优化到得极限。
今天就写到这里，下一次写内存。
转自水木http://www.newsmth.net/bbstcon.php?board=SearchEngineTech&gid=14649&start=14649&pno=1
我自写自转 |
|
|
回复:大规模数据处理漫谈【1】
软件技术, 电脑与网络
liangbin发表评论于2009/6/6 7:42:06 |
| 【我的回复】
磁盘的访问时间 = seek time + rotational delay + transfer time机械臂平移最慢（寻道），选择块较快（旋转速度快），传输数据时间更快。寻道时间是扫过磁道（柱面）的一个函数，扫过磁道跨度越大时间越长（但不是线性关系），一般经验值差不多10ms。更好的磁盘这个数值还要低一些。一般期望是旋转半圈找到指定块，按照1万RPM算，则半圈的时间为 60000ms/（10k*2） = 3ms传输时间，对于磁盘这种块设备（区别于字符设备），传输都是按块传输，因此一般认为是block_size/t。t是这种设备的读写速度，按照t = 10M/second 计算，每块按4k字节算(可以用tune2fs命令查看设备的实际block_size)，读取一个块需要 4k/10M = 0.4ms因此寻道时间是起主导作用的。磁盘最好的方法就是顺序读写了，最坏的情况下，也就是从第n柱面跳到第n+1柱面(柱面从最外延编号最低0，到最内延编号最大，分区的柱面号可以通过fdisk -l查看）。 |
|
|
回复:大规模数据处理漫谈【1】
软件技术, 电脑与网络
liangbin发表评论于2009/6/6 7:40:28 |
| [网友精彩回复]
发信人: ScienceHack (但问耕耘莫问收), 信区: SearchEngineTech标 题: Re: 大规模数据处理漫谈【1】发信站: 水木社区 (Fri Jun 5 00:15:30 2009), 站内既然有高人开了头，那么我就捧场助个兴，插嘴两句：大规模数据处理其实就是 SIGMOD 这个组所研究的问题，由于现代计算机科学中各个功能逻辑已经分工明确了，因此 大规模数据的组织与管理基本上成了研究数据据的人的专门学问。 以致在工业界，当某种应用需要用到大规模数据的管理时，人们会直接想到上数据库系统，把这个任务交给数据库来完成。而现代成熟的工业应用级数据库几乎全都是关系数据库，关系数据库固然很美，E.F.Codd等人发展的关系代数的理论完善,Jim Gray等人所作的事务处理的研究也是炉火纯青。但是，一方面 关系数据库并不适用于所有的数据管理的问题，尽管C.J.Date曾经证明，所有的数据结构都可以被关系模型表达，但是能使用关系模型是一回事，使用它是不是最优方案则是另一回事；另一方面，即使一个数据集适合使用关系数据库来管理，怎样根据数据的应用特点来获得数据存取的最高性能仍然是一个精深微妙的问题。很多人一谈到数据管理，即把其视为数据库的工作而已，不愿深究其奥妙。实则很多情况下，使用数据库系统是不过是“杀鸡用牛刀”，若用一个精心设计的专用的数据存储结构和访问方法往往可以收到更好的效果，特别是在性能关键的领域。这就是为什么google没有使用任何成熟的商业关系数据库实现来作为其数据管理的基础，而是采用了自己实现的类似于分布式哈希表的Bigtable的原因之一。关系数据库的日志，错误恢复，一致性与完整性约束等特性的实现是以性能牺牲为代价的，在Web服务的环境下，有时候最基本的要求是将处理时间降到一个交互用户可以接受的水平，这种情况下，关系数据库能提供的帮助非常有限。大规模数据的管理并不神秘，也不特别复杂。其题眼大概在两个方面，一个是外存速度，另一个是好的访问方法，即数据索引。前者决定着存取单位容量的数据需要的时间，后者决定着确定如何最快地找到需要存取的数据。前一个问题基本决定于现有的磁盘结构：温彻斯特机械硬盘；后一个基本是VLDB等会议上不断讨论的主题：设计一个更快的索引结构。目前所有的数据库的物理存储设计都是围绕着机械硬盘的特性来作优化的，机械硬盘的特性就是 寻道时间主导着存取时间，不管读多少数据（在现代硬盘上一次读512B ~ 600KB数据所用时间是差不多的），一次存取时间可以看作是一个常值。所以以存取次数来确定输入输出性能这种考察方法被广泛接受。一次写不了那么多，有时间再写吧，不过我强烈推荐大家看几本书，都是讲的数据管理的根本上的道理：M.A. Weiss， Data Structures and Algorithm AnalysisJeffrey D. Ullman, Database system implementation之所以推荐这两本是因为，我是看这两本书入门的 |
|
» 1 »
|