挖财架构师:不能从会计角度设计记账 App

阅读数:2914 2015 年 11 月 16 日

2015 年是互联网金融蓬勃发展的一年,微众银行、网商银行... 资本市场融入了更多互联网的元素,互联网金融的模式也日益多元化,其背后蕴藏的风险也越来越为引发大家的主意和深度的思考。为此我们采访了挖财技术部资深架构师王宏江,本文根据采访整理而成。

受访嘉宾:

王宏江,现任挖财技术部资深架构师。Tomcat 方面的专家,善于诊断问题以及性能调优。有丰富的企业架构和大型互联网技术架构经验。同时也是函数式编程爱好者,和 Scala 布道者。在ArchSummit 北京 2015全球架构师峰会上,王宏江将作为专题讲师为大家带来《Scala 在挖财的应用实践》

第一部分:挖财的产品设计,历史技术状况,以及架构的演化,技术体系的现状。尤其在面对人员和业务快速扩张过程,为何做出这样的选择;

第二部分:介绍其中两款用户量较大的工具性产品 (挖财记账和挖财钱管家) 的数据特性,我们是怎么解决数据存储过程中遇到的问题的。涉及数据库方面的架构选择;

第三部分:着重介绍 kafka 与 akka 等 scala 生态工具在处理这些问题中的使用经验。akka 如何与现有主流体系结合,以及一些常用使用模式。听众受益:记账类产品的数据特性和解决方案;scala 在快速发展中的初创公司中的使用经验;kafka,akka 的一些经验。

精彩内容敬请期待,以下是 InfoQ 记者对挖财架构师的专访:

InfoQ:生活在类似的商业社会中,不同用户的数据结构差异大吗?能举例说明一下吗?

王宏江:如果只是指手动记账部分的数据结构,相对固定。不过挖财除了最早的记账工具之外,还有理财、贷款、行用卡管家等产品,特别一提的是还有一款定位为资产管家的“钱管家”产品,希望能为用户提供更全面的资产数据管理。那么就会涵盖到用户的多种行为,这些行为的数据构成差异很大,比如消费类 / 投资类 / 资产类的,数据构成相似性很低。

资产有多种形式,如银行的活期 / 定期, 各种账户余额 (股票账户 / 预存消费的会员卡), 基金, 股票等。同样投资形式也具有多样性,比如投资实际是以增值为目的的资产活动的流水记录,理财、股票、基金等 这些数据的流水属性相差很大。

InfoQ:记账类应用的数据库设计难点在哪里?

王宏江:仅是记账应用的话,经过多年的摸索业务相对稳定,最主要的就是保持领域模型的稳定,数据存储模型以及视图层与领域模型的适配不要太复杂,在数据库层面解决好数据的水平扩展就可以了。

挖财力求对用户的资产活动做全方位的记录,不仅仅是手工记账,正如在第一个问题里提到的它们的数据结构差异很大,在设计领域模型以及数据表时需要做大量的归纳总结,尽量归并相似的数据, 控制 table 的量,也便于后期的个人资产汇总。

另外流水数据中,也存在相对稳定的结构,和可能变化的结构。比如两笔流水之间可能是转账或某种关系 (程序通过比较两笔数据之间的一些相似属性来判断),这个关系记录相对来说就是一个易变的部分,因为新数据进来都要与老数据匹配运算,可能会更新关系。设计时要尽量避免易变数据的更新对稳定数据的影响。

InfoQ:对于在记账方面有消费类型分类恐惧症的用户来说,简单的表设计能否提升用户体验?

王宏江:分类的确是一个头痛的话题,消费类别分类一定要合理,要让用户可以快速定位到消费类别, 快速记录,否则用户在记账时纠结于消费类型, 那肯定会流失用户的。

