现代营销观念认为：“营销管理重在过程，控制了过程就控制了结果。”用户行为分析之漏斗分析模型是企业实现精细化运营、进行用户行为分析的重要数据分析模型，其精细化程度影响着营销管理的成败，以及用户行为分析的精准度。粗陋的漏斗分析模型因为过程管理不透明、数据分析不精细、用户行为分析不科学而造成结果失控。因此，我们经常能够听到一些产品经理的抱怨不绝于耳：从启动 APP 到“支付成功”，用户转化率为何仅仅 0.8 %？

一、什么是漏斗分析？

究竟什么是漏斗分析？漏斗分析是一套流程分析，它能够科学反映用户行为状态以及从起点到终点各阶段用户转化率情况的重要分析模型。

漏斗分析模型已经广泛应用于流量监控、产品目标转化等日常数据运营与数据分析的工作中。例如在一款产品服务平台中，直播用户从激活APP开始到花费，一般的用户购物路径为激活APP、注册账号、进入直播间、互动行为、礼物花费五大阶段，漏斗能够展现出各个阶段的转化率，通过漏斗各环节相关数据的比较,能够直观地发现和说明问题所在，从而找到优化方向。

二、漏斗分析模型的特点与价值：

对于业务流程相对规范、周期较长、环节较多的流程分析,能够直观地发现和说明问题所在。值得强调的是，漏斗分析模型并非只是简单的转化率的呈现，科学的漏斗分析模型能够实现以下价值：

企业可以监控用户在各个层级的转化情况，聚焦用户选购全流程中最有效转化路径；同时找到可优化的短板，提升用户体验；降低流失是运营人员的重要目标，通过不同层级的转情况，迅速定位流失环节，针对性持续分析找到可优化点，如此提升用户留存率。多维度切分与呈现用户转化情况，成单瓶颈无处遁形。科学的漏斗分析能够展现转化率趋势的曲线，能帮助企业精细地捕捉用户行为变化。提升了转化分析的精度和效率,对选购流程的异常定位和策略调整效果验证有科学指导意义。不同属性的用户群体漏斗比较，从差异角度窥视优化思路。漏斗对比分析是科学漏斗分析的重要一环。运营人员可以通过观察不同属性的用户群体（如新注册用户与老客户、不同渠道来源的客户）各环节转化率，各流程步骤转化率的差异对比，了解转化率最高的用户群体，分析漏斗合理性，并针对转化率异常环节进行调整。

三、在漏斗分析模型中，科学归因、属性关联的重要性

先谈归因。在科学的漏斗分析中，需要科学归因设置。每一次转化节点应根据事件功劳差异（事件对转化的功劳大小）而科学设置。企业一直致力定义最佳用户购买路径，并将资源高效集中于此。而在企业真实的漏斗分析中，业务流程转化并非理想中那么简单。

以市场营销为例，市场活动、线上运营、邮件营销都可能触发用户购买。A 欲选购一款化妆品，通过市场活动了解 M 产品，后来在百度贴吧了解更多信息，但是始终没有下定决心购买。后来收到 M 公司的营销邮件，A 被打折信息及详实的客户评价所吸引，直接邮件内跳转至网站购买了该商品。

那么，在漏斗设置时，转化归因应该“归”哪一个渠道呢？在这个案例中，运营人员愿意以实际转化的事件的属性为准。邮件营销的渠道在用户购买决策的全流程中对用户影响的“功劳”最大、权重较大，直接促进用户转化。在科学的漏斗分析模型中，用户群体筛选和分组时，以实际转化事件——邮件营销来源的用户群体的属性为准，则大大增大了漏斗分析的科学性。

再一起看属性关联。在进行漏斗分析时，尤其电商行业的数据分析场景中，运营人员在定义“转化”时，会要求漏斗转化的前后步骤有相同的属性值。比如同一 ID（包括品类 ID、商品 ID）才能作为转化条件——浏览 iphone6，购买同一款 iphone6 才能被定义为一次转化。因此，“属性关联”的设置功能是科学漏斗分析不可或缺的内容。

四、漏斗分析场景：

场景一：电商行业不同客户群体的转化情况

某电商企业客户根据客户的消费能力，将客户划分为普通会员、黄金会员、钻石会员。为加强对用户的转化引导，F 欲针对不同用户群体采用不同的运营方式。

图1 普通会员与钻石会员的漏斗转化情况对比

通过对比，可明显看出，普通会员从“提交订单”到“支付订单”的转化率明显低于钻石会员。为找到“支付订单”阶段转化率变低的原因，F公司运营人员应深度分析普通会员转化率情况，如对比不同付费渠道（PC 端、手机端等）的转化情况，找到优化的短板。另外，可以尝试支付订单流程的新手引导，帮助新手顺利完成购买。

场景二：零售行业——中商惠民科学评估站内推广位的效果

首页推广位的效果监控是站内运营重要一环，数据的监测与分析是重要工作，它为站内优化、页面体验提升作出指导。运营人员可以通过用户的点击转化率与购买转化率可以判断页面不同推广位置效果。下图是中商惠民首页推广位“一元促销”、“清洁专场”两个Banner转化率情况对比。（注：为涉嫌商业机密，以下场景模拟真实应用场景而设，数据均为虚拟。）

图2 “一元促销”、“清洁专场”两个Banner转化率情况对比

除此之外，漏斗分析模型已经广泛应用于各行业的数据分析工作中，用以评估总体转化率、各个环节的转化率，以科学评估促销专题活动效果等，通过与其他数据分析模型结合进行深度用户行为分析，从而找到用户流失的原因，以提升用户量、活跃度、留存率，并提升数据分析与决策的科学性等。

关于神策数据

神策数据（https://sensorsdata），一家专业的大数据分析服务公司，致力于帮助客户实现数据驱动。公司推出深度用户行为分析产品神策分析（Sensors Analytics），支持私有化部署、基础数据采集与建模，并作为PaaS平台支持二次开发。此外，还提供大数据相关咨询和完整解决方案。目前已赢得中国银联、聚美优品、百联、中邮消费金融、广发证券、参考消息、中商惠民、米其林、趣店、融360、纷享销客、共享单车、秒拍、36氪等众多行业领先企业认可。希望更深入了解神策数据或有数据驱动相关问题咨询，请咨询4006509827，由专业的工作人员为您解答。

作者：乔一鸭，神策数据运营一枚。

随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：

Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder

大数据平台与数据采集

任何完整的大数据平台，一般包括以下的几个过程：

数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)

其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：

我们今天就来看看当前可用的六款数据采集的产品，重点关注它们是如何做到高可靠，高性能和高扩展。

1、Apache Flume

Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume使用JRuby来构建，所以依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。

每一个agent都由Source，Channel和Sink组成。

Source

Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

Channel

Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

Sink

Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件(Event)，事件由Headers(包含元数据，Meta Data)和Payload组成。

Flume提供SDK，可以支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume 客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。

同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

2、Fluentd

Fluentd是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。

Fluentd的部署和Flume非常相似：

Fluentd的架构设计和Flume如出一辙：

Fluentd的Input/Buffer/Output非常类似于Flume的Source/Channel/Sink。

Input

Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

Buffer

Buffer负责数据获取的性能和可靠性，也有文件或内存等不同类型的Buffer可以配置。

Output

Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下图：

