20170623-银联扫码、用户画像

Posted by PaymentGroup on June 23, 2017

一、 银联扫码与聚合支付

Q:现在银联的二维码和微信支付宝能聚合在一起吗? A:可以

Q:可以聚合在一起是指通过聚合支付,用户主扫这种模式?

A1:好像银联的不能和支付宝微信的聚合

A2:

  • (提问者)根据我们沟通下来的结果看,目前银联二维码,用户主扫的都是根据订单信息动态生成的码,扫了之后要去银联这边查订单信息的
  • 但是是能做交易,就是麻烦一点
  • 第三方支付比如支付宝微信,挂在小店里的静态码一般都是只包含了商户信息,银联二维码规范里支持,但是银联好像自己没做,也没商户支持
  • 不过主扫风险也是存在的,估计银联是从风险考虑的结果吧

A3:银联针对小微商户,是有静态码的, 初始限额较低(好像是500),不过可以通过完善商户信息或者根据交易频次之类的,进行调额。但银联的静态码,目前了解下来,没办法像微信、支付宝那样,聚合到一起。 商家只能贴一个微信+支付宝+xxx钱包的聚合静态码,再贴一个 银联静态码。


Q:群里有人完成过 银联静态码的聚合嘛?我目前了解到的信息 是没法聚合,但也不晓得是不是有变通的方法

A1:不行的吧,除非扫码的app支持,但是这个要一个个app谈。静态码可以是网址,但是这个网址能不能访问,怎么处理是由扫码app说了算的

A2:我们分析下来,银联的静态码,是后台接口模式,跟微信、支付宝的 前台js sdk/js api 方式 不一样,即使勉强合成一个码,在支付过程和体验上 也有很大的问题…

A3:是的,银行的APP不支持其他公司的链接的,会有类似下图的提示

微信图片_20170623213502

A4:银联有三套二维码系统,目前很难聚合

二、用户画像数据处理方法

Q:群里有玩客户画像的朋友吗?

A:做过用户画像

Q:你们是用的哪种数据库?SQL的还是NOSQL的?

A:sql

Q:你说的用户画像 是先做用户标签 然后看群体 特征的吗?

A:用户画像,我理解主要是行为画像,就是把一个用户的行为分类

Q:那么多的维度数据,是如何组织的?通过标签过扩展?

A:对呀,信息中心就是一个个 行为分类。标签的加工 有的也会用一下挖掘模型,流失 提升 响应 细分,后来 还加了 一些社会网络分析 研究 交易关系 静态关系

Q:那就是相当于一个KV库了?

A:可以这么说,标签和kv 感觉有点不太一样,kv 是数值吧,便签是、高 、中、低或者01


Q:用SQL能放多少数据量?

A:teradata 一张表 放 几亿条 没什么压力的,但也不推荐用td。民生信息中心习惯用td 并没有什么特别的理由,维护确实有点麻烦

Q:大宽表得有多宽?

A1:200多个字段

A2:要多宽有多宽,互联网公司 画像类存储一般用 Hbase,不会用这种商业产品

A3:我在包商 也用了hadoop那套,感觉其实 并不好用

Q:在HBASE也是建一张宽表?

A:是的

Q:用了hadoop那套,不好用在哪里?

A1:Hadoop那一套的运维成本还是较高的 要有专门的人来运维集群。一般适合整个生态配合起来用 spark hbase impala这些。hbase一般不会直接对外输出的,hbase不适合直接提供线上服务 一般上层接一个缓存

A2:我用5台cdh做集群性能不行

Q:应用系统怎么用呢?是不是查询。业务系统查询向缓存查询即可hbase中数据用于进行离线的分析

A:这个是我规划架构,和你们说的也差不多

微信图片_20170623214800

  • 一部分 是查询 还有一部分 画像也是要作为 推荐系统的数据源 之一呀,差不多就是这个架构
  • 性能你可以通过后台导出到关系数据库中
  • 推荐系统service层也可以复用这个缓存 或者 另行缓存

Q:这是什么的架构?

A:分析系统。架构模式上,属于lambda架构

Q:没体现离线的部分,离线部分的历史数据通过什么进行上浮呢

A:不在这体现,有数据交换中心

