打字猴:1.70050935e+09
1700509350 这种语句。
1700509351
1700509352 以上语句实际上就是把本地文件“/Linklog_20161122.txt”复制到集群hdfs:///user/hive/ warehouse中去。这里为什么不使用事务呢?因为在OLAP环境中,数据一般都是已经存在的历史数据,几乎没有回退的机会。如果一定要使用事务,就必须有与Oracle结构相同的更新逻辑。
1700509353
1700509354 以更新一个数据块D为例,如图13-6所示。
1700509355
1700509356
1700509357
1700509358
1700509359 图13-6 事务中的Undo和Redo
1700509360
1700509361 (1)要更新数据块D的时候,为了保证事务隔离,首先必须保证其他事务能访问提交前的数据块D,此时会生成一个Undo块信息U来记录数据块D更新前的信息。
1700509362
1700509363 (2)生成一个Redo信息来记录Undo块涉及的修改内容,包括U的地址、U的内容、事务标识(事务号)。
1700509364
1700509365 (3)修改数据块D的内容,同时产生一个Redo信息,包括数据块D的地址、数据块D修改后的内容、事务标识。
1700509366
1700509367 如果此时用户提交了Commit命令,那么Undo块信息U的内容就会被释放,事务将无法回滚。如果此时提交了Rollback命令,那么数据块D的内容会被Undo块信息U的内容替换。这两种情况都标志着这次事务操作的结束。而在事务操作结束之前,任何涉及数据块D的读操作都会命中Undo块信息U,而不是数据块D。这种方式能够在事务的一致性、回滚速度等方面实现极好的平衡。不过我们也可以清楚地看到,一个数据块的I/O操作实际上产生了若干个数据块的I/O操作,而且这里还没有讨论数据块D涉及的索引块对应的改动操作及锁机制,这些操作对一个OLAP环境来说基本上是不需要的。如果发生了,就意味着极大的I/O开销。OLAP环境中的更新操作一般情况下都是整片数据的删改问题,所以完全没有必要做基于记录层的事务,直接使用文件会使开销更小。
1700509368
1700509369 在Hadoop的HDFS中写一个文件(就像刚刚用HiveQL做LOAD命令那样),会引发对一个文件的复制操作。这个过程是一个轻型的复制过程,如图13-7所示。
1700509370
1700509371
1700509372
1700509373
1700509374 图13-7 Hadoop HDFS写文件流程
1700509375
1700509376 (1)客户端会向NameNode发出一个写入请求。
1700509377
1700509378 (2)客户端直接向某一台DataNode写入文件块。
1700509379
1700509380 (3)DataNode会根据集群配置中的Replication数量做DataNode之间的文件块同步。
1700509381
1700509382 (4)写完后,客户端会关闭写连接,并向NameNode同步一个写完毕的信息。
1700509383
1700509384 这种流程的好处显而易见——中心压力小,写分散,单次写入信息多,从而减少了平摊写入开销。所以,基于HDFS的Hive成为一种永久存储环境下性价比很高的解决方案。
1700509385
1700509386
1700509387
1700509388
1700509389 数据科学家养成手册 [:1700503625]
1700509390 数据科学家养成手册 13.5 表分区和索引
1700509391
1700509392 为了提高检索效率,有时需要建立表分区和索引。
1700509393
1700509394 索引大家应该不会陌生,在OLTP环境中就经常使用它。索引的好处是检索的时候能够有效避开很多不必要的数据块扫描,坏处是在进行数据插入、更新、删除的时候需要重新对索引进行维护,这是一笔时间开销。常见的索引有B-Tree索引、Hash索引、Bitmap索引,它们都能在不同的场合加快检索速度,但是通常也有各自的局限性。
1700509395
1700509396 在OLTP环境中,只要索引设计合理,通常都能够加快检索速度,同时降低一定的更新速度。而在OLAP环境中,在实践过程中我们可能会感受到,在很多场合,索引对检索的加速效果不明显。
1700509397
1700509398 数据科学家养成手册 [:1700503626]
1700509399 13.5.1 表分区
[ 上一页 ]  [ :1.70050935e+09 ]  [ 下一页 ]