元数据

hadoop的机制，是在hadoop的2.x中才有的功能，该功能的实现，非常依赖于一个分布式组件：zookeeper。 zookeeper简要介绍 zookeeper主要做分布式协调服务。主要实现的功能：1.提供对少量数据的存储和管理。2.提供对数据节点的监听功能。 zookeeper的角色：leader（负责数据的写操作）和follower。leader和follower实在启动的时候动态选举出来的。 zookeeper的作用：主控机器选举，分布式协调操作。 zookeeper管理数据采用了类似于文件树结构。每个节点成为一个datanode。节点能够保存一定的数据（小于1M）也可以拥有子节点。 zookeeper的应用场景。 统一命名服务：Dubbo 远程调用：webservice和rpc。统一命名：将多个机器上的服务给予 一个统一的命名。 统一配置管理 将所有分布式应用的数据存入到zookeeper集群中。 集群管理 利用zookeeper实现动态主控节点的选举 NN高可用方案实现机制 问题：相应客户的读写请求的是角色是NN，所以一旦NN宕机了，那么整个集群的服务就停止了。NN+SN机制，只能实现元数据的可靠性，但无法做到服务的高可用性。 解决方案：再加入一个NN。思考点： 能否两个NN收正常客户请求？ 否，两个NN只能有一个相应客户请求（状态为active）

hive内部表、外部表区别自不用说，可实际用的时候还是要小心。 Hive的数据分为表数据和元数据，表数据是Hive中表格（table）具有的数据；而元数据是用来 存储 表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等。下面分别来介绍。 　 　一、Hive的数据存储 　　在 让你真正明白什么是hive 博文中我们提到Hive是基于Hadoop分布式文件系统的，它的数据存储在Hadoop分布式文件系统中。Hive本身是没有专门的数据存储格式，也没有为数据建立索引，只需要在创建表的时候告诉Hive数据中的列分隔符和行分隔符，Hive就可以解析数据。所以往Hive表里面导入数据只是简单的将数据移动到表所在的目录中（如果数据是在HDFS上；但如果数据是在本地文件系统中，那么是将数据复制到表所在的目录中）。 　　Hive中主要包含以下几种数据模型：Table（表），External Table（外部表），Partition（分区），Bucket（桶）（本博客会专门写几篇博文来介绍分区和桶）。 　　1、表：Hive中的表和关系型 数据库 中的表在概念上很类似，每个表在HDFS中都有相应的目录用来存储表的数据，这个目录可以通过${HIVE_HOME}/conf/hive-site.xml配置文件中的hive.metastore.warehouse.dir属性来配置

示例一中我们使用了scvutil命令自动生成了服务的客户端代理类： svcutil http://localhost:8000/?wsdl /o:FirstServiceClient.cs 命令中 http://localhost:8000/?wsdl 连接返回一个XML，该XML即为元数据：用以描述如何与服务的终结点进行交互。正因为有元数据的存在，svcutil命令才能自动生成客户端代理类。 元数据遵循Web服务描述语言(WSDL)标准，所以可被多种语言支持，除WCF的svcutil外，Java程序员也可使用诸如WSDL2Java的工具生成Java语言的客户端代理类。 WCF服务公开自己的元数据可采用两种方案，一是使用基于HTTP-GET协议提供元数据，二是使用专门的终结点方式。 下面将讲述如何通过配置文件来公开服务的元数据 以HTTP-GET方式公开元数据： 此方法我们在我们前述示例中已经使用 1.在Host项目配置文件中，<service>配置节点中指定behaviorConfiguration值为behaviorConfiguration 2.在<behaviors><serviceBehaviors>下添加一个name属性为behaviorConfiguration的<behavior>节点 3.在<behavior>下添加子节点<serviceMetadata>

