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

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 过后，有什么给个理财忠告给大家吗？

王宏江：买个宝压压惊。