Fluentd的技术栈如下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通信RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性非常好，客户可以自己定制(Ruby)Input/Buffer/Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据/日志格式是它的另一个特点。相对去Flumed，配置也相对简单一些。

3、Logstash

Logstash是著名的开源数据栈ELK (ElasticSearch, Logstash, Kibana)中的那个L。

Logstash用JRuby开发，所有运行时依赖JVM。

Logstash的部署架构如下图，当然这只是一种部署的选项。

一个典型的Logstash的配置如下，包括了Input，filter的Output的设置。

几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。

4、Chukwa

官网：https://chukwa.apache.org/

Apache Chukwa是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建(显而易见，他用Java来实现)，提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次 github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构如下：

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。

5、Scribe

代码托管：https://github/facebookarchive/scribe

Scribe是Facebook开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。

6、Splunk Forwarder

以上的所有系统都是开源的。在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

Indexer负责数据的存储和索引 Forwarder，负责数据的收集，清洗，变形，并发送给Indexer

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发 Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库(DBConnect)等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的 Farwarder上。

总结

我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

导语：为解决元数据问题，伯克利实验室团队使用机器学习技术挖掘“科学生态系统”包括仪器时间戳，设施用户日志，科学建议，出版物和文件系统结构以获取上下文信息。来自这些来源的集体信息，包括实验的时间戳，关于所使用的分辨率和过滤器的注释以及用户对时间的请求，都提供了关键的上下文信息。

伯克利实验室团队整合了一个创新的软件堆栈，该堆栈使用机器学习技术，包括关于科学实验的自然语言处理拉上下文关键字，并自动为数据创建元数据标签。

对于概念验证，Ophus从NCEM的分子铸造厂的TEAM 1电子显微镜分享数据，最近由设施工作人员和科学搜索团队收集。他还自愿为几千张图片贴上标签，为机器学习工具提供了一些可以开始学习的标签。

虽然这是一个良好的开端，但科学研究联合首席研究员Gunther Weber指出，大多数成功的机器学习应用程序通常需要更多的数据和反馈来提供更好的结果。例如，对于像谷歌这样的搜索引擎，韦伯指出，当世界各地的数十亿人通过点击所有带有街道标志或店面的图像来验证他们的身份后，就会创建培训数据集并验证机器学习技术。他们的密码。

“在科学数据的情况下，只有少数领域专家可以创建训练集并验证机器学习技术，因此我们面临的一个重大问题是极少数的训练集，”Weber说，他也是伯克利实验室CRD的科学家。

为了克服这一挑战，伯克利实验室的研究人员使用转移学习来限制其卷积神经网络（CNN）的自由度或参数计数。转移学习是一种机器学习方法，其中为任务开发的模型被重用作第二任务上的模型的起点，这允许用户从较小的训练集获得更准确的结果。

在TEAM I显微镜的情况下，产生的数据包含关于仪器在收集时处于哪种操作模式的信息。通过该信息，Weber能够在该分类上训练神经网络，从而可以自动生成该操作模式标签。然后他冻结了网络的卷积层，这意味着他只需重新训练密集连接的层。

除了通过训练数据集生成元数据标签外，伯克利实验室团队还开发了一些工具，这些工具使用机器学习技术挖掘科学生态系统以获取数据上下文。例如，数据摄取模块可以查看来自科学生态系统的大量信息源包括仪器时间戳，用户日志，提案和出版物并确定共性。

结语：在伯克利实验室开发的使用自然语言处理方法的工具可以识别和排列为数据提供上下文的单词，并为以后的用户提供有意义的结果。用户将看到类似于因特网搜索的结果页面的内容，其中具有与用户的搜索词匹配的最多文本的内容将在页面上显得更高。

产品概述

对政府公共服务而言，大数据之“大”，不仅仅在于其容量之大、类型之多，更为重要的意义在于用数据创造更大的公共价值，提升政府网上服务能力，形成政民融合、互动的“互联网+政务服务”新格局。

如何利用大数据技术和理念为公众提供更为精准化、个性化的服务，成为构建方便快捷、公平普惠、优质高效的政务服务体系的重要内容和必然要求。这需要从“供给端”和“需求端”两个方面做好政务服务大数据应用工作。一方面，要运用大数据手段推动政府监管模式转型，强化事中事后监管；另一方面，要利用大数据精准感知用户需求和服务体验，即通过对“一张网”中的群众行为数据、电子证照库、数据共享交换平台数据库等数据资源进行整合，充分利用大数据技术对跨领域、跨渠道的多元数据展开分析挖掘，全面掌握用户访问行为特征和规律，深入了解用户的服务需求，从而根据用户需求和体验来优化服务资源配置，丰富服务内容，改进服务方式，为用户提供个性化、精准化的服务，变“被动服务”为“主动服务”，不断提升政务服务水平和群众满意度。

功能框架

1.一个大数据平台

基于人社大数据中心平台基础上建设人社大数据服务平台，形成人社大数据服务平台（DaaS平台），实现统一基础数据库建设、统一块数据加工、统一服务定制及发布、统一服务目录及图谱和统一服务能力管理，为各类人社应用系统的建设奠定数据基础。

2.两个应用服务平台

两个应用服务平台分别是人工智能咨询服务平台和智能分析平台。

（1）人工智能咨询服务平台

实现自动化、智能化、人性化、个性化的机器人自助服务，为居民和企业在政务业务办理时提供自助的智能化政务服务，包括提供政务信息查询、业务导办、业务预受理、自动分发、政策宣传、相关问题引导等功能。

（2）智能分析平台

依托人社大数据，通过主题分析模型算法，进行各类主题分析。比如，分析群众行为习惯和办事需求，探索个性化、主动化、精准化、智能化服务，提供多样化、创新性的便民服务，变被动服务为主动服务；根据数据历史发展及成长情况做出相应的趋势预测分析和风险分析，及时感知政策实施和运行中的问题，促进政策完善，提升人社整体的宏观决策支持。

产品特点

1、通过对群众行为的大数据精准感知用户需求

2、通过大数据进行业务创新

3、利用人工智能+大数据技术，全天候提供智能化的人社咨询服务

成功案例

珠海市人力资源和社会保障局

对比是数据分析最基本的方法，通过对比识别数据差异。但是对比有得失。在分析过程中，对比得当可获得精准结论，但对比分析也存在陷阱，比如某产品近期销售数据在下滑，想当然得会得出结论此产品受欢迎度在下降，但是查看销售比（销售数/DAU）却在上升，所以只是因为DAU下降了。

所以如何去有效对比？

1、 横向、纵向多维度对比

对比的前提是两个事物或统一个事物的两个状态，其次必须要有一个对比的指标或标准（这里可称为对比的度量）。对比的两事物一个是主体，另一个是客体。也就是明确对比的三要素：主体、客体和度量。比如小明比小王高5cm，就是一个最简单的对比，这里小明是主体，小王是客体，度量身高，且人们对于身高这个度量存有共识。但如果去大排档吃一碗炒饭50元，可能觉得很贵。那如果是取希尔顿吃一碗炒饭128元可能就不觉得贵，这里我们选择了常识作为比较的基准，客体也没有问题，问题在于我们所谓的“常识”并非所有人的“共识”，如果不是共识，就要非常谨慎地得出结论，否则就容易从自我出发做出判断，影响结论的中肯性。

2、建立标准化的对比客体和度量

