在选用开源软件之前还是要问问为什么的！！！

不论是“站在巨人肩上”，还是“不要重复造轮子”，都在不断的提醒我们要充分利用周遭的各种有利条件降低自己的成本，而降低下来的成本就是利润。对软件开发而言也是如此，如果可以充分的有效的利用现有的各种开源软件项目的确可以大大降低软件研发成本，提高软件成熟度，缩短软件投入市场的时间。然而开源项目是“双刃剑”，一方面引入开源项目可以节省一定的成本，但是这也就使得一个软件项目与另一个开源项目有了关联，甚至可能出现“开源软件项目的选取的优劣将直接影响了项目的成败”的情况。因此合理的评估一个开源软件项目就显得尤为重要了。

开源软件

本文希望提出几个可以用于评估开源软件项目的指标。

1、背景

虽然说“英雄不问出身”，但是一般来说一个由大型的专业化软件组织推进和维护的开源项目比一个不知名的小团队维护的项目要靠谱的多；

2、应用

应用是否广泛是评估开源项目的最重要的指标，因为“群组的眼睛是雪亮的”，一般情况下，大家都说好，都愿意使用的项目，品质一定不差。另外，应用在一个大型的软件公司要比应用在一个小型的软件项目中更有说服力；

3、活力

所谓“活性”主要看这个开源项目更新的频度和最近的一次更新的时间如何。因为对软件而言，“有问题是必然的”，因此对一个软件项目而言，持续的更新和维护是必不可少的。选用一个已经长期没有更新的项目是要承担相当风险的，因为一旦有问题，这个问题往往就只能自己硬着头皮解决；

4、社区

虽然“社区”可以被认为是活力的一个方面，但老土认为有必要单独拿出来作为一个独立评价因素。“众人拾柴火焰高”，一个活跃的社区相当于为你的项目团队增加了一批技术人员。这里需要特别说明的是，通过向开源社区贡献代码是提高个人技术影响力的重要手段。

5、规模

打一个不太恰当的比方就知道这点指的是什么，你的软件项目代码有500行，结果为了这个项目引入了一个10万行级别的开源项目。这本身就是一个笑话。当然还要考虑BUG是与软件规模成正比的，一个项目的规模越大，出问题的可能性就越大，排查这个问题的难度往往也会更大，解决难度和周期也更长。

6、文档

文档真的很重要。如果没有好的文档，想要从论坛中的一言两语中理解一个项目，想要通过阅读源代码理解一个项目，那是非常难，非常耗时间的。当然有文档，与有好的可用的文档还是有差异的。不过这里说的文档不一定是大布头的帮助文件，也可能是wiki或是其他形式。

7、获取

获取代码的便利程度当然很重要。如果是Python的开源项目，自然是希望加入PyPI支持"pip install"的方式安装；如果是Java的开源库，能从Maven中心库获得当然最好。当然github也是关键渠道！

下面转一篇文章，其中以在项目中引入MapReduce为例，探讨了在引入某个开源项目之前必要进行的“考察和分析”。其中提出了UNPHAT方法，老土觉得不错，可以与老土在上面提出的方法结合使用。老土提出的方法是从软件项目的角度的评估，而UNPHAT方法则是从技术适用性的角度的考量。

一拍脑袋就要用MapReduce？你以为你是Google啊！（http://www.sohu.com/a/166385713_308467）

---

MapReduce,Hadoop,Kafka……似乎每天都有新的名词出现，每天都会有看似很酷的新技术诞生。是否我们现在的系统框架已经过时了？是否应该效仿谷歌、亚马逊或者领英的技术和方式？

本文作者提出的UNPHAT方法非常实用，它教你如何在急着行动前，清醒的想一想，最适合自己的选择才是对的。

除了技术/系统框架的抉择，这个方法对解决生活中的任何问题都是不错的启发。

21世纪，每个人都多少有些谷歌狂热症，似乎按照谷歌的方式做事，我就能得到谷歌的财富。比如，作为一名软件工程师，我是否该效仿谷歌建立MapReduce框架？是否应该像领英一样用Kafka来搭建系统？

伯克利计算机学院教授Joe Hellerstein会在每次课上会告诫他的本科生：“你不是谷歌，你经营的可不是全球最大的互联网数据服务。”

有兴趣可参考视频：https://archive.org/details/ucberkeley_webcast_NSKvCVFmk2E

