2017年3月月 发布的文章

mybatis #和$的区别

#相当于对数据 加上 双引号,$相当于直接显示数据
1. #将传入的数据都当成一个字符串,会对自动传入的数据加一个双引号。如:order by #user_id#,如果传入的值是111,那么解析成sql时的值为order by “111”, 如果传入的值是id,则解析成的sql为order by “id”.
  
2. $将传入的数据直接显示生成在sql中。如:order by $user_id$,如果传入的值是111,那么解析成sql时的值为order by user_id, 如果传入的值是id,则解析成的sql为order by id.
  
3. #方式能够很大程度防止sql注入。
  
4.$方式无法防止Sql注入。
5.$方式一般用于传入数据库对象,例如传入表名.
  
6.一般能用#的就别用$.
MyBatis排序时使用order by 动态参数时需要注意,用$而不是#
字符串替换
默认情况下,使用#{}格式的语法会导致MyBatis创建预处理语句属性并以它为背景设置安全的值(比如?)。这样做很安全,很迅速也是首选做法,有时你只是想直接在SQL语句中插入一个不改变的字符串。比如,像ORDER BY,你可以这样来使用:
ORDER BY ${columnName}
这里MyBatis不会修改或转义字符串。
重要:接受从用户输出的内容并提供给语句中不变的字符串,这样做是不安全的。这会导致潜在的SQL注入攻击,因此你不应该允许用户输入这些字段,或者通常自行转义并检查。

Hadoop distcp集群间同步数据

hadoop distcp -D ipc.client.fallback-to-simple-auth-allowed=true -log /temp/tianhailong/ webhdfs://10.11.4.240:50070/test/tianhl webhdfs://10.11.1.10/user/hive

遇到的坑:
1、数据所在的集群所有机器,需要配置同步集群的hosts。
2、带有Kerberos安全认证,需要加参数。-D ipc.client.fallback-to-simple-auth-allowed=true
3、 注意运行日志,需要写入有权限的文件夹。 -log /temp/tianhailong/
4、被写入数据的集群是hive用户写入的,需要找一个hive可以写入的权限的文件夹存放数据。/user/hive
 
参数说明:

-m <num_maps> 同时拷贝的最大数目 指定了拷贝数据时map的数目。请注意并不是map数越多吞吐量越大。

参考网址:
https://community.hortonworks.com/questions/294/running-distcp-between-two-cluster-one-kerberized.html
http://stardust.wang/?p=331

维度表和事实表

维度表示你要对数据进行分析时所用的一个量, 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按..分析就构成一个维度。前面的示例就可以有两个维度:类型和区域。另外每个维度还可以有子维度(称为属性),例如类别可以有子类型,产品名等属性。
下面是两个常见的维度表结构:
产品维度表:Prod_id, Product_Name, Category, Color, Size, Price
时间维度表:TimeKey, Season, Year, Month, Date
而事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下:
销售事实表:Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量,以货币计), Unit(销售量)
 
上面的这些表就是存在于数据仓库中的。从这里可以看出它有几个特点:
1. 维度表的冗余很大,主要是因为维度一般不大(相对于事实表来说的),而维度表的冗余可以使事实表节省很多空间。
2. 事实表一般都很大,如果以普通方式查询的话,得到结果一般发的时间都不是我们可以接受的。所以它一般要进行一些特殊处理。如SQL Server 2005就会对事实表进行如预生成处理等。
3. 维度表的主键一般都取整型值的标志列类型,这样也是为了节省事实表的存储空间。
 
事实表和维度表的分界线
事实表是用来存储主题的主干内容的。以日常的工作量为例,工作量可能具有如下属性:工作日期,人员,上班时长,加班时长,工作性质,是否外勤,工作内容,审核人。那么什么才是主干内容?很容易看出上班时长,加班时长是主干,也就是工作量主题的基本内容,那么工作日期,人员,工作性质,是否外勤,工作内容是否为主干信息呢?认真分析特征会发现,日期,人员,性质,是否外勤都是可以被分类的,例如日期有年-月-日的层次,人员也有上下级关系,外勤和正常上班也是两类上班考勤记录,而上班时长和加班时长则不具有此类意义。所以一般把能够分类的属性单独列出来,成为维度表,在事实表中维护事实与维度的引用关系。
在上述例子中,事实表可以设计成如下
WorkDate EmployeeID,WorkTypeID,Islegwork,Content,
而时间,员工,工作类型,是否外勤则归为维度表。
总的来看,和其他建立主外键关系的表也都一样。但是维度表的建立是需要有层次的(虽然不是必须,但是也是典型特征),而事实表的建立是针对已经发生的事实的,是历史数据的存档,也就是说是不应该修改的。以测试部测试软件的Bug为例。每个Bug都是一个事实。这个Bug的状态在数据字典里可能设计成新建,转派,修复,拒绝等等。那么在事实表中Bug表中有一个字段为Status。当测试员或者开发人员改变了这个状态的值,事实表中该如何更新呢?是直接更新Status还是什么其他的方式?显然,为了能够追踪这个Bug的历史信息,应该是重新插入一条新的记录。那么这和以往的数据库设计有什么区别呢?可以看出对于原始记录和新插入的记录,其他字段全部是相同的,也就是全部冗余的。如果以BugID作为主键,这时候会发现主键都是冗余的(当然,插入之前只能删除主键)。所以可以看出,事实表一般是没有主键的。数据的质量完全由业务系统来把握。
总的说来,事实表的设计是以能够正确记录历史信息为准则,维度表的设计是以能够以合适的角度来聚合主题内容为准则。
 
维是分析问题的角度,每一维代表一个统一的访问数据仓库中信息的路径。
在实际问题中,有些维包含多个层次。
事实是各个维度的交点,是对某个特定事件的度量,只有当特定维值的组合没有造成空穴时,一个事实才会存在。事实的数量属性称为度量。
事实数据和维度数据的识别必须依据具体的主题问题而定。“事实表”,用来存储事实的度量(measure)及指向各个维的外键值。维表用来保存该维的元数据,即维的描述信息,包括维的层次及成员类别等

所产生的数据,事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据表包含一个由多个部分组成的索引,该索引包含作为外键的相关性纬度表的主键,而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息,也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。
包含在事实数据表中的“度量值”有两中:一种是可以累计的度量值,另一种是非累计的度量值。最有用的度量值是可累计的度量值,其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息,例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表,单汇总结果一般是没有意义的,例如,在一座大厦的不同位置测量温度时,如果将大厦中所有不同位置的温度累加是没有意义的,但是求平均值是有意义的。
一般来说,一个事实数据表都要和一个或多个纬度表相关联,用户在利用事实数据表创建多维数据集时,可以使用一个或多个维度表。
再举个实际的例子。银行对存款记账,A表中存放实际数据,包括账号、所属机构号、存款金额等,B表存放机构号和机构名称的对应关系。则A是事实表,B是维表。
维度表可以看作是用户来分析数据的窗口,纬度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,维度表包含帮助汇总数据的特性的层次结构。例如,包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构,这些产品中的每一类进一步多次细分,直到各产品达到最低级别。
在维度表中,每个表都包含独立于其他维度表的事实特性,例如,客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。
简单的说:
1、事实表就是你要关注的内容;
2、维表就是你观察该事务的角度,是从哪个角度去观察这个内容的。
例如,某地区商品的销量,是从地区这个角度观察商品销量的。事实表就是销量表,维表就是地区表