就是因为标准可以是认为确定的，所以存在质疑和不确定性。

建立标准化的对比可以是时间标准、空间标准、特定标准、计划标准。

3、 比率的对比

常见的对比是大小的对比、数量的对比，比如销售额的对比，人数的对比，使用不同的对比指标会得到不同的结论，我们把对比标准的选择叫做视角，视角不同，结论不同。比如上述对比小明小王俩同学，身高是视角事宜，除此之外还有年龄、学习成绩、颜值等等。在对比各种变化的原因时，我们也有各种模型，我们所要做的就是找到合适的对比视角。

直接描述事物的变量：长度、数量、高度、宽度等

加工后可得到：增速、效率、效益等指标，这才是数据分析时常用的。

如下图的AB公司销售额对比，虽然A公司销售额总体上涨且高于B公司，但是B公司的增速迅猛，高于A公司，即使后期增速下降了，最后的销售额还是赶超。（数据都是笔者瞎编的，工具用的是FineBI）

3、 指标的逻辑与管理指标

数据分析师有一个关键的职能就是要设计“指标”来对比，设计指标和应用指标有着天壤之别。比如某保健品公司，他们的产品是各类补品及奶粉，他们的业务与市场中人口的出生率、老龄化速度、市场整体购买力、对保健品的消费观念有着直接关系，还与政府对这个市场的管控力度有关。分析这么多之后，有没有一个指标来反映这些综合的因素，它的正反代表着好坏。

考虑到以上因素需要构建一个综合性的指标，这需要各种数据的加权计算。在不考虑市场规模的情况才，可以先构建一个指标指数模型：

Y=aX1 + bX2 + cX3 + dX4+……

Y 可定为市场吸引力指标值

X1 可定为老龄化程度

X2 可定为市场整体购买力

X3 可定为市场对保健品的品牌的看法

X4 可定为政府对这个市场的管控力度

abcd是系数，分别代表影响力程度

当然以上只是简单的罗列，实际情况比如X2还能分解出多个影响指标，甚至整体可以换成乘法模型，指数模型。。。

4、 对标的层次和维度

设定了各项管理指标后，剩下的就是比较工作了。从变化到追踪事物变化的诡计，找到问题的根源，从而找到书屋发展规律，这个过程叫对标。对标可以和自己比，也要和别人和竞品比。

对标的维度有规模指标、速度指标、效率指标、效益指标。

规模指标比如营业额、销售额，电商平台的UV、日活，医院的一天接诊数量，年营业收入额；

速度指标往往代表着活力，也是看未来趋势和潜能的重要指标类，包括各种运营管理指标的速度指标。

效率指标即投入和产出比，如果投入的是时间，月度产值、季度产值；如果投入的是净资产、则净资产周转率；如果投入的是人，人均产值，人均销售额。

雷锋网 AI 研习社按，在数据分析秘籍在这里：Kaggle 六大比赛最全面解析（上）一文中，AI 研习社介绍了结构化数据和 NLP 数据的处理方式，其中包括对 Titanic，房价预测，恶意评论分类，恐怖小说家身份识别四个比赛的详细分析。

本文将介绍图像类比赛的数据处理经验，以树叶分类竞赛（Leaf Classification）和肺癌检测比赛（Data Science Bowl 2017）为例。

正文如下，雷锋网 AI 研习社编译整理：

图像

到目前为止，我介绍的都是文本（语言、字符串或数字）数据集，最后我将带来两个图像数据集的分析。

我选的这两个比赛（肺癌检测和树叶分类）比我看过的其他比赛更具专业特色，这里的分析不再是基本分析，着重于探索不同技术，因此适用于更高阶的读者。

在可视化技术以及特征构建方面，我看到了很多变化。特别是肺癌比赛中，一些作者利用现有的医学知识构建极具专业特色的特征，虽然不能说这些特征的效果有多好，但是这里可视化效果令人惊叹。

树叶分类

竞赛中提供的数据集包括 1584 个按品种分类的被标记的树叶图像，参赛者需要建立一个对标记之外树叶图像分类的模型。

我选择用于分析的 EDA 是 lorinc 的 Feature Extraction From Images，selfishgene 的 Visualizing PCA with Leaf Dataset 以及 Jose Alberto 的 Fast Image Exploration。

第一步最好先仔细瞧一瞧树叶的图像。

selfishgene 检查树叶标本

Jose 绘制出各个种类的树叶，并指出每个种类有 10 张图片。他还观察了同类树叶间的相似性。

lorinc 直接跳入分析阶段，定位每片叶子的中心并应用边缘检测技术，他还将叶子的轮廓转换为极坐标，以便更有效地测量叶子的中心：

之后，当我们使用边与中心之间的距离从形状生成时间序列时，我们可能想要转换到另一种中心性度量——根据该中心的有效性。一种方法是测量中心和边缘之间的（欧几里德）距离......但是有一个更好的方法——我们将笛卡尔坐标投影到极坐标中。

selfishgene 选择看图像的方差方向：

在高维图像空间中，每个图像都可以被看成是不同的「方向」。

Selfishgene 看到的树叶图像的方差

selfishgene 也花费了一些时间来研究图像重建、平均图像周围的模型变化以及特征向量，他解释道：

最上面一行包含每个特征向量的数据分布（沿着「方向」的直方图），第二行包含了我们在前面的图中已经看到的方差方向，第四行包含了树叶的中值图像，值得注意的是，这一行对于所有的特征向量是相同的。

selfishgene 看到的模型变形

特征检测

lorinc 建议将每个样例分成两部分，并将它们作为两个样例处理（尽管他不采用这种方法）。lorinc 从时间序列中找到局部最大值和最小值（例如，绘制在极坐标中的树叶）并记录道：

我很惊讶于这个方法表现得相当不错。我认为我可以从中构建出一个非常有效的特征。但是这种方法的鲁棒性不是很好：对于树叶＃19，它没有找到树叶的末端，只找到了与中心距离最远的点。对于树叶＃78，可以看到在更复杂或有旋转的叶片上效果很差。

lorinc 绘制在极坐标中所测叶子的最小值和最大值

在发现每片树叶周围存在噪音之后，lorinc 谈到数学形态学。他花了一些时间弄清楚如何去除图像中的噪点，并用可爱的图像来显示叠加在树叶上的距离图：

lerinc 测量距离叶子中心的距离

肺癌

我选择的 EDA 是 Guido Zuidhof 的 Full Preprocessing Tutorial，Mikel Bober-Irizar 的 Exploratory Data Analysis 和 Alexandru Papiu 的 Exploratory Analysis Visualization。

anokas 检查单个图像的元数据，可以看到病人出生日期被隐匿（19000101）

2017 年的 Data Science Bowl 比赛要求参赛者通过检测一组图像来预测患者是否患有癌症。虽然在这一竞赛中确实有结构化数据（自动嵌入图像中的标签信息），但其中一些数据是匿名的，也就是说，那些原本具有预测价值的特征（比如患者的年龄）用不了。这意味着所有的 kernel 只专注于图像分析。

在三个 kernel 作者中，Guido 是唯一一个结合医学图像来讨论的人，这点在他对数据集的分析中可以看出来：

Dicom 是医学影像文件标准，这些文件中包含大量元数据（例如像素大小）。不同扫描中的像素大小、粒度都不同（例如，切片之间的距离可能不同），这可能会影响 CNN 的性能。我们可以用同构重采样来处理。

