元数据

1.linux系统中一切皆文件： 文件系统及目录结构： /boot：引导文件存放目录，内核文件(vmlinuz)、引导加载器(bootloader, grub)都存放于此目录  /bin：所有用户使用的基本命令；不能关联至独立分区，OS启动即会用到的程序  /sbin：管理类的基本命令；不能关联至独立分区，OS启动即会用到的程序  /lib：启动时程序依赖的基本共享库文件以及内核模块文件(/lib/modules)  /lib64：专用于x86_64系统上的辅助共享库文件存放位置  /etc：配置文件目录  /home/USERNAME：普通用户家目录  /root：管理员的家目录  /media：便携式移动设备挂载点 /mnt：临时文件系统挂载点  /dev：设备文件及特殊文件存储位置  /tmp：临时文件存储位置 # 2.lsblk-列出系统的硬盘 du -sh 查看文件大小 pwd-显示当前目录 --echo '- - -' > /sys/class/scsi_host/host0（host2）/scan --虚拟机增加硬盘命令 --/proc /sys -进程目录 目录颜色：蓝色-目录，yellow-硬件目录，粉色-套接字，棕色-管道文件，l绿色-可执行文件，红色-打包或压缩文件 --定义颜色文件路径：/etc/DIR_COLORS --除了斜杠和NUL

自然框架在线演示： http://pthuanyu.com/ 【自然框架】PowerDesigner 格式的元数据的表结构 自然框架的源码、Demo、数据库、说明文档的下载，还是老地方： 自然框架的源代码、Demo、数据库、配置信息管理程序下载（2010.02.21更新） 　1、　 Manage_Function（ 节点信息 ） 　　 字段名 中文名 类型 大小 默认值 说明 FunctionID 节点ID int 4 1 主键 ParentID 父节点ID int 4 1 员工姓名 ParentIDPath 父节点ID的路径 nvarchar 30 _ 添加、修改时使用 NoteTitle 节点名称 nvarchar 100 _ 节点名称 PowerMark 权限标识 nvarchar 50 _ 一般情况下等于FunctionID NoteLevel 级数 int 4 1 第几级节点 IsShowNote 节点是否显示 bit 1 1 功能节点里面是否显示 IsShowPower 角色是否显示 bit 1 1 角色选择是否显示 Sort 排序 int 4 1 排序。全部节点的总排序 WebURL 网址 nvarchar 100 _ 打开网页的网址 Target 目标 nvarchar 10 _ 目标 这个表就是元数据的“支柱”了。记录了一个项目里都有哪些功能，功能对应的页面

文章目录 一、Fabric账本 二、区块链 2.1 区块信息 2.2 交易信息 三、世界状态 一、Fabric账本 Fabric账本是有序的、不可篡改的状态转换记录，包括区块链（Blockchain）和世界状态（World stat）两部分。 区块链中保存着不可变的顺序记录，包含配置记录，例如channel的配置；还包含全部交易记录； 世界状态中维护账本的当前状态，方便Appication快速查询 二、区块链 区块链是一个历史交易记录，记录着所有数据对象是如何到达当前状态的。 下图中有4个区块B0、B1、B2、B3，第一个区块B0为创世区块（genesis block），保存一些配置信息，包括Order、peer的信息和证书信息；后面的区块B1、B2、B3则保存着后续交易信息： 2.1 区块信息 区块分为3部分，分别为区块头（Block header）、区块数据（Block Data）、区块元数据（Block Data）： 区块头里面包含区块序号（Block number）、当前区块哈希（Current Block Hash）、上一个区块哈希（Previous Block Hash）， 区块数据就是一系列交易数据； 区块元数据主要包含区块写入时间、写入的人以及签名。 2.2 交易信息 交易（Transaction）保存着捕获的关于交易的一些基本元数据： transaction

NN和2NN工作机制 NameNode中的元数据是存储在哪里的？ 首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。 这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。 但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。 nn和2nn工作机制 第一阶段：NameNode启动 （1）第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动

Java中锁分类 锁的分类 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁（java.util.concurrent包下的几乎都是利用锁） CAS 它是解决轻微冲突的多线程场景下使用锁造成性能损耗的 一种机制 。先是 比较 ，如果不符合预期，则 重试 。它有三个操作因素： 内存位置 ， 预期原值 与 新值 。如果内存位置的值与预期原值相等，则处理器将该位置值更新为新值，如果不相等，则获取当前值，然后进行不断的轮询操作直到成果达到某个阙值退出。 AQS AbstractQueuedSynchronizer 简称AQS是一个抽象同步框架，可以用来实现一个依赖状态的同步器。JDK1.5中提供的 java.util.concurrent 包中的大多数的同步器 (Synchronizer) 如 Lock, Semaphore, Latch, Barrier 等，它们都是基于 java.util.concurrent.locks.AbstractQueuedSynchronizer 这个类的框架实现的。 乐观锁/悲观锁 乐观锁 :乐观锁是一种乐观思想，认为 读多写少 ，遇到并发的可能性低，每次拿数据时候并 不会上锁 ，因为认为不会被别人修改。但是更新的时候会判断有没有人会更新这条数据，采取写的时候先 读取版本号然后加锁

