总体介绍
Home Credit Default Risk是Home Credit公司在kaggle上的一个信贷风险评估竞赛。其提供的数据文件描述及文件间关联关系如下：
有些金融专有名词尤其是一些公司产品的专有名词对于我们外行人员来说相当难理解了，所以我查看了下公司官网，给出了一些背景介绍，有助于理解数据吧。
Home Credit公司的商业模式其实跟支付宝的某些部分很像，后面会类比。一个信用贷款公司的为一个在本公司没有信用记录的用户提供信用贷款是有很大风险的，当然一般冷启动的做法可以是查询用户在信用局的历史征信记录来作为风险评估的参考，数据文件中的bureau.csv和 bureau_balance.csv 就对应这部分数据
此外信用贷款公司还需要逐步引导用户使用自己公司的金融产品，来建立自己的信用体系。Home Credit公司的产品也是循序渐进的，其中Point-of-sale (POS) loans就是一款入门级产品，对于一些价值不高的零售业商品（预计普通人都能承受起的商品），引导用户通过该产品分期付款，从而建立初步的信用数据，这么说起来就很像我们常用的支付宝的花呗功能了，POS_CASH_balance.csv 中的数据就来源于此。该产品体系图如下：
在此基础上衍生出的进阶产品就有Credit cards，可以理解为信用贷款吧，类似于支付宝的借呗 功能，用户使用该产品产生的信用记录就对应于credit_card_balance.csv 中的数据。
application_{train|test}.csv字段介绍
各个文件的字段含义在HomeCredit_columns_description.csv 中都有介绍。大部分人应该都只关心这些特征（字段）或字段的组合和目标的关联（可通过机器学习算法学习出来），而不在意具体的字段含义。这里还是罗列一下 application_{train|test}.csv 这个主要数据文件的字段含义，私以为真正的数据分析还是需要对业务有一定的理解的吧，此外也给我们一个参考类似的问题需要采集哪些数据来建模分析。对应于申请人本次贷款申请的申请信息，分为训练数据和测试数据。其主要数据字段含义如下：
| 字段 | 含义 |
|---|---|
| SK_ID_CURR | 此次申请的ID |
| TARGET | 申请人本次申请的还款风险：1-风险较高；0-风险较低 |
| NAME_CONTRACT_TYPE | 贷款类型：cash(现金)还是revolving(周转金，一次申请，多次循环提取) |
| CODE_GENDER | 申请人性别 |
| FLAG_OWN_CAR | 申请人是否有车 |
| FLAG_OWN_REALTY | 申请人是否有房 |
| CNT_CHILDREN | 申请人子女个数 |
| AMT_INCOME_TOTAL | 申请人收入状况 |
| AMT_CREDIT | 此次申请的贷款金额 |
| AMT_ANNUITY | 贷款年金 |
| AMT_GOODS_PRICE | 如果是消费贷款，改字段表示商品的实际价格 |
| NAME_TYPE_SUITE | 申请人此次申请的陪同人员 |
| NAME_INCOME_TYPE | 申请人收入类型 |
| NAME_EDUCATION_TYPE | 申请人受教育程度 |
| NAME_FAMILY_STATUS | 申请人婚姻状况 |
| NAME_HOUSING_TYPE | 申请人居住状况（租房，已购房，和父母一起住等） |
| REGION_POPULATION_RELATIVE | 申请人居住地人口密度，已标准化 |
| DAYS_BIRTH | 申请人出生日（距离申请当日的天数，负值） |
| DAYS_EMPLOYED | 申请人当前工作的工作年限（距离申请当日的天数，负值） |
| DAYS_REGISTRATION | 申请人最近一次修改注册信息的时间（距离申请当日的天数，负值） |
| DAYS_ID_PUBLISH | 申请人最近一次修改申请贷款的身份证明文件的时间（距离申请当日的天数，负值） |
| FLAG_MOBIL | 申请人是否提供个人电话（1-yes，0-no） |
| FLAG_EMP_PHONE | 申请人是否提供家庭电话（1-yes，0-no） |
| FLAG_WORK_PHONE | 申请人是否提供工作电话（1-yes，0-no） |
| FLAG_CONT_MOBILE | 申请人个人电话是否能拨通（1-yes，0-no） |
| FLAG_EMAIL | 申请人是否提供电子邮箱（1-yes，0-no） |
| OCCUPATION_TYPE | 申请人职务 |
| REGION_RATING_CLIENT | 本公司对申请人居住区域的评分等级（1,2,3） |
| REGION_RATING_CLIENT_W_CITY | 在考虑所在城市的情况下，本公司对申请人居住区域的评分等级（1,2,3） |
| WEEKDAY_APPR_PROCESS_START | 申请人发起申请日是星期几 |
| HOUR_APPR_PROCESS_START | 申请人发起申请的hour |
| REG_REGION_NOT_LIVE_REGION | 申请人提供的的永久地址和联系地址是否匹配（1-不匹配，2-匹配，区域级别的） |
| REG_REGION_NOT_WORK_REGION | 申请人提供的的永久地址和工作地址是否匹配（1-不匹配，2-匹配，区域级别的） |
| LIVE_REGION_NOT_WORK_REGION | 申请人提供的的联系地址和工作地址是否匹配（1-不匹配，2-匹配，区域级别的） |
| REG_CITY_NOT_LIVE_CITY | 申请人提供的的永久地址和联系地址是否匹配（1-不匹配，2-匹配，城市级别的） |
| REG_CITY_NOT_WORK_CITY | 申请人提供的的永久地址和工作地址是否匹配（1-不匹配，2-匹配，城市级别的） |
| LIVE_CITY_NOT_WORK_CITY | 申请人提供的的联系地址和工作地址是否匹配（1-不匹配，2-匹配，城市级别的） |
| ORGANIZATION_TYPE | 申请人工作所属组织类型 |
| EXT_SOURCE_1 | 外部数据源1的标准化评分 |
| EXT_SOURCE_2 | 外部数据源2的标准化评分 |
| EXT_SOURCE_3 | 外部数据源3的标准化评分 |
| APARTMENTS_AVG <----> EMERGENCYSTATE_MODE | 申请人居住环境各项指标的标准化评分 |
| OBS_30_CNT_SOCIAL_CIRC LE <----> DEF_60_CNT_SOCIAL_CIRCLE | 这部分字段含义没看懂 |
| DAYS_LAST_PHONE_CHANGE | 申请人最近一次修改手机号码的时间（距离申请当日的天数，负值） |
| FLAG_DOCUMENT_2 <----> FLAG_DOCUMENT_21 | 申请人是否额外提供了文件2,3,4. . .21 |
| AMT_REQ_CREDIT_BUREAU_HOUR | 申请人发起申请前1个小时以内，被查询征信的次数 |
| AMT_REQ_CREDIT_BUREAU_DAY | 申请人发起申请前一天以内，被查询征信的次数 |
| AMT_REQ_CREDIT_BUREAU_WEEK | 申请人发起申请前一周以内，被查询征信的次数 |
| AMT_REQ_CREDIT_BUREAU_MONTH | 申请人发起申请前一个月以内，被查询征信的次数 |
| AMT_REQ_CREDIT_BUREAU_QRT | 申请人发起申请前一个季度以内，被查询征信的次数 |
| AMT_REQ_CREDIT_BUREAU_YEAR | 申请人发起申请前一年以内，被查询征信的次数 |
从表中就可以大致猜测出一些信息，例如：OCCUPATION_TYPE，NAME_INCOME_TYPE以及ORGANIZATION_TYPE应该有很强的线性相关性；DAYS_LAST_PHONE_CHANGE，HOUR_APPR_PROCESS_START等信息可能不是重要的特征；可以在后面的特征分析时加以验证并采取特定的降维手段