<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>数据 on ZRJ | 学习笔记</title>
        <link>https://blog.zrj.me/tags/%E6%95%B0%E6%8D%AE/</link>
        <description>Recent content in 数据 on ZRJ | 学习笔记</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-CN</language>
        <lastBuildDate>Sat, 16 Apr 2016 12:23:51 +0800</lastBuildDate><atom:link href="https://blog.zrj.me/tags/%E6%95%B0%E6%8D%AE/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>元数据管理学习笔记</title>
        <link>https://blog.zrj.me/posts/2016-04-16-%E5%85%83%E6%95%B0%E6%8D%AE%E7%AE%A1%E7%90%86%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/</link>
        <pubDate>Sat, 16 Apr 2016 12:23:51 +0800</pubDate>
        
        <guid>https://blog.zrj.me/posts/2016-04-16-%E5%85%83%E6%95%B0%E6%8D%AE%E7%AE%A1%E7%90%86%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/</guid>
        <description>&lt;p&gt;关于元数据的文章，看到下面的这些算是不错的&lt;/p&gt;
&lt;p&gt;&lt;a class=&#34;link&#34; href=&#34;http://www.ibm.com/developerworks/cn/data/library/bd-1503bigdatagovernance3/index.html&#34;  title=&#34;http://www.ibm.com/developerworks/cn/data/library/bd-1503bigdatagovernance3/index.html&#34;
     target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;http://www.ibm.com/developerworks/cn/data/library/bd-1503bigdatagovernance3/index.html&lt;/a&gt;，大数据治理系列，第三部分: 实施元数据管理&lt;/p&gt;
&lt;p&gt;其中：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;根据元数据管理的成熟度，大体可以分成 6 个级别，具体如图 1 所示： L0: 初始状态 元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用，其他人如果想获得该元数据需要找到相应的人进行沟通获取。 L1: 从属于业务系统 在这个阶段，随着各个业务系统自动化构建完成，相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中，技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中，元数据之间互通互联困难，如果需要获取其他系统的元数据，除了调阅各种文档外，对分散在各种中间件和业务系统中的技术元数据需要通过桥（bridge）的方式实现互通互联。 L2：元数据统一存储 元数据依然在局部产生和获取，但会集中到中央存储库进行存储，业务元数据会手工录入到中央存储库中，技术元数据分散在文档中的部分也通过手工录入到中央存储库中，而散落在各个中间件和业务系统中的技术元数据则通过桥（bridge）的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建，使得元数据在整个企业层面可被感知和搜索，极大地方便了企业获取和查找元数据。缺点是，元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的事情，而同一件事情则使用了多个不同的名字，有些没有纳入业务系统管理的元数据则容易缺失。元数据没有有效的权限管理，局部元数据更改后也不自动通知其他人。 L3: 元数据集中管理 在 L2 的基础上做了改进，增强了元数据的集中控制，局部业务单元或开发小组如不事先通知其他人，将无法对元数据进行修改。局部元数据的修改完成后将被广播给其他人。和其他中间件和应用系统的交互，仍然通过桥（bridge）的方式进行，中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。 L4：元模型驱动管理 在 L3 的基础上，通过构建元模型以及元元模型，优化各业务单元之间的各种冲突和各种副本，创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构，用以对业务术语归类。和其他中间件和应用系统的交换，通过基于 CWM 的适配器方式进行连接。 L5: 元数据管理自动化 在 L5 元数据管理是高度自动化的，当逻辑层次元数据变更时，会被传播到物理层次，同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流，以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统（元模型），他们之间的关系可以通过知识本体进行推断，因此各个应用系统之间的数据格式的映射自动产生。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;另外，这里，&lt;a class=&#34;link&#34; href=&#34;http://webdataanalysis.net/web-data-warehouse/meta-data/&#34;  title=&#34;http://webdataanalysis.net/web-data-warehouse/meta-data/&#34;
     target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;http://webdataanalysis.net/web-data-warehouse/meta-data/&lt;/a&gt;，数据仓库元数据管理，也讲得不错，顺便一提，这个文章所属的博客，也挺不错，同个作者的还有这篇，&lt;a class=&#34;link&#34; href=&#34;http://webdataanalysis.net/web-data-warehouse/data-warehouse-frame/&#34;  title=&#34;http://webdataanalysis.net/web-data-warehouse/data-warehouse-frame/&#34;
     target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;http://webdataanalysis.net/web-data-warehouse/data-warehouse-frame/&lt;/a&gt;，数据仓库的基本架构&lt;/p&gt;
