hadoop平台工作梳理，hadoop平台梳理

hadoop平台工作梳理，hadoop平台梳理

  文章出自 http://blog.csdn.net/lili72/article/details/41130743

   lili72 

数据平台：

                  一、  hadoop平台：Hbase，hive,storm,spark
                        1） 部署hadoop到多台机器，调整配置参数，保证正常运行。可能出现作业挂死现象。
                        2） 部署hive客户端，元数据库mysql等的配置，hive客户端是不参与集群的，mysql也是安置在另外一台服务器上集群的。
                        3） 部署Hbase,storm,spark
                  二 、 调度系统: 数据是每天接入可以看做是每天要跑的任务，而且任务间存在依赖，需要完善的依赖触发机制。
                         1） 把所有的脚本或者MR，包括数据接入，数据清洗，数据加工都配置成一个个的任务，记录这些任务的运行时间，是否存在依赖等
                         2） 各种类型的任务一定要可控，比如，MR，shell，hive命令统一记录对应信息，方便下面的监控预警系统。    
                  三、 监控预警系统：
                            1） 平台监控与预警：
                                1.1  hadoop本身的监控系统，看job运行状况。
                                1.2  还有对lunix服务器的io，cpu，硬盘大小做监控，超过阀值，则发信息通知对应的负责人。
                            2） 任务监控与预警：
                                2.1  任务包括但不仅限于数据采集任务，ETL任务，同步到mysql的任务。这里的任务可能是一个MR，或者是一个shell脚本，或者其他程序。
                                      监控这些任务的执行情况，记录报错日志，发送报错信息到对应负责人。
                            3） 数据质量监控与预警
                               3.1  检查当天数据源是否正常，比如文件个数，文件大小，文件到达时间等，如果数据源有问题，其实任务调度系统就停在数据源采集任务步骤。
                               3.2  检查各数据的指标项的同比，环比，增幅等，看是否有超过阀值的数据，有责预警。
                          
                  四、 报表展示
                         1） 前端html5或者hightchars或者多维报表工具展现
                       
     数据架构：
    1、 首先总体来说，数据是分3层的
        1.1  s48-源数据层： 
            1.1.1 文件来源，分布到多台机器文本文件，按天或者按小时生成的文件，通过shell脚本，执行定时远程复制，把数据转移到hdfs中的hive里，按天或小时分区，甚至按分钟。
                  操作方式：hive -e \"LOAD DATA LOCAL INPATH '${SourPath}/${day}/${hour}' OVERWRITE INTO TABLE xxx_database.xxx_table PARTITION (dt='${day}',db=${hour});\"
                  优点：操作简便，缺点：无法确保数据的完整性，如果数据没有正常提供，load命令报错，需要在load之前加.ok 文件，确保文件已经完整提供。
                     时间点依赖，如果文件没有按时过来，该load命令需要推迟执行。（结合调度系统使用）
            1.1.2 关系型数据库来源，比如mysql，sqlserver，oracle。通过定时sqoop到hive中，或者通过开源工具kettle同步到hive，或者写MR定制导入数据。
                  操作方式：分增量或者全量的方式，sqoop 命令，有时sqoop异常，比如源数据库所在网络组和集群不在同一个网段，源数据存在特殊字符JDBC-connective不支持
                            使用kettle生成文件，然后导入到hive
                   总结：三种方式各有各的优点和局限性。
            1.1.3 通过kafka主题分发。实时消费，解析json数据，按天存放到txt文件，然后导入到hive中。有异常（无法解析。不符合json格式）数据放到bad.txt,其它放在正常业务数据中
                  保留一份解析前的数据，同时生成一份解析后的数据，自动load到hive中。或者数据直接进入storm中，进行实时计算。
        1.2  t48-数据清洗
            1.2.1 轻度清洗，比如去除重复数据（使用udf的row_number）,替换某些字符（replace），切分某些字段（可能一个字段包含多个语义）。
            1.2.3 要充分考虑使用hive的时候，hql的可优化性，减轻平台负担。
        1.3  t68-数据加工，etl过程，分组
            1.3.1 根据业务含义，按照不同纬度（平台，版本，渠道，类型，日期等）汇总，关联计算等，（比如留存率，活跃用户数，用户流失率，总用户数，总登陆次数等），
            包括行转列，列转行。这个过程主要是case when，group by ,(with CUBE ,ROLLUP，GROUPING SETS ）等。
        1.4  sqoop到mysql中，或者送到指定的路径，通过webservice接口服务。
             1.4.1 通过sqoop命令或者自定义MR处理特殊的某些数据，从hive到mysql，由于某些字符集mysql版本不支持。
   
   （所有的操作都要考虑重跑机制，出错自动重新发起，追历史数据，支持传入参数，有默认参数值）
     1 接口确定：
      前置条件：业务提出需求形成需求文档。
      工作内容：评估需求可行性（根据目前数据平台架构，是否能满足业务的需要），分析需求涉及的接口范围，及时和业务沟通需求点，评估需求花费时间，发需求确认邮件。
      产出结果： 确认好的接口文档。（接口文档包括建表的每个字段英文和中文说明，表名称说明，从源到下一层的映射关系具体说明，码值含义，评估的每天数据量，保存周期） 
     2 ETL开发：（包括数据清洗和数据加工）
       前置条件：接口文档已经确定完成
       工作内容：ETL过程设计，根据接口文档建好表，根据ETL设计文档，编写代码，验证逻辑。大多都是写hive sql来完成。也有些也需要自定义MR来写，比如（ip转数字，），自定义udf函数
                 处理（row_number(),过滤特殊字符的udf，ip省市映射）
       产出结果：etl设计文档，etl代码（sql或Java）
     3 报表展现：
       前置条件：etl已经产出结果
       工作内容：sqoop dm层数据到mysql或者自定义MR导出数据到mysql，前端html5个性化展示，或者hightchar
       产出结果：业务能前台，按各种查询条件获得所需要的数据展现。
       
     4 报表审核：
       前置条件：报表开发已经完成。
       工作内容：根据业务需求，有针对性的检查数据真实性，有效性。
       产出结果：审核文档，保证报表数据质量准确。
       
      5 交付验收：业务工作真实使用。