Q:是OLAP分析吗

A:可以这么理解。

Q:但是跟用户画像好像没啥关系?

A:这个没有体现业务,有关系,涉及到如何画的问题一些确定的模型,表结构其实就是一定的

Q:我问个问题,为什么非要用一张宽表,而不用多张表?用多张表模型结构很清晰

A1:1.这是一个纯客户级的,2.不保留历史 3.标签的一般不会剧烈变化 4.标签 往往是挖掘模型的数据源 一张宽表 方便挖掘

A2:列式存储, 大宽表但是不影响性能 权限控制 标签可以独立进行更新管理,模型结构清晰 这是伪命题 你有一张表 就可能有 1w张表。

Q:以上后续如何进行维护,不保留历史 hbase可以保留历史

A:我是不太想 保留历史 空间老不够 申请扩容又不批 标签数据相对稳定 就不保留啦

Q:这个不应该是原始数据的任务吗?

A1:原始数据分散在 mysql file parquet 各种地方 , 这块首先要先管理起来 ETL 是第一步 然后是分析建模, 打标签, 存储到hbase。最后就是数据上浮到缓存 进行对外服务。简单说就是这三步,可以保留一个 只是hbase的数据结构可以让你多保留几个版本。但是一般也没人用…

A2:我的设计思路是这样的:原始数据基本上都是实时数据,所以全量到Hadoop(先不考虑如何存储),对外输出也是要求实时性高的,所以同时上送到实进计算层用Spark Streaming将结果存入到前端的存储库中(如Redis,mysql),批量计算模型则采用Hadoop中数据进行全量计算,将全量结果推入到前羰存储库中。

A3:我们是通过位的方式来保存标签,一个列能保持64个标签,每个列相当于一个组。通过多个列来支持更多标签。

Q:我想知道是所有属性都需要用标签吗?为什么不ECIF那样的思路?

A1:这样存储数据量比较小,但是运算量比较大。1000万个用户数据在MySQL上也是秒级就能搞定

Q:画像更侧重长期数据的累积 实时需求不大吧? 不同的人同一标签的权重不同

A1: 实时性的需求我就不说了,因为涉及到客户画像、用户行为画像

A2:使用位存储的方式,能够很好的支持各种标签的交集、并集、合集运算。

A3:标签 应该是比ecif的 复杂一点,偏向于营销策略 比如 经营户标签(周期性转入 转出),而且标签有比ecif 更有预测

Q:使用位存储的方式,能够很好的支持各种标签的交集、并集、合集运算。你说的是计算效率吗?

A:因为都是二进制的运算,在内存就能很快计算并且能够并行化。

Q:long型这段 一个这段只能表示64个 计算交集这些直接用数据库位运算吗?

A:使用java计算。我们当时数据量不太大,只有1000多万用户,使用单个mysql就搞定了,基于各种标签的操作基本取决于mysql的全表扫描的时间。优化一下,可以把常用的客户放在NoSQL数据库中。当时数据库方案已经能解决业务需要了,因此没有使用任何NoSQL。

Q:效率慢吧 虽然单个位很快 但是数据库要遍历每条记录 时间花在数据扫描上了 位存储并不能提升效率

A1:特定条件查询性能如何?因为涉及到模糊查询了

A2:也不一定慢,因此数据库内部存储占用的空间很小。其他的方式数据库占的存储明显大很多,查询数据库造成的数据库扫描会慢。这是一个平衡。

Q:或者倒转过来 以标签查用户 主要看场景 应用关注决定存储方式 不一定哪个好

A:对,要根据场景。没有银弹。还是要根据场景,进行相应的估算或者性能压测比较。


Q:能否分享一下用SQL库的理由,使用过程中有没有什么坑?我的一个感觉就是全用标签,数据关系比较乱,不容易管理 A:是民生信息中心 习惯用td 并没有 什么特别的理由。做成一个大宽表

三、其他

Q:用户积分兑换和用户等级权益设计,谁能给点思路,有点不解,谢谢!

A:参考国内最优秀的积分体系和等级体系 QQ会员


Q:咨询下各位,银联云闪付线上和线下收取的服务费价格是否一致?还是区别定价的? ==待回复==

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。