阿里云元数据（yum 阿里云源）
本文目录一览：
元数据性能大比拼：HDFS vs OSS vs JuiceFS
存储是大数据的基石，存储系统的元数据又是它的核心大脑，元数据的性能对整个大数据平台的性能和扩展能力非常关键。本文选取了大数据平台中 3 个典型的存储方案来压测元数据的性能，来个大比拼。
其中 HDFS 是被广为使用的大数据存储方案，已经经过十几年的沉淀和积累，是最合适的参考标杆。
以 Amazon S3 和 Aliyun OSS 为代表的对象存储也是云上大数据平台的候选方案，但它只有 HDFS 的部分功能和语义，性能也差不少，实际使用并不广泛。在这个测试中对象存储以 Aliyun OSS 为代表，其他对象存储类似。
JuiceFS 是大数据圈的新秀，专为云上大数据打造，是符合云原生特征的大数据存储方案。JuiceFS 使用云上对象存储保存客户数据内容，通过 JuiceFS 元数据服务和 Java SDK 来实现 HDFS 的完整兼容，不需要对数据分析组件做任何修改就可以得到跟 HDFS 一样的体验。
Hadoop 中有一个专门压测文件系统元数据性能的组件叫 NNBench，本文就是使用它来做压测的。
原版的 NNBench 有一些局限性，我们做了调整：
我们使用了 3 台阿里云 4核 16G 的虚拟机来做压力测试。CDH 5 是目前被广泛使用的发行版，我们选用 CDH 5 作为测试环境，其中的 HDFS 是 2.6 版本。 HDFS 是使用 3 个 JournalNode 的高可用配置，JuiceFS 是 3 个节点的 Raft 组。HDFS 使用内网 IP，JuiceFS 使用的是弹性 IP，HDFS 的网络性能会好一些。OSS 是使用内网接口访问。
先来看看大家都熟悉的 HDFS 的性能表现：
此图描述的是 HDFS 每秒处理的请求数（TPS）随着并发数增长的曲线，有两个发现：
再来看看 OSS 的性能情况：
[图片上传失败...(image-5b3536-1644394129139)]
OSS 速度比 HDFS 慢了一个数量级，但它的各种操作的速度基本保持稳定，总的 TPS 随着并发数的增长而增长，在 80 个并发下还没遇到瓶颈。受测试资源所限，未能进一步加大压测知道它的上限。
最后看下 JuiceFS 的表现：
从图中可以看出，整体趋势和 HDFS 类似，Open/Read 和 Delete 操作明显比 Create/Rename 快很多。JuiceFS 的 TPS 也是在 20 个并发以内基本保持线程增长，之后增长放缓，在 60 个并发左右达到上线。 但 JuiceFS 增幅更快，上限更高 。
为了更直观的看出这三者的性能差异，我们直接把 HDFS、Aliyun OSS 和 JuiceFS 放在一起比较：
[图片上传失败...(image-10c829-1644394129139)]
可见无论是哪种元数据操作， JuiceFS 的 TPS 增长更快，上限也更高 ，明显优于 HDFS 和 OSS。
一般我们在看一个系统的性能时，主要关注它的操作时延（单个操作所消耗的时间）和吞吐量（满负载下的处理能力），我们把这两个指标再汇总一下：
[图片上传失败...(image-a6e611-1644394129139)]
上图是 20 个并发下的各操作的时延（未跑满负载），可以发现：
上图是 80 个并发时的吞吐量对比，可以发现：
从以上两个核心性能指标来看，对象存储不适合要求性能的大数据分析场景。
阿里云oss对象存储是什么意思？
“对象存储”或“基于对象的存储”一词是由它的名称派生出来的，因为它将数据和元数据封装到对象中。元数据本质上是描述其他数据的数据，或者在基于对象的存储的情况下，是关于通常存储在对象内的文件的信息。
对象存储在平面结构或地址空间中。每个对象都分配一个对象ID或唯一标识符，使它们可以从单个存储库或存储池中检索。企业非常重视这种方法，因为它提供了更大的灵活性，可以将数据放置在基于数据块和文件的存储解决方案之外。
杉岩海量对象存储针对海量非结构化数据存储的最优解决方案，采用去中心化、分布式技术架构、支持百亿级文件及EB级容量存储，具备高效的数据检索、智能标签和分析能力，轻松应对大数据和云时代的存储挑战，为企业发展提供智能决策！
壮实学数据技术07：元数据
hi，米娜桑，我是大家的怪力少女赵壮实！
又是一个美好的周六的早上，今天我们来聊聊——元数据！
元数据也是近两年才火热起来的产品岗位和概念，因为偏向于后侧，相比于数据分析、数据BI、用户分层、归因等酷炫的名词下，元数据就像一朵白莲花。
01 什么是元数据？
好吧，元数据为什么可以睥睨一切呢？因为它是“元”数据。
啥是“元数据”——metadata？
壮实见到这个词语，第一次流下了久别重逢的泪水，甚至有点想笑，莫非，元数据，是一位熟悉现代主义思潮的大佬起的名字？
好的，壮实先从人文视角解释一下什么叫做“元”。
元，依旧指的是原始、原初的意思。我们那元叙事、元数据、元小说给大家讲讲什么是“元”。
1.“元”+“叙事”=元叙事
对于叙事的完整解释，即对历史的意义、经历和知识的叙述
2.“元”+“数据”=元数据
有关于数据的数据
3.“元”+“小说”=元小说
元小说，作家自觉地暴露小说的虚构过程，产生间离效果，进而让接受者明白，小说就是虚构，不能把小说当作现实。这样，虚构在小说中也就获得了本体的意义。
好吧，简单来说，元就是这个东西原始的框架、元素。在现代主义大工业的背景下，人类一切进入了“秩序模式”，所以需要“元”。所以就有了万物“元”化。
是的，大家是不是最近还会听到一个词，叫做“元认知”。没什么神奇的，套用概念，元认识就是关于认知的认知，也许善友老师“第一性原理”和叫兽“时间的朋友”或许是“元认知”？
那元数据，我们就好理解了，就是“关于数据的数据”，有了元数据，它可以让我们的数据生产、使用更加秩序化。
数据生产，有的人会叫做“后台元数据”：指导数据清洗装载工作。
数据使用，有的人会分为“前端元数据” ：描述性、帮助我们更加流畅的使用报表和查询工具。
对于元数据的分类，我们可以分为以下三类:
业务元数据 从业务层面描述元数据。
技术元数据 数据技术层面上的各种统计信息，包含数据类型、长度、血缘沿袭、数据剖析结果等。
处理过程元数据 ETL自身执行结果统计信息，如多少行被加载、多少行数据被丢弃以及数据加载时间等。
02 元数据核心理念和关键要素
话不多说，我们来上阿里云官方ppt：
好的，如果你们看不懂，壮实还画了一个图：
原来的数据生产-使用流程
涉及的相关的元数据
03 元数据产品
目前国内的元数据管理工具大概有三类。
一是像IBM、CA等公司都提供的专门工具，比如IBM收购Ascential得到的MetaStage，CA的DecisionBase；
二是像DAG的MetaCenter，开源产品Pentaho Metadata，它们不依托于某项BI产品，是一种第三方的元数据管理工具；
开源产品Pentaho Metadata示意图
三是像普元、石竹这样的集成商也有自己的元数据管理工具：普元MetaCube、新炬网络元数据管理系统、石竹MetaOne等。
普元元数据驱动的微服务架构：
新炬网络元数据管理系统：
;c=indexa=listscatid=188
石竹MetaOne产品图：
专门的元数据管理工具，对自家产品兼容较好，一旦涉及跨系统管理，就不尽如人意了。
04 元数据的功能和价值
如果你问我，元数据的功能和价值在哪里？目前，业界开展了一些实践：
1、血缘分析：向上、向下表级、字段级别的追溯数据。血缘分析可以让您轻松知道：“我正在查看的报告数据来源是什么？”、“数据经过哪些转换处理？”、“销售额”从包含税费更改为不包括税费，哪些下游字段受到了影响。血缘分析可以满足许多行业(包括医疗、金融、银行和制造业等)对所呈现数据的特殊监管及合规性要求。
2、指标一致性分析：定期分析指标定义是否和实际情况一致。大佬会上对不齐数据是何等的尴尬。。。。
3、实体关联查询：事实表与维度表的代理键自动关联。
05 后记
打破一切：从人文后现代主义到数据后现代主义。
20世纪60年代，德国、法国、美国等出现了反西方近现代体系哲学倾向的思潮，学术上称之为“后现代主义”。你也许不知道啥是后现代主义，来一张图感受一下：
对！就是达利的《记忆的永恒》。
后现代主义就是一种用无序反对有序，用个人呓语反对宏大叙事、用解构反对结构的一种精神。
当代美国活跃的后现代主义者之一格里芬就说：“如果说后现代主义这一词汇在使用时可以从不同方面找到共同之处的话， 那就是，它指的是一种广泛的情绪，而不是一种共同的教条———即一种认为人类可以而且必须超越现代的情绪。”
所有理论的背后，都是这个时代的主流认知+情绪。数据也不例外。我们来看看《壮实学数据技术01》中的数据仓库两位大佬之争，就知道人们在反复横跳在秩序和速度中。
所以，我们今天要考虑，元数据在今天的合理性是什么？
在杂乱数据被管理起来之后，是不是在复杂、程式化上需要做做减法？
数据多≠信息多。如何把数据变为信息，是每一个数据人需要持续思考的事情。
阿里云可以测绘数据不
可以。
数据地图是在元数据基础上提供的企业数据目录管理模块，涵盖全局数据检索、元数据详情查看、数据预览、数据血缘和数据类目管理等功能。数据地图可以帮助您更好地查找、理解和使用数据。
发表评论
暂时没有评论，来抢沙发吧~