数据仓库-易错点

转自：博客园-liuweiqiang2v

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

下图是系统的数据流向。
容易出现错误的地方。
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到用户过程中，如意出错的地方，知道那可以出错了，就知道该怎么应对了。