参与到日常数据开发分析的任务中
前期负责数据探索,数据调研,并负责输出相关数据说明文档。
形成具体需求之后,和PM讨论具体数据需求,输出UAT数据展示给各需求方
构建每日任务,运行具体的业务代码,核验数据,并输出到下游使用方
构建每日任务健康监控,包括数据质量,数据完整性以及任务的实效
参与构建特征存储模块
按照DataScientist部门的需求,从各种不同的业务表中抽取,计算出不同维度的特征并将这些特征保存在数
据库中,ds team的同事按照具体需求从feature store中抽取所需的feature进行模型的构建。目前参与到的
模型包括complaint predict 和non-transcript model.两个模型都是用来对相关的沟通来进行complaint
predict, 从而让人工更早的介入,防止complaint的发生
参与开发了项目内部的spark统一化执行平台
部门内部开发了了一套简化spark使用的工具,通过简单的yaml格式的配置文件,就可以实现各种外部数据源
的读取(包括oracle,bigquery, hive, teradata等),以及输出到各种不同的平台(teradata, hive,bigquery等)。开发人员只需要熟练掌握sql开发的流程就可以完整的开发出在spark上运行的job,大大简化了开发流
程。
涉及到的技术:
spark, hive, bigquery, sql,scala等

指标,用户画像和标签系统
需求:跨境收款的各个部门都需要不同的数据指标,但是这些指标因为没有一个统一的口径,导致不同的业
务部门有不同的理解,导致对于同一个指标,经常出现结果对应不上的问题。这个时候就需要开发一套指标
系统,统一指标口径,同时,基于指标系统,开发标签和用户画像系统。
难点:
业务流程涉及部门较多
各种业务指标繁多
方案:
针对各种业务过程建模,按照不同的数据纬度,不同的业务场景统一数据指标
和bi部门统一定义指标口径
针对不同的维度的指标,将指标结果保存到不同的指标宽表中。数据指标的定时任务是基于spark来实
现的,结果保存到hive中,再同步到phoenix中
基于指标宽表,构建需要的标签(比如30天未入账)
基于标签和指标,构建用户画像系统。针对不同的标签,圈出不同的用户群体,针对该用户群体进行统
一推送。
用户画像和标签系统需要先做标签和用户画像的定义,根据指标宽表,hive中的其他维表和dwd层数据
表查询出符合标签的用户(或虚拟卡)。将打标的结果和用户画像的结果保存在elasticsearch中,提供
给后端服务。
涉及到的技术:
spark,flink,azkaban,hive,elasticsearch,Phoenix等
springboot,mysql,redis等服务端技术
入账系统额度控制和核销系统
需求:应外管局到要求,所有境外收入来源都要有对应的交易记录。同时连连跨境收款业务还包含境外的跨
境收款,因此,对于其他的外汇管制国家,也需要提供提现单的核销方案。连连跨境收款业务部门在对接各
种电商平台的时候,会拉取该用户在该平台的历史交易订单,当有资金通过连连支付的收款系统进入到连连
的虚拟资金账户的时候,需要首先统计用户的订单金额能否满足入账的金额;同时,在连连的用户进行金额
提取的时候,每一笔提现单,都需要对应到具体的订单,需要将订单关联到提现单上。
难点:
订单数据量大
不同平台订单数据格式差别很大
不同平台订单拉取质量不一致
核销需要根据提现单的金额凑超过该金额的订单,而且不能重复使用订单,在分布式计算环境下逻辑比
较麻烦
方案:针对不同的核销场景,做了不同的核销和额度控制的方案。
对于入账额度控制,目前采用的是预先生成订单额度包的方案。首先将数据按modify_time从phoenix
同步到hive中,针对不同的平台,按小时,用户id生成唯一的额度包,将额度包的计算结果从hive同步
到mysql中,再通过定时任务,加到该用户的额度账号上,显示该用户目前可入账金额。
核销系统目前根据不同的平台有不同的处理方案:
实时性要求高:对于实时性要求较高的场景下,提现单核销采用了和额度控制类似的额度包的方
案。预先计算好额度包,在进行额度核销的时候,通过拆包的方式满足提现单金额的要求。这里的
额度包里面的所有订单需要保证序列号是连续的,这样才能保证所有的订单都能被核销掉,才能尽
可能满足提现单的金额
实时性要求不高:对于实时性要求不高的场景小,核销采用定时任务的方式实现。这里用spark实
现的定时任务,每天查询出前一天处理完成的提现单,再根据拉取到的订单,从订单中选出一部分
订单,直到满足提现单的金额,将数据保存到hive中,然后同步到mysql中。
效果:
实时核销在分钟级别可以核销完某境外外管局要求的一批提现单
批量核销每天定时任务在半小时左右可以核销完所有的订单
涉及到的技术:
spark,azkaban,hive等大数据相关的数据任务
Springboot,mybatis,mysql,redis等服务端技术

