这篇文章主要描述的是Prismatic公司系统架构，作者是Todd Hoff，本文出自Todd对Prismatic的程序员Jason Wolfe的邮件专访。
关于Prismatic，首先有几个事情要说明下。他们的创业队伍很小，仅仅由4个计算机科学家构成，其中的三个都是年轻有为的斯坦福以及伯克利博士。他们是在用智慧解决信息超载这个问题，然而这些博士也同时担任着程序员的角色：开发网站、iOS程序、大数据以及机器学习需要的后台程序。Prismatic系统架构的亮点是如和使用机器学习实时地解决社交媒体流的处理问题。由于商业机密的原因，他没有透露他们的机器学习技术，但是我们可以通过架构看个大概。Prismatic创始人之一Bradford Cross把Prismatic的系统简洁地描述为：“它是一个提供大规模、实时以及动态的个性化信息排名、分类以及分组功能的综合系统。”接下来就把这个系统的架构展现给大家。
Prismatic主要功能是发现我们的兴趣，为我们推荐阅读
今天你应该读点什么呢？任何一个现代人每天都会陷入这个困境，大家通常使用一些很隐秘的途径去找到自己想要读的东西：Twitter、RSS、Facebook、Pinterest、G+、email以及Techmeme等这些信息源。Prismatic回答了“今天我应该读什么？”的问题，Jason Wolfe慷慨的同意并且详细地描述下他们正在使用的解决方案，言语中包含了许多时髦的技术名词，例如机器学习，社交图谱，大数据，过程化编程以及事实需求等等。然而结果是他们的方法更隐秘，但和其他一些相似应用不一样的地方在于他们会发掘你的兴趣，无论这些兴趣在你的信息中藏得有多深。
正如大家预料的，他们的做法有点特别。他们选了Clojure做为开发语言，它是一个编译成Java bytecode的现代Lisp语言。主要目的是充分利用过程化语言去构建具有丰富粒度，结构自由的程序，从而满足各种问题带来的特殊需求。列举两个他们用到的过程化语言的优点的例子：第一个是他们几乎每个地方都使用图库。对于每个用户来说，他们的图形计算可以被称为低延迟，流程化的map-reduce任务集；另外一个例子是他们使用子图实现了模块化的服务配置。
他们把系统设计的焦点放在过程化开发上来，避免了使用像Hadoop那样的巨型框架，转去使用小型的，这使得系统更可靠，更容易纠错，更容易扩展以及更容易理解。Prismatic的机器学习做法的难点在于要求一个非常长的训练周期。需要指出的是：首先，获得优质分析源内容并不需要多少时间；其次，使用基于机器学习的推荐系统需要对用户从幼儿到现在的一生的所有数据进行训练；这个可扩展的思维数字模拟系统扮演着信息的收集者以及生产者双重的角色。
图：越来越多的应用开始关注用户的阅读推荐
统计数据
- 现在每天有几千万篇文章、博客以及其他一些内容通过Twitter，Facebook，Google Reader以及互联网发布。
- 但是仅仅需要用户登录时的那几秒钟，Prismatic就能够使用他们之前的阅读历史进而去分析用户的兴趣，然后推荐阅读，使用用户在社交网络上的活动，从而将联系人发表的、符合用户胃口的文章推荐过来。同时，Prismatic也会记录用户在它本身上的动作，也将它做为分析的一个来源。
- Prismatic只需要数十秒钟去访问用户的个人主页，通过和用户兴趣模型对比，便可以分析出用户最感兴趣的东西。
- 现在每周有数百万的优秀文章通过Prismatic成功分享给用户。
平台
- Prismatic的主机托管在AWS的EC2上，使用Linux操作系统。
- Prismatic99.9%的后台通道和API服务都用Clojure开发。
- Prismatic所有的重量级框架部署在JVM中。
- Prismatic使用MongoDB存储服务器参数和用户分析数据。
- Prismatic使用了MySQL。
- Prismatic使用了S3。
- Prismatic使用了Dynamo。
- Prismatic将重点放在开发能解决特殊问题产生的需求的代码上。
数据存储和输入输出
- 和典型的结构不同，Prismatic的服务都围绕着数据而设计，可以提供实时读写数据的能力。
- 大部分数据都直接在后端管道之间传输，不会和磁盘发生I/O。
- Prismatic把数据保持在离CPU尽可能近的地方，这样就让API的请求几乎没有IO延迟，同时把API绑定到CPU上，巧妙的扩展了系统的规模。
- Prismatic使用了许多现成的解决方案：MongoDB，MySQL以及Amazon的S3和Dynamo。每个都是经过对实际需求仔细研究的，包括规模，接入模式和数据存储相关的其他特性。
服务
从外部来看，Prismatic的系统被分成了10个独立的服务模块，大致可以归总为5种类型：数据采集；新用户管理；API；其他客户机服务；批处理。每个服务都是为一个功能而设计，通过一种特殊的方式进行横向扩展，通常受1到2个特殊资源限制（IO，CPU，RAM）。
- 数据采集——后台
每天都会有大量内容（包括文章，博客和网页等）产生，Prismatic想要尽可能多的捕捉到他们。为了让用户可以评论每个内容，并和自己兴趣相投的朋友进行分享，Prismatic必须识别每个内容的作者，分享者以及一些比较有价值的评论。做这些的第一步就是收集和分析内容和关系数据。
首先在采集通道入口执行下面这些步骤：通过喜好在RSS上找到新文章；通过API将用户Twitter和Facebook上的最新评论和动态收集上来。执行这些功能的服务非常简单，而且没有状态信息，唯一的状态和有意思的地方是如何确定哪些信息是已经收集过的了和怎样智能的分析接下来该收集哪个信息。其中最难的就是前者，因为有些人他可能在多个地方发过同一个信息。
接着，把RSS、Twitter以及Facebook等信息源收集上来的资料送入到一个过滤器中，让它决定哪些需要进入通道进行分析。首先把垃圾邮件和其他垃圾信息丢掉，URL将被送到管道中去，此时会有很多有趣的事情发生，Prismatic会建立一个URL队列，将每个队列送入一个图运算中，使用它将URL进行详细描述，抓取它的HTML代码，使用机器学习的算法把文章的内容抓取出来，识别最好的图片，抓取出作者，标签以及话题等等。为了让这些过程尽可能快速进行，能够装入内存以及提高表现力，他们投入了很大一部分时间，当然，处理这些URL的方式是高度并发的。
最后是文档控制器，它的作用是接收上面处理好的详细的文章和社交内容，将他们进行匹配，把文章集整理成故事系列，决定把哪些设为当前要处理的文档，并且管理这些API相关的机器目录。
- 新用户管理——后台
新用户管理模块主要负责收集新注册的用户的信息。它主要由两个部分构成：通过用户的Twitter，Facebook以及GoogleReader找出他喜欢的主题以及喜欢的文章来源；分析他的社交图谱，找出他最喜欢哪些朋友分享的文章。
执行这些功能的服务也是高度并行的。社交图谱分析非常复杂，关键是这些服务如何能够实现如此低的延迟以及如此可靠的吞吐量：对于Twitter，Facebook和Google Reader的活跃用户来说，准确找出数百个用户喜欢的话题对于Prismatic来说只需要15秒，甚至更少。用户授权以后，Prismatic就可以非常快地分析出用户的兴趣，用户常常在注册的时候（填写密码和点击确认的过程中）这个工作就已经完成了。看看在这15秒内，发生了什么：Prismatic把用户最近在Twitter和Facebook上发表的内容以及Google Reader中标记为喜欢的东西都抓取进来，这一般是10秒钟左右；然后把用户和他的联系人等共享的1000个URL收集上来；再将这些数据送入上面提到的文档控制器，使用相同机器学习堆栈进行采集/分析的通道；这些分析结果经过聚合，后期处理，最终都存储到DynamoDB和S3里去。
这个过程对延迟的要求非常严格，所以这些进程不能串行，必须并发执行，所以他们不得不尽可能多地使用通道和并行处理的技术。这个过程对吞吐能力要求和很高，因为每个进程并不小，同时一旦有许多用户同时来注册，要想降低延迟你就必须做更多的事情。这里也是Prismatic的独到之处，他们的流处理和聚合类都将重量级降了下来，把性能做到了极致，达到了每个用户使用一个低延迟map-reduce任务的效果。对于多个用户的情况，他们系统使用的并发处理几乎发挥了机器的全部性能。
API——面向客户机
数据采集和新用户管理都部署在API机器上。系统主要的设计目标和挑战是：最近的文章必须被编入索引并且可以满足低延迟的需求，索引并不算小（常常是许多GB），而且必须实时更新，只有这样才能把最近更新的文章传递给用户，这些需要为用户设计跨机器的负载均衡，同时要求必须能快速简单地将任务划分到新机器（当然还有关闭合并）；如果要想找到用户的真正需求，仅仅使用索引是不够的，同时还需要用户的“指纹”（他们的爱好，社交关系，最近读过的文章等），这些指纹数据非常大而且在不断发生变化。
对于前几个问题需要用到文档控制器（上面提到了）。文档控制器组织当前的文档集，对他们进行预处理，每隔几分钟就把刚刚做好的的索引集存储S3中去。当一个新的API机器启动时，文档控制器首先读取这些文件，将他们放入内存，再将最新的索引副本传递给它。文档控制器也负责将所有索引的改动（新增文档/新增评论/删除等）实时地传递给所有正在运行的API机器上去。其他一些API机器常用的功能也由文档控制器从S3中读入内存，周期性的更新到S3，如果数据超过了S3的存储大小限制，就将它存入DynamoDB。
剩下的问题就是如何在保证延迟需求前提下，提取和更新每个请求里的用户“指纹”。Prismatic这里使用的方法是使用粘性会话（Session），把用户绑定到一台API机器上。当用户第一次登录的时候，就把他的信息存入一个具有有效期的回写式缓存中。在用户会话的生命期周期内，把其中的数据放入内存进行兴趣分析。在这个过程中用户进行的所有操作都会通过同一个API机器进行处理，对于那很小的一部分不关键的用户指纹，每隔几分钟，会话到期或者关闭时再