另外两位作者通过对数据集和图像本身进行更全面的探索开始了他们的 EDA。

apapie 检查了图像的形状，而 anokas 开始观察每个病人的扫描次数、总扫描次数和每个病人的 DICOM 文件直方图，他还检查了 ID 和病人是否患有癌症是否存在关系（他发现没有关系，这意味着数据集的排列是很有序的）。

Alexandru 对像素进行分配并绘制图像：

Guido 在 EDA 中阐明了 HU 所代表的东西（空气，组织和骨骼）：

图像

每位作者都在继续研究这些图片：

Anokas 观察一组患者图像

Alexandru 通过 X 射线看图像

Alexandru 花了一些时间研究边缘检测是否能增强图像。

提高阈值后，Alexandru 呈现出一些比较醒目的图像

Alexandru 总结道：

有趣的是，过滤器也能检测到肺里的血管，因此，一些用于区分球体和管道的三维表面探测区分技术将更适合这种情况。

同时，Guido 讨论了重采样，重点关注了 DICOM 图像的基本性质：

一次扫描可能存在一个像素间距［2.5,0.5,0.5］，这意味着切片之间的距离是 2.5 毫米。对于不同的扫描，可能是［1.5,0.725,0.725］，这对于自动分析来说存在一定问题（例如使用 ConvNets 的时候）。处理这一问题的常见方法是将完整的数据集重新取样到确定的等向性分辨率（isotropic resolution）中，如果我们选择将所有的数据重新采样到 1mm*1mm*1mm 的像素中，这样就可以使用 3D 卷积网络而不用担心学习缩放与切片厚度的固定。

之后，Guido 在 EDA 中合并了多个 DICOM 图像完成检测部位的三维图：

在另一个版本中，去除周围的空气以减少内存：

3D图像

点评

这次竞赛是我所见过的最与众不同的。鉴于 Guido 对医学图像的熟悉，他能够利用这一背景来得出更微妙的结论。但这并没有阻止其他两位缺乏医学背景的作者得出同样有趣的结论。

总结

结构化数据

对于结构化数据，分析时倾向于寻找目标变量和其他变量之间的相关性，需要花费相当多的时间进行可视化或对变量进行排序。

对于较小的数据集，可以分析的数据只有这么多列，然而，不同的参赛者使用了截然不同的可视化方法，在选择特征工程方面更极具创造性。

自然语言数据集

从这些 EDA 中可以看到，大家在处理自然语言数据集时有相似之处，但在特征工程的选择以及分析中，会得出不同结论，产生很大的变化。

图像数据集

图像竞赛中，在分析和特征工程方面表现出了极大的多样化。我所看到的图像竞赛主要是针对有一定积累的参赛者，而且是在一些特定领域，这可能会产生更超前的多样性。

当数据集变得更加专业或深奥时，介绍性的分析和解释就会减少，而比较深入和专业化的分析就会增加，而这正是我所看到的。虽然不同类型的数据有明显不同的趋势，但专业领域知识起着重要的作用。在肺癌和叶片竞赛中，引入专业领域知识到研究中，可以支撑更深层次的分析。（有趣的是，我在自己的研究中也遇到过这种情况，Jeremy Howard 在他的 fast.ai 课程里讨论了 Rossman 的数据集，以及最成功的模型是如何集成第三方数据集，如温度、存储位置等，从而做出更准确的销售预测。）

参赛者处理特征工程的时候，并没有一个统一的过程。有些人选择在分析时开始，而另一些人则在最初的分析完成之后，将其作为一个单独的步骤。

最后，我看到的每一份分析手册都有确定的读者（初学者或资深研究者），这会影响分析和写作。

在一些更受欢迎的比赛中，或是针对普通研究人员的比赛中，EDA 分析都是详尽无遗的。在这些 EDA 中，我也看到了一种趋势，即在分析的同时穿插补充或叙事来帮助初学者更好地理解技术。

相比之下，针对更资深的研究者的笔记则倾向于去掉多余的叙述性描述，许多还跳过了基本的数据分析，而是直接转到特定领域的技术中去。

特别鸣谢 Michelle Lew、Ari Zilnik、 Sean Matthews 和 Bethany Basile，感谢他们对这篇文章的审阅。

via：thekevinscott

雷锋网 AI 研习社编译整理。

文| 傅一平原文自：与数据同行

在数据管理领域，我们通常将数据分为：主数据、交易数据、参考数据、元数据和统计分析数据（指标）， 指标是BI里面核心的概念，是一个企业数据运营关注的核心数据，一般以KPI和报表的形式体现。

从实践来看，一个企业要进行数据治理，涉及了架构、安全等诸多层面，但最迫切的是提升数据质量，其中指标质量则是重中之重，一般业务上90%以上关于数据的疑问都从指标的质疑开始，只要你从事数据相关工作，就应深有体会。

“这个指标好像跟业务发展实际不符，快去查查”，估计这是报表取数人员听到的最多的一句话了。

笔者就来谈谈如何从根本上去提升指标的数据质量，即实现指标的标准化，作为一个数据管理人员，不管你有多少能力，曾经解决了多少问题，当过多少回救火英雄，都应该从更为长远的角度来思考这个问题。

指标标准化的核心价值在于实现“书同文，车同轨”，即通过针对指标的一系列管理过程，去提升指标准确性、一致性、敏捷性及开放性，在以前的文章《如何才能做好一张报表》中对此有详细的阐述。

DAMA将数据治理放到核心地位，指标的标准化就是个典型的数据治理问题，治标是容易的，治本的代价则太高，但如果要实现进阶，还是要站的高一点，多思考一下，想想是否有更好的方法，就从笔者多年前做过的指标标准化项目开始吧，分为组织保障、报表梳理、指标整合、实现方式、功能架构、可视化引擎及管理流程等七个方面。

1、组织保障

指标库这类数据管理项目，或称BI项目，一般业务部门参与的力度是不大的，这是大多BI项目实施效果不佳的一个深层次原因。

DAMA提到要实施数据治理活动，跨部门的数据治理委员会等是关键的组织，的确是这样，指标跟全公司每个单位都相关，对于其进行规范化改造当然应该获得大家的一致同意。

可惜的是，大多企业没有这个理想条件，也不会有数据治理委员会，在数据还未成为真正的实质性资产前，比如纳入财务部的资产目录，很少有企业会设立这个数据组织，因为效益不明显，因此，哪个企业都不大可能为指标出一个规范并且通令全公司贯彻执行，对于数据管理人员，指标库这个事情也许意义不小，但对于全公司意义则小了，这是现状。

在没有公司层面的组织保障前，数据管理人员或BI部门大多得靠自己，通过自己来推动事情往前走， 这是应有的态度，你不提，公司也没有任何人会提，毕竟你是最大受益者，实施指标库这个事情非常复杂，谁都没有成功的把握，秉持小步快跑，试点探索的原则是不错的。

笔者的这个指标库项目获得了分管领导的强力支持，这是项目能进行的现实组织保障，其实这类管理项目设立之初，很难让业务部门和一线人员马上认识到其价值并充分参与进来，这个沟通管理成本太高了，但无论如何，一个数据治理项目能否成功，公司的支持是第一要务，不仅仅是IT部门的事情，DAMA的很早就在《DAMA数据管理知识体系指南》明确了数据治理的组织要点，以下是DAMA的数据治理组织架构图，非常超前：