摘要：纠结地说，这应该算是一篇关于Attribute 的笔记，其中的一些思路和代码借鉴了他人的文笔（见本文底部链接）。但是，由于此文对Attribute 的讲解实在是叫好（自夸一下 ^_^），所以公之于众，希望能对大家有所帮助。 　　 Attribute与Property 的翻译区别 　　Attribute 一般译作“特性”，Property 仍然译为“属性”。 　　 Attribute 是什么 　　Attribute 是一种可由用户自由定义的修饰符（Modifier），可以用来修饰各种需要被修饰的目标。 　　简单的说，Attribute就是一种“附着物” —— 就像牡蛎吸附在船底或礁石上一样。 　　这些附着物的作用是为它们的附着体追加上一些额外的信息（这些信息就保存在附着物的体内）—— 比如“这个类是我写的”或者“这个函数以前出过问题”等等。 　　 Attribute 的作用 　　特性Attribute 的作用是添加元数据。 　　元数据可以被工具支持，比如：编译器用元数据来辅助编译，调试器用元数据来调试程序。 　　 Attribute 与注释的区别 注释是对程序源代码的一种说明，主要目的是给人看的，在程序被编译的时候会被编译器所丢弃，因此，它丝毫不会影响到程序的执行。 而Attribute是程序代码的一部分，不但不会被编译器丢弃，而且还会被编译器编译进程序集（Assembly

TDD：TEST-DRIVEN Development 测试驱动开发究竟是什么意思？如何理解测试驱动开发？ 举个红绿条简单的例子： 1.编写测试代码 2.编译运行测试代码，肯定会失败，因为实现代码还没有写 3.编写实现代码 4.运行测试观察测试结果，可能是红色的。 5.开发修改代码使得测试通过 6.运行测试，观察测试结果，直到变绿 7.可进行重构，进行代码优化，删除冗余，继续运行测试直到变绿 DDT：DATA-DRIVEN TEST 数据驱动测试是什么意思？如何理解数据驱动测试？ 数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。通过建立测试与开发定义的软件元数据的关联——元数据映射表，在测试与开发之间建立松耦合关系。不论测试人员修改测试脚本，还是开发人员修改软件，只需要修改元数据映射表，既可以满足测试与开发同步进行。这样，可以减少测试脚本调试的工作量，更好的实现自动化测试 什么是数据驱动的自动化测试框架？ 数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中，数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里

第一部分 导论 第1章 商业数据挖掘简介 　1.1 介绍 　1.2 进行数据挖掘需要什么 　1.3 数据挖掘 　1.4 集聚营销 　1.5 商业数据挖掘 　1.6 数据挖掘工具 第2章 数据挖掘过程与知识发 　2.1 CRISP-DM 　2.2 知识发现过程 第3章 数据挖掘的数据库支持 　3.1 数据仓库 　3.2 数据集市 　3.3 联机分析处理 　3.4 数据仓库的实现 　3.5 元数据 　3.6 系统示范 　3.7 数据质量 　3.8 软件产品 　3.9 实例 第二部分 数据挖掘工具 第4章 数据挖掘方法概述 　4.1 数据挖掘方法 　4.2 数据挖掘视野 　4.3 数据挖掘的作用 　4.4 实证数据集 附录4A 第5章 聚类分析 　5.1 聚类分析 　5.2 聚类分析的描述 　5.3 类数量的变动 　5.4 聚类分析的运用 　5.5 在软件中使用聚类分析 　5.6 大数据集的方法运用 　5.7 软件产品 附录5A 第6章 数据挖掘中的回归算法 　6.1 回归模型 　6.2 逻辑回归 　6.3 线性判别分析 　6.4 数据挖掘中回归的实际应用 　6.5 大样本数据集的模型应用 第7章 数据挖掘中的神经网络 　7.1 神经网络 　7.2 数据挖掘中的神经网络 　7.3 神经网络的商业应用 　7.4 神经网络应用于大样本数据集 　7.5 神经网络产品 第8章 决策树算法 　8

安装大概步骤： 1.先安装一台虚拟机，装好jdk，hadoop配置 2.复制克隆出三台，搭建ssh免密登陆 一.先准备一台虚拟机 1.防火墙： 关闭防火墙：systemctl status firewalld 防止防火墙自启：systemctl disable firewalld 2.安装JDK 3.修改主机：hostnamectl set-hostname hdp-01 vi /etc/hosts 追加 192.168.31.114 hdp-01 192.168.31.115 hdp-02 192.168.31.116 hdp-03 192.168.31.117 hdp-04 4.修改hadoop配置 4.1修改hadoop-env.sh export JAVA_HOME=/root/jdk1.8.0_151 4.2修改core-site.xml <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://hdp-01:9000</value> </property> </configuration> 4.3修改hdfs-site.xml <configuration> <property> <name>dfs.namenode.name.dir</name> <value>/root/hdpdata