事实上，这个世界上目前只有5家公司在运行着足够巨大需要MapReduce框架的程序。而对于其他公司，只是在 I/O(输入输出)上做了很多不必须的防错工作。

你们的数据中心大楼有多少层？谷歌的有4层，上图就是他们位于俄克拉荷马州梅斯县的数据中心。

谷歌的数据中心

这当然也涉及了更多不必要的费用的产生：一方面你需要做更多的I/O，另一方面你需要从一个使用了很久、相对成熟的系统转移到一个你并不熟悉的系统。这其实是一种大的退步。有多少Hadoop的用户清醒地权衡过这些得失？又有多少用户能对此做出明智的决定？

如果你正在使用的技术来源于一家大公司，但是你的业务情景完全不同，你将很难从容地用他们的技术来实现同样的效果。

恩，是的，这是另一篇“不要盲目崇拜新技术”的文章。

尝试新技术前，先试试UNPHAT法则

软件工程师有时会为些荒诞不羁的事情而疯狂。当需要选择实用哪一种技术时，我们会从社交网络里中某人的评论，跳到另一个人的博客，不断的摇摆不定下不了决心，最终陷入到一种疯狂的状态。迷茫中，我们总是朝着那些好像最耀眼的光芒漂游着，却忘记了我们真正寻找的是什么。

下一次，当你发现自己在网上了搜索 某些很酷的技术去（重新）搭建架构时，请先用这个UNPHAT 法则对这个新技术进行审视：