当然笔者觉得现实的组织演进也许如下图更合适，但道理是一样的，相关利益方需要对这个事情达成共识：

2、报表梳理

指标的主要表现形式是报表，因此第一要务就是报表梳理，公司的报表浩如烟海，因此这个项目设立之初就限制了范围，主要针对一线市场部经理、终端管理、流量管理三类核心角色，共梳理了相关的39个彩信、48份邮件通报及数据集市上的733张报表。（下图是用excel，下载企业大多用帆软、水晶一类的报表工具）

3、指标整合

各类报表及相关指标表达各不相同，梳理前应该给出一个描述指标的标准框架，包括指标大类、子类、维度、周期、归属、命名规范等等，曾经由于框架漏了一些要素导致返工现象，这个顶层设计一定要做好，以下是示例：

命名规范：业务限定词+业务名称+量值限定词+量值描述（量、收、用）

举例1：两网有效用户到达数

举例2：自建有线宽带出账用户数

下图列出了大致的梳理步骤，主要以省公司报表和彩信KPI为基础确定基准指标，各地市指标剔除个性指标后，合并到省公司的基准指标中，形成本次的最终指标范围。

全省指标共计6841个（未剔重），经过归并整合，得到基础共性指标2306个，如下图所示：

此项工作耗时巨大，以下是成果的示意：

4、实现方式

根据指标性质不同可以分为3类，即基础指标1046个、计算指标652个和通用营销类指标303个。

5、功能架构

为了支撑指标快速，标准化实现，通过增强数据管理平台来实现指标的快速开发、部署和管理，主要包括指标信息维护、指标开发、运维管理、指标质量管理等功能。

比如指标库每月需要新增超过9. 5亿行的数据，存储周期按12+1，即123亿行，以传统关系型数据库的查询能力无法支撑，这里就采用Hbase架构支撑海量指标的快速查询。

6、可视化引擎

为了支撑指标组装报表与配置报表的快速开发，使用数据可视化引擎产品，主要包括指标组装、报表开发、报表展现功能，现在的这类产品很多了，但定制化给予一个创新性项目更大的自由度。

指标组装报表工具是区别传统基于SQL配置报表的灵活度更高的报表配置方式，主要提供基于指标选择组装生成报表。

7、管理流程

指标的建设只是走完了数据治理的第一步，为了确保指标库长期可用，必须要有一套针对的指标管理机制和流程，否则建设的结束就是混乱的开始，理想的做法当然是发布一套公司级别的指标管理规范，但这个时候时机往往并不成熟，比如系统可用性到底如何，因此，我们当时就确立了一个简单原则，一条开发铁律：不重复开发，能用指标实现的不允许单独开发报表，当然这非常考验数据管理的艺术，极大依赖于团队的业务和数据能力，但有主见的数据管理团队一定要懂得如何与业务人员进行博弈，记得你才是全公司数据的管理者，而不仅仅是个开发者。

笔者在关于指标库的实现简要谈完了，但我对于大多企业搞指标库却是持悲观态度的，传统BI部门面对浩海的数据需求时，往往是没有管理原则的，因为公司对你的数据管理授权是不明确的，我们不得不以牺牲长远来满足当前，其实BI每接收一个不规范（比如胡乱的指标命名和定义）的报表需求就要承担由此带来的管理成本，而不仅仅是开发成本，这为后续数据管理的混乱埋下了祸根。

但存在的又是合理的，因为搞个指标库在开始的时候，无论是管理及运维成本都不低，关键是短期来看效益还不明显，这也许是成功案例不多的一个原因。

因此，当我们在抱怨业务指标口径一塌糊涂的时候，要记得是企业没有数据管理的原则导致了这个现象，也是你的不作为导致了这个现象，这跟公司的文化、机制及流程是息息相关的，顶层设计没解决，也许只能将就了，或者，你就要付出百倍的努力去改变或优化这个设计吧，这需要巨大的决心和毅力。

DAMA谈数据治理首当其冲谈组织设置，显然是非常睿智的，奇怪的是在知乎上关于DAMA数据治理的讨论几乎没有，这倒是值得思考的问题。

转载自百家号作者：趣说人工智能

人工智能图像来源分析图像来源分析的任务也受益于深度学习元数据（特约点评：人工智能图像来源分析图像来源分析的任务也受益于深度学习元数据对于图像来源分析提供了新的思路，这个创新点趣说人工智能必须推荐。来自网友小星的推荐！）

人工智能图像来源分析：图像来源分析的任务也受益于元数据摘要:无论是绘画还是模因，创意作品都遵循独特的旅程，从而形成最终形式。了解这些旅程，这一过程被称为“原产地分析”，为任何特定工作的使用，动机和真实性提供了丰富的见解。我们在本文中考虑将这种类型的研究应用于互联网上广泛的不受管制的内容。源内容分析提供内容的时间顺序和有效性的快照，因为它随着时间的推移上传，重新上传和修改。尽管仍处于起步阶段，但在线多媒体的自动化起源分析已经应用于不同类型的内容。目前大多数作品都是根据图像或视频之间的共享内容来构建起源图。这可能是一项计算成本高昂的任务，尤其是考虑到互联网每天都能看到的大量内容。利用非基于内容的信息（例如时间戳，地理标记和摄像机ID）可以帮助提供有关特定图像或视频在互联网上传播的路径的重要见解，而无需大量计算开销。本文在两种不同的场景中测试基于元数据的推断图形构建的范围和适用性：数字图像取证和文化分析。

