大数据维护指南（2）

1、关于代码编写：
大S 主要采用spark来控制主要流程。不管是kafka到hdfs，还是HDFS到hbase，以及后面的任务。所以spark的代码一定要高质量。
1、如果你spark访问hbase，访问kafka，尽量参考我们提供的spark提供的用例代码。我相信你有能力写好自己的接口，但你不该发费太多时间去研究这些。后续调优发的时间远比你用的多。除非提供的接口已经无法满足你的要求。

我们提供了
1） spark 读kafka，spark 读 hbase，spark读HDFS等
2） 写 kakfa，写hbase，写HDFS等
3) bulkload 的，基本覆盖了常用场景
具体内容见附件  

关于spark代码：以下几点可以参考。 
1）如果一个RDD被多次使用，可以考虑使用RDD.cache功能
2）尽量不要在RDD中定义集合，然后采用集合来缓存数据，然后返回list.iterator方法。因为可能在你不知情况下。内存已经无法放下你需要的数据。导致内存溢出。
应该优先使用new Iterator。实现next和hasNext

3）如果需要在RDD里加载配置，或者连接其他组件。优先mapPartitionsWithIndex和mapPartitions，因为该算子传给你的是迭代器，而不是一条条记录，你可以在迭代器外面实现你的加载配置或者连接功能。减少不必要的加载。
4、如果将2和3结合用那就完美。
5、序列化问题.KryoSeralizer 是JavaSerializer的10倍。实现可以参考附件案例 SparkHbasetoHbasePythonExample。下面是产品文档原话

6、对于配置,小量的数据，不要在算子RDD中加载。尽量使用广播。

7、如果任务确定存在长尾现象，或者整个job中只有少量stage需要大量的executor，可以采用动态资源调度，如果没有上述情况，尽量就别用动态资源分配方式了。动态分配没有那么乐观。不停申请，不停kill。带来更多负担。主要是涉及数据传递时，问题更多。
开启方式，spark.dynamicAllocation.enabled=true，相关配置

以上就是spark开发的问题。

其他知识点：
hbase基础
了解hbase，主要了解三个方面 1） zookeeper的hbase目录， 2）HDFS的hbase目录。3）页面；4）hbase shell
1）zookeeper上面的是给维护和内核开发看的。对于业务开发是透明的。感兴趣的去看看就行，就别操作了。

2）HDFS是主要的数据存储地方
数据目录结构如下:
/hbase/data/default/table/regionName/fimilyName/Hfile

对开发而言，只需要了解表的大小，region的大小。其他基本可以不用了解。
HDFS主要用来统计表占用的内存大小。
hdfs dfs -du -h /hbase/data/default/
region占用的内存大小
hdfs dfs -du -h /hbase/data/default/test2/
  
mob文件在 /hbase/mobdir 目录下面，单独管理

注意1：不管基于什么原因，不要随意直接删除底层文件，删除后不会立即报错，但是以后一定会出问题。 如果要删除表。通过hbase shell命令
disable 'tableName'
drop 'tableName'

3) 页面：
入口：

通过页面可以看到目前表的建表语句，region个数，

也可以通过表详情，可以看到region的所在机器，也可以知道startkey和endkey。
本地化：指HDFS的文件和region在同一机器上的大小。本地化越高越好范围（0-1）。0可能是没有数据。
请求量：上次重启到目前的请求量。累计值。重启消失。

4）综合：

注意1：目前的region的hbase.hregion.max.filesize值为100G。如果数据写满，这个对查询影响还是很大的。按照网页库100P计算。MOB文件大小和HFile大小比为33:1 所以hfile文件只有3P，按10 G 一个region。也就是300000。最终500台机器。也就是每个rs上600个region。因为主要支撑查询。活跃region多一点问题也不是很大，不过减少分裂。可以适当调整hbase.hregion.max.filesize到20G。100000 region。

注意2：文件增加到一定后，肯定会使用到联邦。到时不支持夸Namenode的rename（move）动作。只支撑copy。性能会下降的。bulkload的load过程会很明显的。poc阶段应该考虑进去。

注意3：已经说到联邦。所有的目录也应该做好规范。虽然以后能迁移，但是挺麻烦的。

注意4、HDFS上的数据是hbase累计状态，页面显示的是瞬时状态。如果发现HDFS上的region个数比页面显示的多。不要奇怪，正常现象。一定是region split了。