&lt;p&gt;这一篇，&lt;a class=&#34;link&#34; href=&#34;http://webdataanalysis.net/web-data-warehouse/data-warehouse-source-data/&#34;  title=&#34;http://webdataanalysis.net/web-data-warehouse/data-warehouse-source-data/&#34;
     target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;http://webdataanalysis.net/web-data-warehouse/data-warehouse-source-data/&lt;/a&gt;，对结构化数据和非结构化数据做好较好的阐述&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;数据仓库中集成了企业几乎所有的可以获取到的数据以用于数据分析和决策支持，当然也包括了我在网站分析的数据来源一文中所提到的所有数据。这些进入到数据仓库中的数据无外乎三种类型：结构化数据、半结构化数据和非结构化数据，它们经过转化后以某种形式统一地储存在数据仓库中，即通常说的ETL（Extract, Transform, Load，抽取、转换、装载）的过程。下面主要说一下这三种数据类型的区别，它们分别包括哪些源数据以及这些数据在网站数据分析中的作用。&lt;/p&gt;
&lt;p&gt;结构化数据&lt;/p&gt;
&lt;p&gt;　　这类数据的格式非常规范，典型的代表就是关系数据库中的数据，这些数据可以用二维表来存储，有固定的字段数，每个字段有固定的数据类型（数字、字符、日期等），并且每个字段的字节长度也相对固定。这类数据也是最易管理维护的，同时对于查询、展示和分析而言也是最为方便的一类数据格式。&lt;/p&gt;
&lt;p&gt;　　结构化的数据在网站中一般指的是网站内部的数据库数据以及一些外部开放的数据库接口中获取的数据。这些数据可以直接通过ETL导入到数据仓库中进行集成化管理，而在网站分析和数据分析中直接可以根据需要通过SQL语句查询导出。&lt;/p&gt;
&lt;p&gt;　　结构化的数据在网站数据分析中占据着举足轻重的地位，这些存储在数据库中的数据一般都是网站的运营数据及用户操作的结果数据（Outcome），比如网站的注册用户数、博客的文章数、评论数……而对于电子商务类网站而言，那些订单和销售数据也直接的存储与数据库中，而基于这些数据计算得到的总利润、每个订单平均利润、每个用户创造利润等KPI数据可以直接分析网站的目标是否实现。&lt;/p&gt;
&lt;p&gt;半结构化数据&lt;/p&gt;
&lt;p&gt;　　半结构化数据的格式较为规范，一般都是纯文本数据，可以通过某种方式解析得到每项的数据。最常见的就是日志数据、XML、JSON等格式的数据，它们每条记录可能会有预定义的规范，但是可能每条记录包含的信息不尽相同，也可能会有不同的字段数，包含不同的字段名或字段类型，或者包含着嵌套的格式。这类数据一般都是以纯文本的形式输出，管理维护也较为方便，但在需要使用这些数据时，如获取、查询或分析数据时，可能需要先对这些数据格式进行相应的解析。&lt;/p&gt;
&lt;p&gt;　　半结构化的数据通常是指网站的日志数据，或者因为某些需求以XML或JSON格式输出的数据。最常见的就是网站的Apache日志，它根据预定义的字段顺序打出相应的值：&lt;/p&gt;
&lt;p&gt;72.14.192.1 – - [09/May/2010:03:35:02 +0800] “GET / HTTP/1.1″ 200 13726 “-” “Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US),gzip(gfe) (via translate.google.com)” 而JSON格式则会以键值对（Key/Value）的形式输出数据：&lt;/p&gt;
&lt;p&gt;{time: 1234567890, action: “comment”, respond: true, user: {userid: 1, username: “abc”}} 　　对于像Apache日志那样的数据，我们可以根据需要切分出那些有用的数据将它们导入到数据仓库，而xml和JSON格式的数据我们可以调用各类字符串解析的方法通过它们的标签或者名称来获取相应的值，对于嵌套结构可以使用逐层遍历的方法依次获取，同样选取那些对于分析有用的数据存在数据仓库。在这个过程中，ETL中的转换部分会显得较为复杂，因为这里需要进行格式解析，而这一步的优劣直接影响ETL的稳定性和健壮性。还有一个令人头疼的问题就是数据的格式和存放问题，也许有必要创建一些自定义字段类型；或者选择NOSQL数据库，关于NOSQL数据库的讨论一度热火朝天，从Google的Big table、Amazon的Dynamo到Facebook的Cassandra，NOSQL数据库提供了可扩展性的海量数据存储，对于WEB数据管理提供了新的解决方案。&lt;/p&gt;
&lt;p&gt;　　半结构化数据对于网站数据分析同样非常重要，网站的点击流日志及一些用户行为数据一般都是以半结构化数据的形式输出的，当我们需要统计网站分析中的各类指标或者进行用户行为分析时，这类数据就必不可少。&lt;/p&gt;
&lt;p&gt;非结构化数据&lt;/p&gt;
&lt;p&gt;　　非结构化数据指的是那些非纯文本类数据，没有标准格式，无法直接地解析出相应的值。常见的非结构化数据有富文本文档、网页、多媒体（图像、声音、视频等）。这类数据不易收集管理，也无法直接查询和分析，所以对这类数据需要使用一些不同的处理方式。&lt;/p&gt;
&lt;p&gt;　　富文本、图片、声音、视频等这些信息，除非需要进行高级的文本挖掘或者多媒体数据挖掘，否者对于一些日常涉及的数据统计和分析而言，非结构化数据本身是没有分析的价值的。所以一般不会将非结构化数据直接以二进制的形式存入数据仓库，数据仓库之父——Inmon的建议是在数据仓库中只需要储存非结构化数据的元数据（Meta Data），或者称为解释型数据。所以我们一般将非结构化的数据存放在文件系统（File System）中，而在数据仓库里面记录这些数据的信息，以便快速地索引和寻找需要的数据。如Word文档的标题、摘要、作者、创建时间、最近一次修改时间等，而图片则可能还包括像素、分辨率等。就像你右击文件属性的详细信息标签下看到的那些数据项，这些非结构化数据的元数据能够通过标准的形式记录，并且能帮助快速地搜索查询到对应的非结构化数据，同样可以被用于统计和分析，其实就是给每个非结构化数据贴上了标签，并将标签信息记录到了数据仓库中。&lt;/p&gt;
&lt;p&gt;　　可能对于大多数网站而言，这类非结构化数据除非被用于高级的数据挖掘，在大部分时间中它们对数据的统计分析作用并不大，但对于某些网站，比如图片、视频类网站，这些数据就至关重要。对于图片、视频网站而言，每个图片和视频就是网站的产品，而记录图片视频的元数据就是这些产品的详细信息数据，产品分析、产品细分等都依赖于这些数据；同样，对于一些公司的内部归档的文档、资料而言，如果有数据仓库统一地记录这些文件的信息，就能够在必要时快速地搜索找到需要的文件，对于信息的统一集成化管理非常有效。&lt;/p&gt;
&lt;p&gt;　　随着互联网的不断发展，各类信息不断膨胀，还有各式各样的数据类型会不断涌现，而数据仓库扮演着数据集成者的角色，对于各类数据的处理和管理也将不断地改进优化。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;在这一页中，&lt;a class=&#34;link&#34; href=&#34;http://doc.xuehai.net/b99d1ea974a953d8c5ab91561-12.html&#34;  title=&#34;http://doc.xuehai.net/b99d1ea974a953d8c5ab91561-12.html&#34;
     target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;http://doc.xuehai.net/b99d1ea974a953d8c5ab91561-12.html&lt;/a&gt;，列出了传统的数据产品，例如 db 有 oracle 10g, db2 v8.2 v9.1, teradata 5.2, ETL 有 datastage 7.5, powercenter 7.1, topeng, 等等&lt;/p&gt;
&lt;p&gt;&lt;a class=&#34;link&#34; href=&#34;http://zrj.me/wp-content/uploads/2016/04/view.jpg&#34;  target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;&lt;img src=&#34;https://blog.zrj.me/images/view.jpg&#34;
	
	
	
	loading=&#34;lazy&#34;
	
		alt=&#34;view&#34;
	
	
&gt;&lt;/a&gt;&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
