在Morningstar的架构里，data api起着越来越重要的作用，5年前开发的版本虽然非常稳定，但已经不能满足我们现在业务发展的需要，因此新的data api被设计为一个统一接口，也就是所有的产品都通过data api获得数据，只有data api与后端的数据库进行交互。

我所工作的领域全部是前端，因此对于我们而言，大部分情况下，都只需要通过ajax向data api发出请求，或者通过一个本地的代理，用node构建数据请求代理层，实现请求转发，实际上是data api的前端处理而已。

但是今天在接触的过程里面，我发现我们的data api还分为SqlMart和Natisa，一直搞不明白怎么data api还分。经过一番了解之后，原来这两个只是data api的两个服务，其中SqlMart负责获取轻量级的数据，直接向前端返回数据，而如果需要进行数据运算，则会将服务转向Natisa，通过Natisa运算后，将结果返回给前端。

不过由于历史的原因，这两个服务之间并不能很好的兼容，特别是一些datapoint，在名称上也不一样，这导致如果前端要从Natisa切换到SQLMart服务，不得不修改一些字段名称。

但如果我们忽略这个问题，从理想的状态来考虑，这样的设计有什么样的好处，应该怎么来运行呢？

查询与计算分离的好处

一般大型的公司后面都有海量的数据，而且由于业务涉及面广，数据格式基本上都是杂乱的，虽然大数据系统已经被广泛运用，但是在data api这一层，仍然尚未做到这么智能，仍然需要开发者完成查询与计算两个其实可以完全分开的业务。

SQLMart和Natisa属于服务级别的应用，服务级别也就是service，负责不同的具体任务，对于只是查询而言，比如立即查询出当前某只股票的价格，或者上月结束某只基金的流出等等具体的数据（这些数据以非常明确的值保存在数据库中），则直接通过SQLMart进行查询取出。

但是对于一些需要统计后运算的数据，就需要有一个强大的计算服务来完成。举一个例子，我希望获得某只基金的回报率在过去十年在具体分类中的百分位排名，并且按季度返回最近一期之前的所有数据，那么这个具体场景中就需要进行计算。需要查询出过去十年每一年的回报率以及当年的每月回报率，然后再进行时间区间内的累加，得到一个total值，再在这个时间区间内进行降序排序，再进行百分位排名运算，最后将这个结果返回。由于这个过程里面可能涉及几万条甚至几十万条数据，而且由于这个需求并不固定，比如时间区间、步幅等等都可以让用户自己选择，而且当前数据还在变化，所以根本没法缓存一个数据下来（一些历史确定数据可以变相缓存），只能即时进行运算，这时就需要Natisa进行运算。

可以想象，这两个service肯定由不同的服务器来完成，这样就算其中一个挂掉或出现bug，也不会影响另外一个服务。
无论是在性能上，还是在业务专注度上，这种区分都对整体的维护有好处。

架构的想象空间

前端请求数据时，可以事先作出预判，决定采用哪一个服务来返回数据。有些可以更快获得的数据，可以提前加载出来，从而更快渲染界面，而需要长时间运算的数据，就放到后面再渲染。

而对于服务端而言，也有了自己的一些空间，如果把所有的运算都放在Natisa，那么整个公司那么多产品都从Natisa去运算，再牛逼的服务器，也可能承受不住压力而宕机，对于每个产品自己的server，可以根据自己的情况，从SQLMart获取细粒度很小的数据后进行小型的运算，返回给前端，这样不走Natisa，可能也能给前端速度带来一些优化。

而对于SQLMart而言，由于它的任务非常轻量，所以甚至可以起到代理的作用，当来自前端的请求的数据并不能直接从SQLMart得到时，它甚至可以将请求转发给Natisa，这样相当于做了一个Mapping，对于前端而言，完全无需区分到底是哪一个服务在为自己提供数据，甚至真的可以把data api当做黑箱，请求数据，拿到数据。

在Morningstar，虽然工作的都是前端的内容，但是由于公司是以数据为支撑的技术架构，所以在整体的技术框架上，还是比较保守一些，使用的技术都是需要等到它在市场上表现的非常稳定之后才敢用，这无疑阻碍了我们快速学习和掌握新技术的实践途径。但是，也正因为这样，Morningstar的架构非常成熟，在数据端的沉淀也很有深入学习的空间，一旦掌握了，我相信在任何一家以数据见长的公司，都可以非常容易上手。

2016-10-24 4359