一直在特定领域的分布式系统一线摸爬滚打，曾取得一些微不足道的成绩，也犯过一些相当低级的错误。回头一看，每一个成绩和错误都是醉人的一课，让我在兴奋和懊恼的沉迷中成长。自己是个幸运儿，作为一个 freshman 就能够有机会承担许多 old guy 才能够有的职责。战战兢兢、如履薄冰的同时，在一线的实作和思考也让我获得了一些珍贵的经验，却直至今日才够胆量写出来一晒。这篇文章标题前面是“妄谈”两字，所持观点未必正确，我姑妄言之，有缘之人姑听之。若有些友好的讨论，亦我所愿也。

    我做的虽然也是分布式系统，却不够胆去讨论通用分布式系统的设计原则。因而这篇文章的主题限定到一个特定领域的分布式系统设计，这样即使别人有疑惑，我也可以把 TA 拖到我擅长的领域打败 TA :)

    既然要限定，我们需要给这个系统下个定义，就有必要解释一下标题。

    大数据(Big Data)，这是由于分布式系统和云计算的风靡而变得很火的一个词。那么多大的规模才算大数据呢？目前没有定义，但要讨论这个问题，就必须给个确定的范围。在本文中，这个范围暂时定义为 10TB~1PB 的数据量。为什么是这个范围？我的理由是，小于 10TB 的数据规模有比较多的可选方案；大于 1PB 的数据规模，讨论的意义不大，下面会谈到。

    表格型数据，是指数据是有结构的，类似于关系型数据库中的表，但不是关系型，至少不是完整的关系型。在大数据的范围内，不能说完全没有关系型的需求，但这个需求实际上是很小的。因为关系操作的复杂性，使得其在大数据上的性能非常差，此类的需求往往使用数据冗余等其它方式来实现。是性能原因，而不仅是实现难度导致它不被需求。

    时间序列数据，是指数据是按照时间产生的，跟随时间而变化的分析型数据。其实分析型数据一般都是时间序列的。与操作型数据不同，在分析型数据中单单一条记录的信息是很小的，只有与其它数据进行对比、组合、分解，这条记录才会体现出其价值。

    在这些限定词下，这个系统的用途就比较清楚了。它可以被用到很多地方：比如网站访问统计(Google Analytics 和百度统计)、APP 的数据统计、集群服务器状态收集、在线广告的展现和点击量等等。它是一个数据仓库，但庞大于一般的数据仓库，功能需求却少于一般的数据仓库，而且很强调性能。在这个级别上，我还没看到成熟的开放系统解决这个问题(也许我是孤陋寡闻)，基本上每家都是自己实现，所以它也更值得讨论。

    由于不知该如何系统地探讨，我下面只能把自己发散的思维整理为一条条简单的原则，可能会有很大的跳跃性。但是，谁在乎它连不连贯呢？

    latency 对你很重要时，不要采用分层设计，优化做得越底层越好

    事实上，对于有兴趣做这样一套系统的公司，latency 都很重要。因为 latency 不重要时它们完全可以使用 HBase。而且，当你有超过 1PB 数据时，你会发现其中很大一部分的 latency 不重要，那剥离出来这部分，用 HBase 吧。

    在这个数据量上，必须采用分布式的实现方案。但不要为了系统逻辑的清晰而做存储层与应用层分离的实现，像 BigTable 那样。因为 locality 可以显著地降低 latency，做了存储层和应用层的分离，那你就放弃了很多可以优化的地方。否则你必须破坏分层的封装性，像 Facebook 对 HBase 做的那样。

    MySQL 不是一个选项，分布式 MySQL 也不是，分布式 KV 也不是，做自己的系统吧

    总会有人问这些问题：为什么数据库(分布式数据库、分布式 KV 存储)不能用于这样的场景？我只能说，原因关键是上面三个形容词：时间序列数据、表格型数据、大数据。此外可能还要加上性能、成本等其它因素。

    问出上面这个问题的人，其实都可以去用数据库或者 KV 系统，大部分情况下他们的需求会被满足。因为实践过且不满足需求的人，不会问上面这个问题，所以自己找出为什么吧，更容易些。

    索引很重要，但要注意控制粒度

    上面说过，对于分析型数据而言，单条记录没那么重要，所以快速地获取一条记录不会成为此类系统的目标，而且索引会降低数据更新的性能。但是能不要索引吗？开玩笑，那你怎么查询！索引必须要有，但要考虑到业务场景，做到合适的粒度。所谓合适的粒度，就是能快速获得目标数据而又不至于影响数据更新的性能。

    内存很重要，能省则省，能用就用完

    内存的重要性大家都明白，但很少人能真正理解。能省则省——说的是不要用浪费空间的数据结构；能用就用完——说的是在保证服务器能正常工作的前提下，使用最多的内存。

    IO 很重要，做任何能减少 IO 次数和数据量的事，如果要折衷，选择优化次数

    对于分析型数据而言，CPU 向来不是瓶颈，IO 才是。做任何能减少 IO 次数和数据量的事，比如各种缓存(块缓存、索引缓存、请求结果缓存)，比如数据压缩。如果在减少 IO 次数和减少数据量上做折衷，选择减少 IO 次数，除非这会导致数据量爆炸。

    即使没分层，也不要随机写

    即使能直接访问到本地文件系统，也不要使用随机写，不要向一个文件中插入内容，而是将更新与基准合并写入另一个文件。这样性能更高，真的。

    支持 CRUD？不，只支持 CRA，A for aggregate

    其实很多数据都可以表示成时间序列型数据，例如 MySQL 的数据表内容完全可以用时间序列的操作日志来表示，这也是 Twitter 首席工程师 Nathan Marz 提倡的，他说有 CR 就够了。虽然我没有那么极端，但是朋友，我们处理的就是时间序列数据啊，所以我们完全不需要 UD。增加 A 的原因是，聚合会减少数据量，聚合会提升查询性能。

    一定要压缩数据，选择一个合适的压缩算法

    原因很简单，这能够减少 IO 数据量。但不要傻乎乎地压缩整个文件，跟 BigTable 学，分块压缩。考虑到对数据更新和读取的性能偏重不同，选择对自己合适的压缩算法。因为列存储的压缩比一般而言更高，所以

    如果能做列存储，就做吧

    尽量分离更新和读取的压力

    如果数据需要做清洗，可以聚合，那么在导入系统前做这件事，而不是让承担查询压力的系统做这件事。

    实时性没那么重要，批量更新会让你更轻松

    如果能接受一天的延迟，就每天一批；能接受一个小时的延迟，就不做分钟级更新。更新次数越少，预聚合效果越好，数据量越小；更新次数越少，一致性越容易保证；更新次数越少，事故处理越从容。实时更新的话，很多事情会变得非常复杂，尤其是故障处理。

    用数据冗余实现关系型需求或者高性能需求

    如果有关系型运算需求，一定要逼 PM 改掉。实在改不掉，在导入系统前(或者过一段时间后)计算得到结果，直接导入到系统中。高性能需求也是这样，提前在系统外聚合好再导入，让系统做最少的事情它才能更快。

    分布式架构？不重要，重要的是可靠性

    至于采取什么样的分布式架构，其实不重要。只要它能实现 IO 的(大致)负载均衡，并且可靠就够了。另外，值得一提的是，如果想实现中心机，选举，分片自动分裂、合并、迁移等 fancy 分布式技术，首先想想自己公司是不是行业领导者。Perfect is the enemy of good. 对于很多人来说，Zookeeper 足够了。

    借鉴别人经验

    这个不用我解释了吧。找一切可利用的信息，和一些人讨论，自己做决定。 :)

    (暂时写到这里，但我可能会更新这篇文章，当我想到更多时。)

建议继续学习：

1. 大数据下的工行    (阅读：5537)
2. 企业掘金大数据的两种选择    (阅读：2124)
3. 数据化比大数据更靠谱    (阅读：2069)
4. 大数据过滤及判断算法 -- Bitmap / Bloomfilter    (阅读：1275)
5. 五种常用基数估计算法效果实验及实践建议    (阅读：970)