大数据安全控制和场景分析

1、如何实现 hadoop 的安全机制。
    1.1 共享 hadoop 集群:
        a: 管理人员把开发人员分成了若干个队列，每个队列有一定的资源，每个用户及用户组只能使用某个队列中指定资源。
        b: HDFS 上有各种数据，公用的，私有的，加密的。不用的用户可以访问不同的数据。
    1.2 HDFS 安全机制
        client 获取 namenode 的初始访问认证( 使用 kerberos )后，会获取一个 delegation token，这个token 可以作为接下来访问 HDFS 或提交作业的认证。
        同样，读取 block 也是一样的。
    1.3 mapreduce 安全机制
        所有关于作业的提交或者作业运行状态的追踪均是采用带有 Kerberos 认证的 RPC 实现的。授权用户提交作业时，JobTracker 会为之生成一个 delegation token，
        该 token 将被作为 job 的一部分存储到 HDFS上并通过 RPC 分发给各个 TaskTracker，一旦 job 运行结束，该 token 失效。
    1.4 DistributedCache 是安全的。
        DistribuedCache 分别两种，一种是 shared，可以被所有作业共享，而 private 的只能被该用户的作业共享。
    1.5 RPC 安全机制
        在 Hadoop RP 中添加了权限认证授权机制。当用户调用 RPC 时，用户的 login name 会通过 RPC 头部传递给 RPC，之后 RPC 使用 Simple Authentication and Security Layer（SASL）确定一个权限协议（支持 Kerberos 和 DIGEST-MD5 两种），完成 RPC 授权。

2、hbase和hdfs使用场景分析
    HDFS： 
        1、一次性写入，多次读取。
        2、保证数据的一致性。
        3、主要是可以部署在许多廉价机器中，通过多副本提高可靠性，提供了容错和恢复机制。
    Hbase： 
        1、瞬间写入量很大，数据库不好支撑或需要很高成本支撑的场景。
        2、数据需要长久保存，且量会持久增长到比较大的场景
        3、hbase 不适用与有 join，多级索引，表关系复杂的数据模型
        4、大数据量 （100s TB 级数据） 且有快速随机访问的需求。
        5、容量的优雅扩展大数据的驱使，动态扩展系统容量的必须的。例如：webPage DB。 
        6、业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）
        7、优化方面：合理设计 rowkey。因为 hbase 的查
        6、hbase 的 rowkey 设计，影响 hbase 的性能有哪些。

3、hbase设计问题

  a、 hbase.hregion.max.filesize 应该设置多少合适。
    默认是 256，HStoreFile 的最大值。如果任何一个 Column Family（或者说 HStore）的 HStoreFiles 的大小超过这个值，那么，其所属的 HRegion 就会 Split 成两个。
    众所周知 hbase 中数据一开始会写入 memstore，当 memstore 满 64MB 以后，会 flush 到 disk 上而成为storefile。
    当 storefile 数量超过 3 时，会启动 compaction 过程将它们合并为一个 storefile。这个过程中会删除一些 timestamp 过期的数据，比如 update 的数据。
    而当合并后的 storefile 大小大于 hfile 默认最大值时，会触发 split 动作，将它切分成两个 region。 
b、autoflush=false 的影响
 无论是官方还是很多 blog 都提倡为了提高 hbase 的写入速度而在应用代码中设置 autoflush=false，然后 lz 认为在在线应用中应该谨慎进行该设置 原因如下：
     2.1、autoflush=false 的原理是当客户端提交 delete 或 put 请求时，将该请求在客户端缓存，直到数据超过 2M(hbase.client.write.buffer 决定)
     或用户执行了 hbase.flushcommits()时才向 regionserver 提交请求。因此即使 htable.put()执行返回成功，也并非说明请求真的成功了。
     假如还没有达到该缓存而 client 崩溃，该部分数据将由于未发送到 regionserver 而丢失。这对于零容忍的在线服务是不可接受的。
     2.2、autoflush=true 虽然会让写入速度下降 2-3 倍，但是对于很多在线应用来说这都是必须打开的，也正是 hbase 为什么让它默认值为 true 的原因。
     当该值为 true 时，每次请求都会发往 regionserver,而regionserver 接收到请求后第一件事就是写 hlog，因此对 io 的要求是非常高的，为了提高 hbase 的写入速度，
     应该尽可能高地提高 io 吞吐量，比如增加磁盘、使用 raid 卡、减少 replication 因子数等 。