人工智能图像来源分析：图像来源分析的任务也受益于元数据简介:理解视觉对象背后的故事是一种广泛兴趣的活动。无论是确定用于制作绘画的调色板，雕塑家的风格，还是艺术品的真实性，得出手头物体的起源和构成对许多人来说都是一项艰巨但重要的任务。考官。源于艺术作品性质的微妙线索长期以来一直用于提供与起源相关的问题[8]。劳伦斯·斯蒂芬·洛瑞（Darnce and Joan）绘画中的灰白色调使劳伦斯·斯蒂芬·洛瑞（Laurence Stephen Lowry）对其真实性产生了质疑[10]。 Danseuse Bleue et Contrebasses油漆中的铅含量以及对画家签名的仔细审查使得专家能够正确地恢复Edgar Degas最着名作品的有效性[9]。这种来源分析帮助历史学家，文化分析师和艺术爱好者分析这些作品的起源，内容和成长。虽然用于进行种源分析的技术随着时间的推移而发展[25]，但它一般来说仍然是一个未解决的问题[63]。在艺术史领域，它是最活跃和最重要的研究领域之一[64]，因为仍有复杂的案例尚未建立起源（例如，绘画Bords de la Seine a`Argen- teuil [ 51]和解释艺术品之间关系的新途径。

上述案例研究可能使人们相信，来源分析是过去破译事件的工具。相反，随着在线数字媒体的普及，对起源分析的需求从未如此及时。目前的社会情绪只能在网上模因和其他病毒运动的背景下得到充分理解[59]。此外，由于真实和虚假图像之间的界限模糊，这些类型的在线现象可以用于欺骗公众的程度已经引起了人们的极大关注[32]。借助高质量的相机和图像编辑软件，任何人都可以使用照片，比照片或雕塑更容易打造照片。我们已经达到了这样的程度，即可以生成具有细粒度细节的数字伪造品，直至摄影风格和传感器噪声[49,44]。反取证方面的这些进步削弱了内容的可信度，所有权和真实性。共享图像和视频的当前比例需要以自动方式回答这些问题。

可以采用图像处理和计算机视觉技术来检测图像或其他数字艺术形式之间的对应关系[47,7,68]。这种对应的范围可以从图像[46]中的对象匹配到比较两者的风格[29]和语义[57]。原产地分析可以被认为是多个图像对集之间的排序对相似性，因此是成对图像比较的自然延伸。这些随后的有序排序可以被建模为图形，其中每个边缘表示一对之间的对应关系，并且边缘的末端顶点表示两个相应的图像。图1中可以看到这种图形的一个实例。该示例表明，源头分析算法可以分析同一视觉对象的多个非常近距离的真实版本。像这样的复杂场景可能会使基于内容的相似性指标不可靠。

人工智能图像来源分析：图像来源分析的任务也受益于元数据贡献：由于单个原始图像的大量可能版本，用于量化图像对之间的相似性的度量可能是嘈杂的。完全依靠视觉线索将不同版本排序成图形可能导致原始重建不良[11,52]。因此，利用其他数据源来确定连接变得恰当。例如，很难指出图2中两个图像之间的语义差异，但可以通过检查图像文件的元数据来区分图像。这样的一对图像可以被称为语义上相似的，因为它们以语义方式彼此相关但不是源自相同的源[56,11]。匹配难度也可以出现在近似重复图像的集合中，这些图像是从经历过一系列变换的单个原点（例如，作物饱和去饱和物）产生的。这些图像集中的像素级数据可能表现出模糊的证明方向性。可能需要超出像素级数据的信息来检测这些图像之间的差异。为了处理图像内容无法解释图像演变的场景，可以使用文件元数据来帮助填补空白。在这项工作中，我们探索使用通常存在的文件元数据标签来改进图像来源分析。我们将这些结果与基于图像内容的方法进行比较，并突出显示两者的优缺点。

人工智能图像来源分析：图像来源分析的任务也受益于元数据相关工作：原产地分析是各种基于数据的领域中广为人知和研究的现象，如语义网和数据仓库[30,16,4,62]。然而，在线多媒体的起源分析尚未在现有文献中进行广泛研究。与图像起源分析问题最相关和最相关的工作类型来自数字取证文献中的三个既定概念：近似重复检测[19,41]，图像拼接检测[21,6， 38,17,34,15]和图像系统发育[24,23,22]。大多数提出的方法用于分类图像是否是检索上下文中的查询图像的近似复制，并且不确定近似重复的集合中的原始图像。然而，图像系统发育社区已经研究了这个特殊问题。

图像系统发育解决方案旨在找到不同版本图像之间的亲缘关系[24]。与物源分析类似，图像系统发育将其表示限制为以原始图像为根的单根树，即使可能有多个原始图像对图像的创建有贡献。该算法接收查询图像并输出图像系统发育树（IPT）。通过将拼接图像纳入考虑范围，该方法也被扩展到处理多个（两个）根[56]。此多父方案的一个实例在图1中可以观察到四个图像（供体）对中心合成图像的内容有贡献。这些图像系统发育方法的一个约束是解决图像来源分析的非常具体的情况，它们使用有限的一组变换和图像格式处理受约束的数据集[39,22]。除此之外，他们中的大多数只考虑两个图像来形成复合，从而限制了大规模一般适用性的解决方案。因此，新的图像来源算法必须在不同的伪造数据集，图像变换，文件格式和图像分辨率中进行推广和评估，以适用于实际情况。

作为从图像系统发育工作启发的图像种源分析的更一般框架的一步，最近关于无向种源图构建的工作[11]采用了美国国家标准与技术研究所（NIST）提出的更一般的分类和数据集。 [55]。它提供了U-phylogeny管道作为解决证明分析的初步方法，该方法不仅限于一组封闭的图像变换，也不限于用于形成多母复合材料的供体图像的数量。结果是针对存在和不存在干扰物的情景（与查询图像的起源历史无关的图像），显示了容忍无关图像的方法。 U系统发育方法的局限性在于它不提供定向起源图，这是理解媒体对象演变所必需的。

为了克服方向限制并提出可扩展的方法，在[52]中描述了用于图像源分析的更完整的端到端流水线。用于图形构造的方法首先基于局部图像特征建立不相似性矩阵，然后采用层次聚类来对节点进行分组并在最终出处图中绘制边缘。如第1部分所述，仅依靠图像内容可能会导致噪声边缘延迟。对于有向边缘尤其如此，已经证明有向边缘比无向边缘更难以导出[11,52]。解决此问题的一个选项是使用文件元数据。文件元数据主要用于数据和软件起源分析[1,4,30]，因为这些信息揭示了无法直接从数据中获得的文件的重要线索。

在图像域中，元数据通常存储关于用于捕获图像的设备和用于处理图像的软件的信息。这些类型的标签提供的信息已被用于提高任务的有效性，如图像分组[37,45]，基于内容的图像检索[2,67]，照片分类[14]，图像注释[ 40]和版权保护[33]。其中，在图像之间建立语义对应的算法，例如自动分组或分类，可以利用诸如日期，位置，内容发起者，相机类型和场景类型之类的标签[35]，而那些检测到篡改的标签可能依赖于检测内部的不一致性。包含源和版权信息的这些和其他标签的值[18,33]。图像元数据可以分为三种类型：EXIF，IPTC和XMP [26]。可交换图像文件格式（EXIF）数据是使用最广泛的数据，无论图像采集的模式和条件如何，大多数相机都会自动创建和存储。 IPTC是国际新闻电信委员会专门为媒体开发的标准。它主要与版权信息有关，在最新版本中，它已被纳入Adobe的可扩展元数据平台（XMP）标准。 XMP是三者中最新的标准，但并不是最广泛采用的标准。在本文中，我们专门使用EXIF标准。正如Alvarez在[3]中所提到的，“从JPEG文件中提取EXIF标题可以帮助调查人员区分未触及的数字图像。”根据该文章，执法人员使用元数据来帮助确定图像是否已被编辑为看起来像儿童色情。 EXIF信息以及JPEG标题信息和缩略图也被用于测试数字图像的真实性[42]。 Fal等人提出了要相关的图像处理和EXIF参数的证据的另一个实施例。 [27]。虽然过去已经成功地将元数据用于取证任务[12,28,34,48]，但它之前尚未用于物源分析。

使用元数据进行原产地分析：提出的基于元数据的解决方案建立在上一节中解释的最先进的物源图构建框架之上。为了使解决方案尽可能广泛适用，我们依靠EXIF元数据标签来改进对来源图中边缘的推断。我们根据标签的可用性和与出处问题的相关性来选择标签。虽然许多图像中经常存在大量元数据标签，但这些标签中只有一小部分提供了有用的信息，可用于辨别图像间关系。此外，使用仅由特定相机固件提供的标签或仅适用于某些格式（例如，JPEG）的标签降低了所提出方法的普遍性。

图3描绘了一个方向模糊的图像对示例。在图3（a）中的两个图像之间执行基于兴趣点的成对分析之后，两者之间的拼接（从左到右边缘）或移除（从右到左边缘）操作的有效参数可以做成。利用两个图像中的“DateTimeOriginal”标记消除了这种关系的歧义，揭示了狮子在以后确实拼接到图像中。表1显示了在本工作中选择的元数据标签，用于提供图像成对出处分析。

通常，互信息的价值被用作图像之间的成对关联度，或者作为N个图像中完整图形中边缘的权重，没有自我循环[52]。为了在此阶段合并元数据信息，我们提出了一种基于启发式的规范化投票，以将权重归因于每个成对的图像关系。用于此目的的启发式算法是在图像出处的背景下直接的元数据相关假设，并且依赖于表1中给出的标签的内容。

人工智能图像来源分析：图像来源分析的任务也受益于元数据讨论：图像元数据是改善图像检索[61]，语义分割[5]和操作检测[34]等领域结果的宝贵资产。我们的工作表明，图像来源分析的任务也受益于元数据。外部环境可以证实纯视觉技术的证据，为物源图重建创造一个更好的整体解决方案。除了利用无法从图像本身获得的信息之外，基于元数据的方法在计算上非常便宜。此外，与需要大量培训资源的复杂，数据驱动，基于视觉的技术不同，像我们这样的方法根本不需要培训。这些方法可以很容易地大规模部署，从而导致很少的性能开销。由于当前可用的物种数据集的尺寸相对较小，需要大量训练数据的方法可能会受到影响。到目前为止，在该领域发布的大多数数据集确实很小。

尽管外部信息可以改进基于图像的方法，但是来源分析还远未解决。这项工作仅提供了在物源分析中利用元数据的初步探索。虽然我们的结果显示出改进，但基于元数据的方法由于缺少或操纵而具有更高的不可靠性的可能性。解决问题的进一步进步必须集中在检查内容衍生的元数据上。未来的工作可能包括从内容和可用标签估计缺失的元数据信息[27,65]。目前，我们的研究结果表明，基于图像内容的方法应该是后备选项，因为仅元数据对于确定边缘方向而不是边缘选择更有用。我们推测，未来，最佳出处方法应主要依赖于图像内容，但在元数据分析存在的情况下利用元数据分析作为二次细化系统，并提供充分的证据。

罗伯特·S·西纳(Robert S. Seiner) 2018年6月6日 相隔译

在过去的25年里，信息技术的世界已经“戏剧性地”成熟了——我的职业生涯相对短暂。从午夜时分在大学计算机实验室打卡和给露天平台的读者提供材料，到互联网、电子商务、商业智能、大数据、人工智能……人们可能会认为，他们已经见识了一切。

我们只能想象，未来的25年里，我们将面临什么。在21世纪之后，在可预见的未来，管理数据、信息和知识的需求和速度(如果还没有的话)将成为业务驱动因素。

“管理数据、信息和知识将是业务驱动因素。”

如果你还不知道的话，这个短语值得重复几次。一个公司管理数据、信息和知识的能力将决定一个公司能有多成功，或者他们是否能成功。

为了管理数据、信息和知识，公司需要知道他们拥有什么数据。公司需要准确地知道他们的数据是如何被使用的，以及如何使用这些数据来创造竞争优势。要了解这些信息，公司需要管理和使用它的元数据。

元数据是在IT工具中记录的信息，它可以改进数据和数据相关过程的业务和技术理解。(1)这个定义比我们这个行业的人们过度使用的“关于数据的数据”定义要长得多。当您将这个定义分解成几个部分时，它将告诉我们什么是元数据，在哪里可以找到它，它如何有用，以及它将帮助谁。

元数据在未来几年将变得越来越重要。元数据将不再是“周三的信息处理系统之子”(2)，正如数据仓库之父Bill Inmon在《数据管理评论》(data Management Review)中所言。每个公司都有元数据。这是毫无疑问的。数据库构建在元数据之上。数据模型建立在元数据之上。程序、显示、报告、查询、数据迁移……信息系统的所有组件都是使用元数据构建的。这本身就应该表明，管理元数据很重要。但现在它不是。

元数据的问题

关于元数据的问题仍然存在。元数据究竟是什么?管理元数据要花多少钱?如何证明对元数据的“投资”是合理的?谁使用元数据?如何开始管理元数据?这些都是非常重要的问题，在这些问题中，答案将成为决定公司是否继续实施元数据管理策略和实施计划的关键因素。

这些问题并不总是容易回答——特别是当人们的问题有点脱离每日构建的数据和技术架构以支持企业的情况时——即人最有可能不停地改变主意。专家们已经写了很多书来回答这些问题。这些问题不在本文中讨论之列。

作为替代，这里选择了不同的方法。本文不再关注元数据问题的“答案”，而是关注元数据可以回答的“问题”。

问题分类

元数据可以回答的“问题”可分为十类。我之所以选择这10个类别，仅仅是因为它是一个很好的整数。除了这是我以前使用过的元数据的逻辑分解之外，没有其他原因。如果这些类别不适合您的需要，根据您的需求完全可以自行组织。我选择的10个分类包括:

数据库元数据数据模型元数据数据移动元数据业务规则元数据数据管理元数据应用组件元数据数据访问/报告元数据合理化的元数据数据质量元数据应用操作元数据理解分类当你阅读“元数据可以回答的问题”列表时，问自己三个简单的问题:在你当前的环境中:我的公司能回答这些问题吗?我的公司为回答这些问题付出了什么代价?当我们不能回答这些问题时，结果是什么?我猜测，如果您在得出上述关于元数据的三个问题的答案时，您将感到元数据管理怎么这么简单的。许多问题属于多个类别。例如，在数据迁移期间，数据从源流到宿（目标）。向目标执行的操作(赋值)可能来自映射列表(或转换表)，具体取决于源或多个源。当源数据丢失或源值没有指定的目标值(有时称为缺失规则)时所采取的操作可以视为数据迁移元数据或数据质量元数据。我列出了一些问题，如果有必要你可以画出它们之间的联系。这些问题不应该被认为是包罗万象的。相反，应该将元数据问题视为一个“入门工具包”，它可以帮助您的公司理解这一点:这些问题的答案很重要。这些问题的答案并不总是可以得到的。如果IT部门能够访问这些信息，他们将“执行”得更好。“成本节约”和“竞争优势”与通过元数据管理数据有关。元数据可以回答的问题数据库元数据数据库元数据描述物理数据。数据库元数据通常存储在数据库目录或copybook/segment定义中，开发人员和db管理员使用数据库或文件辅助类型工具进行访问。数据是否存在于数据库(或文本/顺序文件)中?哪些数据库存在?存储数据的数据库的物理名称是什么?数据位于何处?(如平台(或dbms)、服务器等)数据库中表的名称是什么?表中什么列?主键是什么?有其他索引吗?表与其他表有什么关系?表是视图的一部分吗?数据库上一次是什么时候更新的?谁最后更新了数据?有哪些文本文件和顺序文件?我的数据所在数据集的物理名是什么?数据位于何处?(比如框架、区域、数据集名称等)有多少个数据版本?数据集是存在于磁带上还是存储器上?哪些拷贝代表文件中的数据?哪些程序使用拷贝?什么工作流驱动程序?如何处理、组合和排序数据?数据模型元数据数据模型元数据描述数据的逻辑设计和从逻辑设计到物理数据的映射。数据模型元数据还可以包括业务规则、实体关系、域值等。数据模型元数据通常在数据建模和案例工具中找到，尽管有些数据模型元数据仍然可能在图表和电子表格工具中跟踪这些信息。存在什么数据模型?哪里可以找到模型?是否存在企业数据模型?谁创建了模型，用于什么目的，项目/数据库等等?谁负责更新这些模型?定义了哪些业务实体，它们存在哪些模型?在数据库(表或系统)文件中表示的业务实体在哪里?业务实体的定义是什么?构成这些实体的属性是什么?属性的业务定义是什么?属性是否具有限制性域?各属性的允许值是多少?逻辑数据模型和物理数据模型之间的关系是什么?物理数据模型是否与逻辑数据模型同步?物理数据模型是否与物理数据库同步?实体和表、属性和列之间存在什么映射?数据迁移元数据数据迁移元数据描述数据从源到目标的移动。数据迁移元数据包括数据的选择和提取、映射、转换和数据加载的信息。数据迁移元数据可以在ETL或数据迁移工具、电子表格、桌面数据库中找到，也可以在编写用于执行数据移动的代码逻辑中找到。迁移数据来自哪里?是系统或其他数据库?用于填充数据的字段是什么，是否为派生字段?数据是如何得到的?计算，条件，还是两者兼具?派生过程中，还使用了哪些数据?数据的值是否依赖于其他数据的值?依赖哪些数据,如何依赖这些数据?目标数据是否允许为null?数据丢失的话怎么办?源数据不符合质量要求时怎么办?当没有为源值分配映射的目标值时怎么办?目标数据具有什么值?这些值如何映射到以前的值?什么时候迁移数据?数据总是以这种方式“迁移”，还是有随时间变化?什么时候触发迁移?业务规则元数据业务规则元数据描述业务如何使用其数据进行操作。业务规则元数据描述定义数据使用的实体关系、基数、域规则等。业务规则元数据通常存在于数据建模或案例工具中，或者存在于工具、文字处理、电子表格或其他工具之外维护的其他形式的文档中。逻辑数据模型中数据实体之间具有怎样的关系?这些实体之间的基数是什么样的?在什么条件下，数据片段可以承载特定的值?一段数据可以承载什么价值?价值的含义是什么?如何创建、更新和删除数据?什么时候，由谁建立的规则?数据管理元数据数据管理元数据描述组织中谁对使用数据所采取的行动负责。数据管理元数据定义组织中的谁定义数据，组织中的谁创建、维护和删除数据，以及谁使用数据或直接使用工作中的数据或信息。数据管理元数据仍没有被几个公司采用(还没有!)，而仅有的几个使用的公司也只使用桌面数据库和电子表格运作。如果你对数据有疑问，你会打电话给谁?谁负责定义、创建、读取、更新和删除数据?具备什么能力和职责的个人可以管理数据?谁是将数据作为工作的一部分的数据“消费者”?哪些信息可以在公司内部共享?公司外呢?谁必须批准才能在公司之外发布报告?谁负责为数据分配可接受的值?怎么让管理程序适用公司的信息政策?信息政策在哪里能找到?应用组件元数据应用组件元数据描述应用程序的所有对象，从数据文件或表到程序、脚本和功能、显示等等。应用组件元数据是组成系统的所有组件以及组件如何共享和重用的交叉引用。交叉引用工具和桌面工具通常是存储这些信息的地方。哪些应用程序组件被认为是标准的可重用对象?这个“可重用对象”是如何确定的?如何测试这些对象，以及谁维护这些对象?什么程序(及数据、显示等)是系统(或过程或功能)的一部分?哪些作业(或过程、脚本)执行程序?程序和作业使用什么数据?数据是如何使用的?如何将数据从程序传递到程序、作业到作业、系统到系统?数据依赖于什么系统?什么系统依赖于特定数据?哪些程序和作业是重用的?在哪里重用?随着时间的推移，项目和工作发生哪些变化?谁编写了程序和作业?谁负责支持和维护程序和作业?哪些程序更新数据?哪些报告显示数据?哪些页面显示数据?数据访问/报告元数据数据访问和报告元数据描述了如何访问数据，以及已经创建了哪些报表可以读取或重新创建。数据访问和报告元数据也可以描述必须采取的步骤来获得授权读取数据,如何解释数据的描述,可用工具,报告的描述,等等。数据访问和报告元数据通常在报告工具和传统类型的文档(如桌面数据库、文字处理和电子表格)中寻找。使用这些数据的报告有哪些?报告的描述什么?如何访问报告?应该采取哪些步骤来获得使用数据的授权?报表如何选择、组织/排序、分组、汇总和显示数据?报告使用了什么数据?什么报告使用我的数据?报告最后一次更新是什么时候?必须亲自制作报告，还是已现成结果?哪里可以找到结果?合理化的元数据合理化元数据描述了标准的“企业可接受”信息片段，以及这些信息片段如何在系统中表示或映射为数据。标准的信息片段可以是数据元素的选择列表，这些数据元素具有可接受的含义、历史、值和/或来自企业数据模型的标准信息片段。合理化元数据可以描述数据元素是同一信息块的程度和差异。合理化元数据通常存储智囊库或传统文档中。公司的标准(核心)要素是什么?这些元素的业务名称和定义是什么?标准元素是如何、由谁选择的?标准元素是否被验证以供重用?标准元素在哪里映射到现有数据?如何使用标准元素?数据质量元数据数据质量元数据描述数据的质量。数据质量元数据描述准确性可信级别、变更管理、数据值和定义的历史，以及随时间变化如何影响数据的理解。数据质量元数据还描述遇到“坏”数据、数据丢失或重复时需要采取的操作。使用数据质量工具、存储库和传统文档类型跟踪数据质量元数据。数据可能的值是如何随时间变化的?什么时候可接受值变了?数据的定义是如何随时间变化的?数据的定义是什么时候变了?什么数据是“坏”数据?对数据进行了哪些质量检查?什么是质量检查程序?该程序是谁写的和执行的?谁分析的结果?数据有多大的可信度?在数据被认为是“低质量”数据之前，可接受的置信水平是多少?计算操作的元数据计算操作元数据描述数据的活跃度和调度中心。计算操作元数据描述数据存储、磁带使用、作业和服务器操作、调度依赖项、异常处理、备份和恢复过程等。计算操作元数据可以通过调度系统、存储系统、操作和服务器系统等找到。计划对数据运行哪些操作/作业?有哪些类型的数据备份和恢复可用?我的数据最后一次被备份、恢复和验证是什么时候?备份和恢复数据需要哪些步骤?谁负责备份和恢复?谁拥有使用数据的安全特权?创建、读取、更新或删除?针对特定数据运行程序/报告的最佳时间是什么时候?哪些操作依赖于来自另一个进程的数据?当作业或系统失败或终止时，应采取哪些行动?当作业或系统失败时，应该调用谁?我们运行的是什么版本的软件?如果许可，我们有多少许可证，谁在使用它们?许可证何时到期?软件的下一个版本什么时候安装?新版本对软件进行了哪些更改/增强?有多少磁盘空间可用?已用了多少磁盘空间?数据以什么速度增长?谁分配存储空间，应该联系谁来回答有关磁盘存储的问题?磁带存储头是如何定义的?