hadoop数据容易出现错误的地方

最近在搞关于数据分析的项目，做了一点总结。

下图是系统的数据流向。
容易出现错误的地方。
1、数据进入hadoop仓库
有四种来源，这四种是最基本的数据，简称ods，original data source，后续 的数据都是有这些组合而来
a、日志文件
b、http接口
c、DB查询
d、建表指向
最后数据都是以hadoop文件的形式存放在hadoop中。

日志文件：

• 新增机器没有通知数据分析组抓日志
• 根据约定获取日志是遇到错误，例如：约定获取gz的压缩日志，结果没有
• 数据提供方rsync日志出现问题

http接口：

• 接口不稳定，经常500
• 接口提供的数据本来就是错误的

DB：

• 数据结构的变化没有及时通知数据分析组

建表指向：

• 过了约定的时间，还没有提供

2、hadoop文件
hadoop.apache.org

3、hive
参考资料hive.apache.org
hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。 其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
通过建立hive表，将数据load进入hive表。

drop table if exists rpt_crm_cube_kpi_reserve_room_gb_seq;

create external table rpt_crm_cube_kpi_reserve_room_gb_seq (

    report_date string,

    area_name string,

    manager_name string,

    manager_user_id string,

    assistant_name string,

    hotel_seq string,

    hotel_name string,

    hotel_grade string,

    tree_code string,

    city_name string,

    confirmed bigint,

    reserve_room bigint,

    instant_confirmed bigint

) partitioned by (dt string)

*ROW FORMAT DELIMITED*

*  FIELDS TERMINATED BY '\001'*

*  COLLECTION ITEMS TERMINATED BY '\002'*

*  MAP KEYS TERMINATED BY '\003'*

*  LINES TERMINATED BY '\n'*

*STORED AS INPUTFORMAT*

*  'com.hadoop.mapred.DeprecatedLzoTextInputFormat'*

*OUTPUTFORMAT*

*  'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'*

location '/user/qhstats/rpt/rpt_crm_cube_kpi_reserve_room_gb_seq';

*  *标记的地方为约定好的，不能出错，否则数据载入就会出错 *

    insert overwrite table rpt_crm_cube_kpi_gb_sales partition (dt = '$DATE', kpi = 'all_lose')

    select

        3 as target_id,

        peer.report_date,

        peer.area_name,

        peer.tree_code,

        peer.manager_name,

        peer.manager_user_id,

        peer.object,

        peer.completed,

        rank()   over (partition by peer.tree_code order by if(peer.object = 0, -1, 1 - peer.completed * 1.0 / peer.object) desc) as peer_rank,

        count(1) over (partition by peer.tree_code) as peer_count,

        parent.peer_rank  as parent_rank,

        parent.peer_count as parent_count

    from (

        select

            report_date,

            area_name,

            manager_name,

            manager_user_id,

            tree_code,

            sum(1) as object,

            sum(if(is_lose = 1, 0, 1)) as completed from rpt_crm_cube_kpi_lose_gb_seq where dt = '$DATE' and type='ALL' group by report_date, area_name, manager_name, manager_user_id, tree_code ) peer inner join ( select * from rpt_crm_cube_kpi_gb_tree_code where dt = '$DATE' and kpi = 'all_lose' ) parent on peer.tree_code = parent.tree_code; EOF } 

容易出错的地方：

• 列的数据类型需要明确，否则有字符串到hive表转换的时候会发生错误。例如在文件里边是 ‘xiaoqiang’，列类型却设置为bigint，最后数据会为null。

4、hive表导入到DB

hive的数据可以导入到DB

function export_to_crm_cube {

    $HIVE -e "select * from rpt_crm_cube_kpi_gb_sales where dt = '$DATE' and kpi = 'all_lose' " > $TMP_FILE



    $crm_cube_DEV_STR << EOF

    delete from crm_cube_kpi_gb_sales where report_date = '$FORMAT_DATE' and target_id = 3;



    load data local infile '$TMP_FILE'

    into table crm_cube_kpi_gb_sales (

        target_id,

        report_date,

        area,

        tree_code,

        manager_name,

        manager_user_id,

        object_cnt,

        completed_cnt,

        peer_rank,

        peer_cnt,

        parent_rank,

        parent_cnt

    );



EOF

}

容易出错的地方：

• 数据类型的转换，数据分析组统计有50%多的概率出现数据类型转换的问题

5、DB到app

DB到App中，数据已经固化在DB了，剩下的就是把数据呈献给用户，这时候数据的准确性就需要保证了。

数据的准确性保证需要依赖一下几点：

取数的正确性，从那些地方取数据。
数据逻辑的正确性，产品提供的数据逻辑是否正确。
数据的准确性，数据逻辑翻译为代码是否正确
前端的呈现，数据都吐正确了，前端是否正确的展现给用户。

 

总结了数据从hadoop到用户过程中，如意出错的地方，知道那可以出错了，就知道该怎么应对了。