特征服务器
功能: 用来存储和处理特征的服务,对外提供rpc和restful两种方式调用
难点:
数据量大,保存几亿用户的用户特征,上百万文章的文章特征
请求量大,每天定时任务有上亿用户的特征更新;实时推送请求每半小时调用量达到上亿
对接其他语言客户端,字段和数据存储的兼容性问题
方案:
数据存储使用cassandra集群,固定数据字段格式和数据类型
使用grpc提供rpc服务,grpc基于http2.0的流式调用提供了性能保障,同时grpc提供了多语言的支持
使用nginx做负载均衡,达到负载和容灾的目的
效果:
定时任务spark 客户端通过grpc调用测试,更新上亿条数据,耗时在一个小时左右,处理速度估算达到
上万tps
实时推送查询请求延迟在10ms以内
涉及到的技术:
Spark, Java, grpc
实时推送服务
功能: 筛选资讯,针对不同的用户,实时推送消息到用户app端
难点:
协调集群资源短时间内触达上亿用户
各种模型的整合使用
资讯新闻的排序召回策略
千人千面的推送
方案:
加载活跃用户数,用户画像,文章画像,加载算法团队提供的算法,针对不同的用户喜好, 进行打分排
序,然后通过kfaka将推送发送到storm平台
storm平台只做简单的数据处理,调用推送部门的推送接口,将消息推送到用户app
数据排序模型使用FM和GBDT模型
召回方式使用倒排序索引,根据用户的偏好,召回相应类型的文章
效果:
每半小时或一小时推送一次,每次任务运行20到30分钟,下发数据量达到亿级
缺点:
服务外部依赖文件过多,内部代码过于冗余复杂
模型调整需要同步修改的代码部分较多,代码抽象不够,代码维护成本过高
集群资源占用量大,有一定的资源优化空间
推送相关结果的数据处理
搜集打点数据,构建etl,统计相关推送结果数据
涉及到的技术: Spark,hive,sql, azkaban等

猛犸反欺诈平台-风控平台
猛犸反欺诈平台通过引入规则系统,为使用者提供了灵活配置、执行与评估反欺诈规则的能力。通过规则平台的引
入,可以更好的将底层技术平台的检测、计算结果(比如设备指纹ID、设备相似度、欺诈特征等)应用到反欺诈场
景中。
客户通过在用户界面进行场景,策略,规则集和规则的配置。完成配置之后,用户通过sdk和s2s api 上报上来的数
据会被作为规则变量使用,根据配置中的规则,生成这条消息的执行结果,正常、欺诈、疑似欺诈。
平台架构上,页面端负责配置具体的规则,所有的配置由配置下发模块完成,具体实现用到了zookeeper和
mongodb。具体的配置被保存在Mongo中,配置的当前版本信息被保存在zookeeper中。当配置完成下发之后,
zookeeper中的相应节点中的配置版本信息发生变化。所有依赖规则配置的系统会监控该节点的状态,及时从
mongo中更新具体的配置到缓存中。规则平台会根据配置的规则进行规则的执行,当需要进行特征调用的时候,
会调用特征引擎模块,进行特征的解析。最后将整个策略执行的结果保存在elasticsearch中,提供api查询方式供
用户调用,同时,在页面上统计各规则的执行命中情况。整个平台中的服务分为流服务和微服务,流服务需要从
kafka中拉取数据,处理完之后,发送到下游的topic中。微服务同时也可以是流服务,但是微服务同时还需要向外
提供一系列restful的接口,供平台中的其他服务调用。
猛犸反欺诈平台-设备指纹项目
猛犸反欺诈设备指纹系统是通过大数据机器学习技术,综合设备的协议栈、OS、浏览器以及硬件特征,为每一台
物理设备生成不依赖于设备本地ID的设备指纹ID。客户嵌入我们提供的sdk,发送事件到我们的系统中,前台
nginx做负载均衡,分流数据到数据收集器,数据收集器收集好数据之后发送到kafka对应的topic,下游处理系统
根据搜集的数据进行解析(例如user-agent,ip 等的解析),解析完成之后,获取每个特征的权重,然后获取一个总
分,根据这个总分去缓存系统中查找最接近的一个,如果与最接近的一个maxentid直接的分差大于阈值,生成新
的maxentid,并进行缓存。id生产好之后,整个数据结构保存到mongodb中,提供restful api供客户查询。

复新保人寿微信服务项目
复新保人寿微信服务项目主要是在移动微信端给用户快捷便利的投保服务,提升复保的知名度和业绩。复保的微信
项目主要实现功能: 1.微活动(男神险投保,女神险投保,票选身边的男神,票选身边的女神,每周一券等) 2.
微服务(身份证绑定,保单查询,相关险种查询,在线投保支付等) 3.微社区(建议专区,积分商城等) 4.后台
管理(用户管理,公众账号管理,合作外部渠道管理等) 开发流程: 1.前端开发人员写好适应移动微信端的页面
2.请求发送到后台,分配到相应的action 3.action中调用service实现业务逻辑 4.dao层使用mybatis对数据库进行
操作 责任描述: 负责微活动中大部分代码的编写,需求的增加,调整,测试,以及bug修改。