c对于传统关系型数据库中的一张 table，在业务转换到 hbase 上建模时，从性能的角度应该如何设置 family和 qualifier 呢？
    最极端的，①每一列都设置成一个 family，②一个表仅有一个 family，所有列都是其中的一个 qualifier，那么有什么区别呢？
    从读的方面考虑：
        family 越多，那么获取每一个 cell 数据的优势越明显，因为 io 和网络都减少了。
        如果只有一个 family，那么每一次读都会读取当前 rowkey 的所有数据，网络和 io 上会有一些损失。
        当然如果要获取的是固定的几列数据，那么把这几列写到一个 family 中比分别设置 family 要更好，因
        为只需一次请求就能拿回所有数据。
    从写的角度考虑：
        首先，内存方面来说，对于一个Region，会为每一个表的每一个Family分配一个Store，而每一个Store，
        都会分配一个 MemStore，所以更多的 family 会消耗更多的内存。
        其次，从 flush 和 compaction 方面说，目前版本的 hbase，在 flush 和 compaction 都是以 region 为单位的，
        也就是说当一个 family 达到 flush 条件时，该 region 的所有 family 所属的 memstore 都会 flush 一次，
        即使 memstore 中只有很少的数据也会触发 flush 而生成小文件。这样就增加了 compaction 发生的机率，
        而 compaction 也是以 region 为单位的，这样就很容易发生 compaction 风暴从而降低系统的整体吞吐量。
    第三，从 split 方面考虑，由于 hfile 是以 family 为单位的，因此对于多个 family 来说，数据被分散到了更多的 hfile 中，减小了 split 发生的机率。
    这是把双刃剑。更少的 split 会导致该 region 的体积比较大，由于 balance 是以 region 的数目而不是大小为单位来进行的，因此可能会导致 balance 失效。
    而从好的方面来说，更少的 split 会让系统提供更加稳定的在线服务。而坏处我们可以通过在请求的低谷时间进行人工的 split 和 balance 来避免掉。
    因此对于写比较多的系统，如果是离线应该，我们尽量只用一个 family 好了，但如果是在线应用，那还是应该根据应用的情况合理地分配 family

3、redis 分布式实现原理。如何实现读写分离，在这个过程当中使用了哪些算法，有什么好处。
    memcache 只能说是简单的 kv 内存数据结构,而 redis 支持的数据类型比较丰富。Redis 在 3.0 以后实现集群机制。
    目前 Redis 实现集群的方法主要是采用一致性哈稀分片（Shard），将不同的 key 分配到不同的 redis server 上，达到横向扩展的目的。
    使用了一致性哈稀进行分片，那么不同的 key 分布到不同的 Redis-Server 上，当我们需要扩容时，需要增加机器到分片列表中，这时候会使得同样的 key 算出来落到跟原来不同的机器上，
    这样如果要取某一个值，会出现取不到的情况，对于这种情况，Redis 的提出了一种名为 Pre-Sharding 的方式：
    使用了 redis 的集群模式：存在以下几个问题
        A：扩容问题：
        Pre-Sharding 方法是将每一个台物理机上，运行多个不同断口的 Redis 实例，假如有三个物理机，每个物理机运行三个 Redis 实际，
        那么我们的分片列表中实际有 9 个 Redis 实例，当我们需要扩容时，增加一台物理机，步骤如下：
            1、在新的物理机上运行 Redis-Server； 
            2、该 Redis-Server 从属于(slaveof)分片列表中的某一 Redis-Server（假设叫 RedisA）；
            3、等主从复制(Replication)完成后，将客户端分片列表中 RedisA 的 IP 和端口改为新物理机上 Redis-Server的 IP 和端口；
            4、停止 RedisA.
        B: 单点故障问题
            将一个 Redis-Server 转移到了另外一台上。Prd-Sharding 实际上是一种在线扩容的办法，但还是很依赖Redis 本身的复制功能的，
            如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。