Hadoop 协议处理器
相关注释文件为:
org/apache/hadoop/fs/FsUrlStreamHandlerFactory.java
org/apache/hadoop/fs/FsUrlStreamHandler.java
org/apache/hadoop/fs/FsUrlConnection.java
1 引入Hadoop 中通过集成 FileSystem 抽象类,使其能在不同的文件系统中可移植,要从 Hadoop 文件系统中读取文件,最简单的方法是使用 java.net.URL 打开数据流,从中读数据。
无论是 JAVA 原生的 File 类还是 Hadoop 的 FileSystem 类,他们在将文件对象转换成对应 URI(Uniform Resource Identifier, 统一资源标识符) 时的方法都继承了 java.io.Serializable。所标识的资源可以是文件,也可以是电子邮件地址等。如绝对 URI 由 URI 模式和模式特有部分组成,它们之间由冒号隔开,常用的模式有: file, http, hftp, mailto, telnet, hdfs, har, s ...
LSM-Tree 概述
摘要
相比于传统的 in-place updates,LSM-Tree 第一次写入都会缓存到内存中,通过后台的 flush 顺序追加到磁盘里,即 out-of-place update
LSM-Tree Basic回顾 LSM-tree 历史,讨论 LSM-Tree 结构,对 LSM-Tree 的写入/读取/空间利用作成本分析。
Historyindex-structure 分为就地更新和非就地更新两种。
图 a 直接覆盖旧记录,这种设计会牺牲写入性能,因为更新会导致随机 I/O,并且索引页通过更新和删除操作会产生分段,降低了空间利用率
为什么会导致随机 I/O?
图 b 将更新变化存储到新位置,不覆盖旧条目。这样设计利用顺序 I/O 来处理写操作,可以提高写性能;不覆盖旧数据,简化了恢复过程。
但是其存在的问题是:记录可能存储在任何位置,会牺牲读取性能。因此 out-of-place 结构通常需要单独的数据重组来提高存储/查询效率。
顺序进行非就地更新的想法在80年代已用于 log-structure ...
LevelDB 源码分析 (二)
内存管理 - Arena内存频繁创建和释放的地方一定会有内存池的出现,如在 levelDB 中 im/memtable 组件中,会有大量内存创建(数据的持续 put)和释放(dump到磁盘后释放内存)。其基本原理为:
levelDB 中内存管理的 component 为 Arena,其成员变量在 arena.h 中,log_format.h 中规定其块大小为 4K: kBlockSize=32768。
在实现 Arena (arena.cc)中,当内存剩余字节数小于所需分配时,根据所需分配字节是否大于 $kBlockSize/4$ 来确定是否需要使用当前块的剩余字节。
引用计数levelDB 中,memtable/version 等组件可能被多个线程共享,不能直接删除。而是需要等到无线程占用时,才能删除。
Key 和 Compare前置知识
SequenceNumber
递增的 uint64 整数,相同 key 按照其降序,最大值为:
123// We leave eight bits empty at the bottom so a type ...
LevelDB 源码分析 (一) | 前沿和基本组件
What is LevelDBLevelDB 是 KV 型数据库,为 BSD 协议,为 Leveling+分区 实现的 LSM 代表,适合写多读少。
特性
Key Value 支持任意 Byte 类型数组,不单单支持字符串
为持久化存储的 KV 系统,大部分数据存在磁盘上
按照 key 值顺序存储数据,按照用户定义的比较函数进行排序
操作接口简单,包括写/读记录以及删除记录,也支持针对多条操作的原子批量操作
支持 snapshot,读写操作互不影响
支持 snappy 压缩,I/O 效率高
源码编译
直接 clone
1git clone https://github.com/google/leveldb.git
initialize submodule issues#1004
12345# 一步到位git clone --recurse-submodules https://github.com/google/leveldb.git# without re-cloninggit submodule update --init --recursive
编译
...
Reading | 存储上的软硬件协同
存储上的软硬件协同Introduction
CPU 和 Memory 的 gap 越来越大,目前朝着多核发展有所缓和,但还是有很大的 gap
Disk 速度更慢,目前用一些软件方法来解决如操作系统将经常使用的数据存储在主存中,相比访问磁盘提高了访问速度
毫无疑问,主存是目前系统的瓶颈:
RAM 硬件设计 (速度和并行化)
内存控制做更优的设计
CPU caches
DMA for devices
现代硬件 (07年) - Commodity Hardware TodayIntro
除了 DDR4 还在发展,07 年的硬件和现在没有什么区别
最初的系统分为南北桥,北桥为 CPU 和内存控制器的接口,南桥主要为 I/O 的接口。
这种设计会有很多限制:
与 RAM 之间的通信都需要通过北桥
CPU 间的通信需要通过北桥上的同一总线
RAM 只有一个接口
改进设计: 将北桥与外部内存控制器作分离的设计,这样可以增大带宽
这样的设计瓶颈为北桥带宽
NUMA - 非一致性内存架构
CPU 相互通信也有一定成本
RAM Types分为 SRAM 和 ...
Reading | CDBTune
Reading - CDBTuneSummaryCDBTune 是一个帮助云数据库智能调优的工具,也是最先通过强化学习来找到调优策略方向的 Auto Tuning Tool。
CDBTune 的 contributions 主要为:
First end-to-end automatic database tuning system.
Use limited number of samples to learn the best knob settings by try-and-error manner in RL.
Design a new reward function in RL, accelerates the covergence speed.
Use DDPG(Deep Deterministic Policy Gradient) method to find the optimal configurations in high-dimensional continuous space.
Good adaptability and outperforms DBA and O ...
Reading | Google File System
IntroGFS 设计前的观察 :
设备故障经常发生,GFS由许多台廉价设备作为存储节点组成,设备数量和质量决定任何时间都有部分设备无法工作,甚至有些设备会无法恢复。
文件越来越大。需要重新考虑 I/O 操作和 Chunk 大小的参数设计
大部分文件变更是以 Append 而非 Overwirte。
放宽一致性协议,能大幅简化系统,减少应用程序负担,
Design假设 Assumptions
系统由经常发生故障的廉价商用设备组成,而系统能持续监控自身并检测故障、容错和及时恢复的能力。
系统存储一定数量的大文件,但也能支持小文件
Workload 主要源于两种 Read 操作: 大规模的流式读取和小规模的随机读取。大规模中同一个 Client 端连续读操作会经常访问同一个区域,小规模中会在文件某个任意偏移位置读几KB
Workload 还来自很多文件的大规模 Append 写入。一般情况下当写入规模与读取规模相似时,文件一旦写入就不会被修改。
文件通常在 Producer-Consumer 队列中或 Multi-way Merge 中使用。因此最小化原子性需要的同步开销非常 ...
Reading | OtterTune
Ottertune 阅读Summary
Ottertune 为一个用于数据库的参数配置自动化工具,调优过程由三个步骤组成:
Workload Characterization ( Workload 特征采集/分析 ): 确定最能代表 target workload 的 metrics
Knobs affect metrics.
FA (factor analysis): 将 high-dimensional DBMS metric data 转为 low-dimensional data
K-means: Cluster thest lower dimensinal data into meaningful groups.将这些低维因子分组
**Knob Identification (重要参数分析): ** 使用 Lasso 方法确定 Knobs 的重要级排序
计算出哪些参数对性能影响最大及参数间的关系
Automatic Tuner (自动调优)
Step#1 - Workload Mapping: 根据已经挑选出的一组metrics,匹配 ta ...
How to read a paper?
How to read感觉自己读论文不是很高效,一篇论文看一个白天,方法什么的在路上也很难全部说出来,此篇不断记录我是如何看论文的 (我应该如何看论文)
所有借鉴过的方法都会在引用给出,感兴趣可以点击康康。
Abstract
Why: purpose of this work
How: method employed
What: result they discovered
Conclusion: Meaningful?
Introduction
如果是小白,好好看
如果是老鸟,skip or read the first/last paragraphs.
Catch one’s attention.
Explain the research context.
From broad topic to sprcific issues to focused core questions.
Results and Discussion
What they found
Vital data, figures and tables
Must understand how t ...
系统研究的一点思考
不仅仅是科学
Computer System: Science + Engineering + Art
Science
Measure and quantitate existing phenomenon
Building models to understand the world
Engineering
Building useful systems and tools
做有用的工作
We build stuffs with flexibility
Reinvent a wheel
主要挑战: 复杂性
设计架构 + 实现
目标: STEADY开发: T-imely
性能: S-imple, E-fficient, A-daptable
功能: D-ependable, Y-ummy
容错: D-ependable
研究驱动力
工艺与硬件的变化
技术创新的进步
应用模式的变化
“埋头拉车” + “抬头看路”
埋头拉车: 在一个领域内埋头苦干, 深入钻研
Get hands dirty
Understand even the gory details
抬头 ...