注意5、直接删HDFS上的数据，一般要等到重启时才表现出来。所以不要为自己删除成功而沾沾自喜。

注意6、hbase管理region是要成本的。规范是单RS上的region总数不要超过2000,活跃region不要大于200。超过指标不会带来立即的后果。但是可能会通过查询性能下降，GC严重等情况在无形中影响。

注意7、目前写入采用的都是bulkload方法，读取都是scan方法。没有优化的可能。但是如果以后采用put和get。记得尽量采用putList 和getList获取结构‘

注意8、bulkload会按照一个region一个列族生成一个HFile文件。

注意9、目前bulkload导入数据的时候是没有开启压缩功能的。所以开始时会有点膨胀，但是到hbase的合并时会做压缩。如果第二天发现数据量少了点，也不用奇怪了。

3、Spark结构：
1、重页面看，spark分为spark-Resource，spark-jobhistory。spark-jdbc。
1）spark-Resource：
   作用完全弱化，只剩下方便配置统一修改。停用，或者卸载对业务都没有任何影响。
2）spark-jobhistory
   作用：spark任务结束，还能留点念想。
3）spark-jdbc
   作用：采用spark-beeline来访问。

对于目前大S而言。如果已经安装spark客户端，spark的服务基本可以停用。不过本身不占什么资源，没必要停用而已。

说的更明白点：spark只是Yarn的application应用。因此对yarn的理解比对spark理解更重要。同样也应因此任何spark的配置修改客户端配置即可。不过为了减少相互影响，尽量采用--conf 放入带入。

4、Mapreduce 功能同上。

HDFS&YARN篇
1）hdfs文件一般三副本构成，一般很少出现三副本都损坏的场景，所以客户端操作时都能正确操作文件，但是当文件非正常关闭时，hdfs记录文件处于正在写的状态，会导致其他客户端无法操作此文件，报错Cannot obtain block length,这种情况一般要先找到这个文件hdfs fsck –blockId blk_123124(块Id) 找到这个文件 ，hdfs debug -recoverLease -path /tmp/test.txt -retries 10 恢复这个文件 
2）通过hdfs dfs –du –h 目录，可以查看目录下存储的文件占用空间大小，通过hdfs dfs –count –q –v –h 目录，可以查看目录下有多少文件和目录
3）目前设置队列资源时，都只关注队列使用的资源，但是很少关注队列对任务AM资源的限制，每个任务都有一个AM，队列里面所有AM资源的总和不能超过队列设置的AM资源限制，当AM使用达到限制时会导致任务一直处于accept状态，当然队列本身资源的限制也会导致队列处于accept状态
4）大部分情况，任务提交后，提交任务的用户可以在界面提交后可通过提交的用户在界面能正常打开任务详情，但是机机账户受限于登录界面，只能通过其他用户查看任务，spark默认情况下配置了admin用户查看yarn的UI，其他用户不在其列，可以在spark客户端加上，“spark.ui.view.acls”：指定yarn界面的访问者列表，详细可参考产品文档
5） yarn 其实是cpu，内存虚拟后的结果。方便统一管理。不管MR还是Spark。申请资源都是yarn的资源。

6）hdfs 联邦不支持rename： 数量量大后面肯定会用到联邦。联邦其实就是将两个分开的文件系统统一管理。类似于C盘和d盘。不支持跨盘rename。只能copy。如果在写代码是记得将其加入。
if (resSrc.targetFileSystem.getUri().equals( resDst.targetFileSystem.getUri())){
    rename src to dst
}else{
   copy  src to dst
   delete(Src)
}

Kafka篇
1）kafka 安全接口是21007端口，默认使用用户密码认证，security.protocol 配置为SASL_PLAINTEXT，如果你使用的是21005，security.protocol配置为PLAIN_TEXT
2）kafka 的数据是以pardition来分布在broker节点的磁盘上，如果你的数据量非常大，建议pardition分多点，具体可以参考《性能调优指南》进行划分，
若pardition较少，很容易导致单盘存储满
3）linger.ms=0，Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送，以此提高吞吐量，而linger.ms则更进一步，这个参数为每次发送增加一些delay，以此来聚合更多的Message

7、关于Python，
因为spark，hbase本身基于cala和java，FI不管是维护还是研发。对python的理解都不够，常用问题好解决。但是出现不常见问题，定位时间会明显加长。目前对大数据应用开发方面尽量选择java或scala语言。