Understand (理解）：在你理解问题之前，不要开始思考解决方案。应该从问题入手，而不是从答案入手。在问题的领域思考如何结局，而不是在“解决方案的领域”里选择解决办法。

Numerate(列举）：请列举出多个候选方案，而不是直接选择你喜欢的那个。

Paper (论文）：选定一个候选方案。如果你找到一篇候选方案的论文的话，请阅读它。

Historical Context (历史背景）：在设计和开发候选方案时，请考虑相关方法的历史背景。

Advantage （优势）：权衡利弊。决定使用什么样的优先级来排序所列出的利弊。

Think! (思考！)： 冷静而谦逊地思考这个解决方案与你的问题的匹配状况。考虑出现什么样的情况，你会改变自己的想法？例如，数据集小到什么程度，你会决定放弃使用Hadoop？

你不是亚马逊

下面是一个很简单的使用UNPHAT方法的例子。我最近和某家公司就是否使用Cassandra对夜间产生的大批量工作流数据进行读取的问题展开了讨论。

我读过Dynamo的论文，而且我知道Cassandra是一个Dynamo的衍生物，所以我清楚地了解这些分布式数据库将读写可用性放在第一位（亚马逊希望所有的“添加到购物车”行为永远不会失败）。我也知道他们是通过部分降低数据库的一致性来提高它的读写可用性，这会对传统关系型数据管理系统中的几乎所有特性都会产生一定影响。但是与我交谈的这家公司并不需要将读写可用性放在第一位，因为他们的传输模式是一天进行一次大批量的读写。

亚马逊出售大批量商品。如果“添加到购物车”功能偶尔发生故障，他们可能会损失很多收益，但是你的使用场景也是这样吗？

这家公司之所以想要使用Cassandra是因为PostgreSQL在读取文件时需要好几分钟的时间，他们认为这是一个硬件限制问题。在问了几个问题后，我们确定了如果需要从固态硬盘中读取一个5000万行、80字节宽的表格的完整的文件，大概需要5秒。虽然这个速度比较慢，但是仍比实际查询快了2个数量级。

此时，我需要再多问一些问题（来理解他们的问题），并衡量为防止问题变得严重的5个策略（列出多个候选方案！），但是我已经很清楚地知道使用Cassandra是一个完全错误的解决方案。他们需要去做的是耐心调试原有的结构，或者重新搭建一些数据结构，或者选择其他的技术方案（应该不需要）……但肯定不是亚马逊为购物车所搭建的高读写可用性的关键值存储方案！

你不是领英

我很惊奇地发现有个学生的公司选择使用Kafka来搭建他们的系统。而他们的业务流程只有每天几十条高价值交易，如果生意好的话，可能一百多条。对于这个吞吐量而言，一个人手工去进行记录就可以完成数据库存储了。

相对而言，Kafka是为了处理领英上所有的待分析的事件而设计的：这是一个很巨大的数字。即使是几年前，这个数字可以达到每天处理万亿事件，在高峰时期可以超过每秒一千万的信息量。我同意Kafka对于低吞吐量的工作负荷同样有效，但是相比之下，低了十个数量级的数据真的需要Kafka吗？

太阳虽然很大，但也只是比地球大六个数量级

或许工程师们根据预期需要和对Kafka理论基础的充分理解，“确实”做了一个经过考量的决定。但我估计他们是被一些社交网站（通常是合理的评论）中对Kafka的热情所洗脑，而几乎没有考虑它是否适合这个问题。毕竟……这个是差了十个数量级的情况。

回到亚马逊

比亚马逊分布式数据存储架构更受欢迎的是能支持他们规模化的面向服务的体系结构：service-oriented architecture（SOA）。Werner Vogels在2006年对Jim Gray的采访中提到，在2001年亚马逊意识到他们扩展前端受到限制，从而设计了一个面向服务的架构最终解决了这个问题。这种想法在工程师中产生了巨大影响，甚至只有几个工程师和很少的用户的创业公司都开始将他们的APP分解为一系列的迷你服务了。

但是当亚马逊决定迁移到SOA的时候，他们已有大概7800名雇员，而且销售额超过了三十亿美金。

旧金山的比尔·格雷厄姆礼堂可以容纳7000人

而亚马逊决定转向到面向服务的框架（SOA）的时候，它的雇员大约有7800人。

我并不是说当你有7800名雇员的时候你才可以转向SOA。只是希望你可以思考，SOA对你的问题而言是最好的解决方案吗？你的问题到底是什么，以及你是否可以使用其他方法解决？

如果你说你的50人的工程师团队如果没有SOA就会难以运转，那么我会很好奇为什么那么多大公司使用一个很大但是管理得很好的单个应用程序也可以做的很好。

即使谷歌也不是谷歌

使用大型数据流引擎类似Hadoop和Spark也会特别有趣：通常，传统的数据库管理系统（DBMS）更适合于整体的工作负载，有时候数据量非常小，甚至可以存储在内存中。你知道可以使用10000美元购买一个千兆的内存条（RAM）吗？即使您拥有十亿用户，它仍可以为每个用户提供1kb的内存。

或许对于你的工作负载而言可能还不够，你需要对硬盘进行读写。但是你需要对数以千计的磁盘进行读写吗？确切的说，你拥有多少数据呢？GFS（可扩展的分布式文件系统）和MapReduce是为了处理整个网络的计算量而创造的，例如，在整个网络上重建搜索引擎……

上图：硬盘驱动器的每千兆字节的成本（美元）。今天的硬盘驱动器价格比2003年（GFS研究论文发布那年）低了很多很多。

或许你已经阅读了GFS和MapReduce的相关论文，而且很感谢谷歌的问题出现在输入输出量而不是容量上：他们进行分布式存储，因为磁盘存储需要太长时间。在2017年你将使用的硬件设备会有多大的输入输出量呢？考虑到你不会需要和谷歌一样的输入输出量，你是否只需要买一个更好的磁盘呢？使用SSD你会花多少钱呢？

或许你期望可以进行规模化。但是你有进行过数学计算吗？你累积数据的速度会比SSD价格下降的速度更快吗？你的业务需要增长多少，你的数据才会多到不能放在一台机器上。在2016年，Stack Exchange网站每天收到2亿个请求，而他们的后台仅仅是4台SQL服务器，一台主要服务于Stack Overflow网站，一台为其他事物服务，其他两台用来保存副本。

再次重申，你走完整个UNPHAT流程后，可能仍然决定使用Hadoop或者Spark。这个决定有可能是正确的。最重要的是，对于这个问题，你真的选择了最合适的工具。在这一点上，谷歌做的很好：当他们发现MapReduce不是构建索引最合适的工具后，他们就不再使用它了。

最重要的是理解问题

我上面提到的并不是全新的内容，但也许它能引起你的思考，或许使用UNPHAT对你来说有难以置信的效果。如果是这样，你可以尝试Rich Hickey谈话中（https://www.youtube.com/watch?v=f84n5oFoZBc）所提到的“吊床推动发展”，或者Polya书中（https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X）写到的“如何解决一个问题”，或者Hamming的课程中（https://www.youtube.com/playlist?list=PL2FF649D0C4407B30）所提到的“科学和工程实践的艺术”。我们希望你可以去思考并真正的了解你正在尝试解决的问题！

最后，我想以Ploya书中令人警醒的一段话作为结尾：

去回答一个你不明白的问题是愚蠢的。为了一个你并不想要的结局而努力是悲哀的。