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到用户过程中，如意出错的地方，知道那可以出错了，就知道该怎么应对了。