hadoop工作平台梳理

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

lili72

数据平台：

一、  hadoop平台：Hbase。hive,storm,spark

                        1） 部署hadoop到多台机器，调整配置參数，保证正常执行。可能出现作业挂死现象。

                        2） 部署hiveclient，元数据库mysql等的配置，hiveclient是不參与集群的。mysql也是安置在另外一台server上集群的。

3） 部署Hbase,storm,spark

                  二 、 调度系统: 数据是每天接入能够看做是每天要跑的任务。并且任务间存在依赖，须要完好的依赖触发机制。

1） 把全部的脚本或者MR，包含数据接入。数据清洗，数据加工都配置成一个个的任务。记录这些任务的执行时间，是否存在依赖等

                         2） 各种类型的任务一定要可控。比方。MR，shell，hive命令统一记录相应信息。方便以下的监控预警系统。

三、 监控预警系统：

                            1） 平台监控与预警：

                                1.1  hadoop本身的监控系统。看job执行状况。

                                1.2  还有对lunixserver的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 交货验收：操作实际使用。

版权声明：本文博客原创文章。博客，未经同意，不得转载。