我们尝试过手动加自动分类的方式。但自动分类功能并不那么简单,需要结合大数据和机器学习才能较好的解决,比如说"Uber"刚出来的时候,算法识别不出它的分类,只能归到“其它”,后来运营才手动把这个关键字设置为了“交通出行”这个分类;还有比如关键字里出现“桔子酒店”,分类算法不好的话,可能把它放到了“水果”或“零食”下面,而不是“出差”或"住宿"。自动分类这块我们还在摸索,做好并不容易。

对于消费数据,关注的层次不同势必影响结构的设计, 需要做取舍决断。例如我在超市购物十件物品共花费 500 元,有以下两种设计:第一种是只关整体什么时间花费多少钱。 那这个结构很简单,只需要包含这些属性: 时间,金额,地点... 其优点是记账简单,但是对于后续的大数据挖掘没有用,因为缺少必要的数据特征;第二种需要知道买了哪些东西,什么价格。 这样的结构要复杂一些: 物品名称,价格, 数量,金额,时间, 地点 …其优点是所有数据特征都在,后续方便大数据挖掘, 甚至可以在大数据基础给出某类商品的价格参考。但是记账大麻烦, 用户不愿意使用。综上,最终的设计进行了折中,记账的主动权在于用户。

提升用户的记账速度对于维持用户的记账习惯和留住用户很关键, 还可以通过其它手段提升记账效率:如不同的账本, 情景记账, 记账模板等等。

InfoQ:智能手机和手机支付的发展对记账类 App 的影响是什么呢?

王宏江:智能手机对记账用户的习惯有非常大的影响,我们现在同时提供了 PC-web 端和 App,两者的使用量完全不是一个级别。早期 PC 时代的记账网站:账本、盐糖记、帐族等等在移动互联网普及之后没有迅速转型都已经没落,因为大多用户对记账这个事情没那么严肃,想起来就记一下,智能手机正好满足。手机支付的普及对记账也有促进,现在记账类 App 都提供了一些第三方导入接口,将这些系统的记录自动导入过来。

InfoQ:我曾经也用过记账,却因为 App 崩溃重装导致数据丢失,现在云计算发展是否对记账数据的容灾能力有十分的保障?

王宏江:记账 App 端也存在“轻"和“重”,有时候 App 端为了用户体验,减少与服务器端的交互次数和数据流量的开销,很多数据缓存在本地,如果没即时同步可能存在这种风险。不过长远来看,随着 4G 的全面普及,以及流量不再成为大家特别较真儿的事情,很多的 App 会变的更“轻盈”。

InfoQ:我使用挖财时发现它要求提供信用卡的密码,淘宝密码,储蓄卡密码,你怎么保障帐号安全?怎么让用户信任你们?

王宏江:这个问题确实有些敏感,网上也有过一些讨论。我先吐露一下,实际中这部分用户的数量并不少,这也反映出它是很多用户的真实需求。

自动记账是一个趋势,未来一切交易行为都将电子化,怎么把散落再各个平台的数据管理起来并利用好,是个非常有挑战的事情。

现阶段帮助用户管理数据的一个前提是需要用户的授权,另外这里有个误区,大多平台 (尤其银行) 是区分查询密码和交易密码的,这里需要授权的是查询密码而非交易密码。

对用户查询密码的管理,我们当作最高级别的问题对待,采用最严格的加密算法,并且数据是存放在隔离区域的,整个公司都没几个人有权限访问。在使用时整个传输层也全都是加密的。

当然,即使如此仍不放心的话,在自动记账时可以选择不让挖财记录你的查询密码,而是触发数据同步的时候用户自己手动输入密码,只是这样体验不太好。

InfoQ:会要求开发人员学习一些会计知识来提升数据库设计的实用性吗?

王宏江:不要求,懂会计知识会更好,但是在设计时不能从这个角度出发,容易设计成专业系统,因为我们的目标是广大的小白用户,过于专业这些用户反而不会使用了。

InfoQ:在双 11 过后,有什么给个理财忠告给大家吗?

王宏江:买个宝压压惊。