了解Kafka生产者 ​ 之前对kafka的整体架构有浅显的了解，这次正好有时间，准备深入了解一下kafka，首先先从数据的生产者开始吧。 生产者的整体架构 ​ 可以看到整个生产者进程主要由两个线程进行协调工作，其中一个是主线程，首先由KafkaProducer创建消息，然后通过拦截器、消息序列化器、分区器的处理后，缓存到消息累加器中。另一个是Sender线程，负责从消息累加器中获取消息，并发送至Kafka集群中。 ​ 下面来具体分析各个组件的作用，以便加深了解。 拦截器 ： 从名字就可看出是按照一定规则对消息进行过滤。这个具体的规则可以自己去重写kafka中的ProducerInterceptorPrefix类中的onSend方法来实现。之后在KafkaProducer的配置参数 interceptor.classes中指定该拦截器来进行使用。还可以指定多个拦截器，组成拦截链。 序列化器 ：生产者需要使用它将消息对象转化为字节数组发送给kafka集群。消费者端进行反序列化还原消息对象。kafka中自带序列化器StringSerializer可对String、VyteArray、ByteBuffer等等类型进行序列化。kafka支持自定义序列化器，实现Serializer，重写serialize方法，即可实现自定义序列化器。修改配置文件中的value

（一） Informatica所有的元数据信息均以数据库表的方式存到了元数据库中。当然Infa本身工具提供了很多的人性化的功能，使我们在开发时可以很方便的进行操作，但人们的需求总是万变的，需要方便的取到自己需要的信息，那就需要我们对他的元数据库有很深的了解。 Informatica通过表和视图给我们提供着所有的信息，在此将通过一个系列的帖子，将大部分常见的，且非常有用的表及视图介绍一下。基于这些东西，我们即可以根据不同的需求查出自己需要的数据，也可以开发一些辅助的Infa应用程序。 ///////////////////////////////////////////////////////////////////////////// OPB_ATTR : INFORMATICA (Designer,Workflow等)设计时及服务器设置的所有属性项的名称，当前值及 该属性项的简要说明 Informatica所有的元数据信息均以数据库表的方式存到了元数据库中。当然Infa本身工具提供了很多的人性化的功能，使我们在开发时可以很方便的进行操作，但人们的需求总是万变的，需要方便的取到自己需要的信息，那就需要我们对他的元数据库有很深的了解。 Informatica通过表和视图给我们提供着所有的信息，在此将通过一个系列的帖子，将大部分常见的，且非常有用的表及视图介绍一下。基于这些东西

Informatica 结构 1个或多个资源库（Respository） PowerCenter数据整合引擎是基于元数据驱动的，提供了基于数据驱动的元数据知识库（Repository），该元数据知识库可以在主流的关系型数据库中部署。该院数据库中存储所有的ETL元数据，包括：源、目标表的物理和逻辑元数据，ETL转换规则，知识库用户权限，ETL任务运行历史信息等元数据。 2个Server Informatica Repository Server： 资料库的Server，管理ETL过程中产生的元数据，用来管理所有对资料库中元数据的请求和操作。 Informatica Server： 实际的ETL引擎 5个Client PowerCenter Designer： 设计开发环境，定义源及目标数据结构；设计转换规则，生成ETL映射 Workflow Manager： 合理地实现复杂的ETL工作流，基于时间、事件的作业调度 Workflow Monitor： 监控Workflow和Session 运行情况，生成日志的报告 Repository Manager: 资料库管理，包括安全性管理等，元数据维护和安全操作，如：元数据查找，用户、组、权限管理等。 Repository Server Administrator Console:对知识库的操作，如：知识库的创建、备份，恢复等。