第1章 HBase简介 1.1 什么是HBase HBase的原型是Google的BigTable论文，受到了该论文思想的启发，目前作为Hadoop的子项目来开发维护，用于支持结构化的数据存储。 官方网站：http://hbase.apache.org – 2006年Google发表BigTable白皮书 – 2006年开始开发HBase – 2008年北京成功开奥运会，程序员默默地将HBase弄成了Hadoop的子项目 – 2010年HBase成为Apache顶级项目 – 现在很多公司二次开发出了很多发行版本，你也开始使用了。 HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群。 HBase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。 HBase是Google Bigtable的开源实现，但是也有很多不同之处。比如：Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google

元数据是用来描述数据的数据（Data that describes other data）。单单这样说，不太好理解，我来举个例子。 下面是契诃夫的小说《套中人》中的一段，描写一个叫做瓦莲卡的女子： （她）年纪已经不轻，三十岁上下，个子高挑，身材匀称，黑黑的眉毛，红红的脸蛋－－一句话，不是姑娘，而是果冻，她那样活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑，动不动就发出一连串响亮的笑声：哈，哈，哈！ 这段话里提供了这样几个信息：年龄（三十岁上下）、身高（个子高挑）、相貌（身材匀称，黑黑的眉毛，红红的脸蛋）、性格（活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑）。有了这些信息，我们就可以大致想像出瓦莲卡是个什么样的人。推而广之，只要提供这几类的信息，我们也可以推测出其他人的样子。 这个例子中的"年龄"、"身高"、"相貌"、"性格"，就是元数据，因为它们是用来描述具体数据/信息的数据/信息。 当然，这几个元数据用来刻画个人状况还不够精确。我们每个人从小到大，都填过《个人情况登记表》之类的东西吧，其中包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等......这一套元数据才算比较完备。 在日常生活中，元数据无所不在。有一类事物，就可以定义一套元数据。 喜欢拍摄数码照片的朋友应该知道，每张数码照片都包含EXIF信息。它就是一种用来描述数码图片的元数据。按照Exif 2

元数据是用来描述数据的数据（Data that describes other data）。单单这样说，不太好理解，我来举个例子。 下面是契诃夫的小说《套中人》中的一段，描写一个叫做瓦莲卡的女子： （她）年纪已经不轻，三十岁上下，个子高挑，身材匀称，黑黑的眉毛，红红的脸蛋－－一句话，不是姑娘，而是果冻，她那样活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑，动不动就发出一连串响亮的笑声：哈，哈，哈！ 这段话里提供了这样几个信息：年龄（三十岁上下）、身高（个子高挑）、相貌（身材匀称，黑黑的眉毛，红红的脸蛋）、性格（活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑）。有了这些信息，我们就可以大致想像出瓦莲卡是个什么样的人。推而广之，只要提供这几类的信息，我们也可以推测出其他人的样子。 这个例子中的"年龄"、"身高"、"相貌"、"性格"，就是元数据，因为它们是用来描述具体数据/信息的数据/信息。 当然，这几个元数据用来刻画个人状况还不够精确。我们每个人从小到大，都填过《个人情况登记表》之类的东西吧，其中包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等......这一套元数据才算比较完备。 在日常生活中，元数据无所不在。有一类事物，就可以定义一套元数据。 喜欢拍摄数码照片的朋友应该知道，每张数码照片都包含EXIF信息。它就是一种用来描述数码图片的元数据。按照Exif 2

1、NameNode中的元数据是存储在哪里的？ 首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。 这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。 但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。 2、NN和2NN工作机制详解： Fsimage：NameNode内存中元数据序列化后形成的文件。 Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据

上篇： 第 6 章 Spark 内存管理 1、BlockManager数据存储与管理机制 BlockManager是整个Spark底层负责数据存储与管理的一个组件，Driver和Executor的所有数据都由对应的BlockManager进行管理。 Driver上有BlockManagerMaster，负责对各个节点上的BlockManager内部管理的数据的元数据进行维护，比如block的增删改等操作，都会在这里维护好元数据的变更。 每个节点都有一个BlockManager，每个BlockManager创建之后，第一件事即使去向BlockManagerMaster进行注册，此时BlockManagerMaster会为其长难句对应的BlockManagerInfo。 BlockManager运行原理如下图所示： BlockManagerMaster与BlockManager的关系非常像NameNode与DataNode的关系，BlockManagerMaster中保存中BlockManager内部管理数据的元数据，进行维护，当BlockManager进行Block增删改等操作时，都会在BlockManagerMaster中进行元数据的变更，这与NameNode维护DataNode的元数据信息，DataNode中数据发生变化时NameNode中的元数据信息也会相应变化是一致的。