是到该总结的时候了。但是怕又陷入以前的陷阱总是写不完，那就写成连续的吧。

    从2010年开始介入量子统计系统的设计到开发，恍然间已经两年时间过去了。很多情况下都是业务在驱动着工程化和站在原来量子统计的架构设计、工程实现上前行(感谢@史绪良爱自由)。

    1. 先说一下工程结构吧： 说数据处理的结构又必须唆说一下CAP理论(中文、英文)

    这三个特性在分布式系统里面是不能兼得的。尽管在做量子数据系统工程化开发的时候，心中并没有这样的概念，但是理论真的很重要，越到后来越重要。

    不好意思，还得再离开小标题一下，说一下业务场景和需求：

1. 用户需要尽快的看到他所在的淘宝店铺的数据变化情况

2. 要尽可能廉价的服务用户

3. 尽可能完成各种数据计算，并且结果要准

4. 要尽可能的服务更多的用户

    翻译为工程需求就是：

1. 实时或者准实时计算和查询的需求

2. 系统的需要在架构和单个procedure上进行高度优化和特化

3. 支持通用统计计算的需求，开发效率要高

4. 系统要能够线性缩放

    是不是和Cap理论的三个特性说的是一件事情？呵呵。当然当时并不知道在一个系统里面是做不到的(浅薄啊！)，但是最后在工程上，我们还是通过对数据和业务的进一步拆分和理解来绕开了这个问题。

    前段时间看到了twitter工程师Nathan Marz的一篇文章《How to beat the CAP theorem》，只能感叹“殊途同归”，我们的实现是如此惊人的相似，但是twitter在工程化和系统化上达到高度，我们还暂时有不小的差距，尽管我们有很多比他们好的地方，但是还是偏散，不过我们一直在学习、在进步不是？

    通过将业务需求拆分为两个部分：离线处理和在线实时处理，利用不同业务下的数据特性，较好的解决了量子的业务工程需求。简单的可以用下面的图描述工程实现：

    思路总是很散，又想说说对“数据”这个词的理解了。我认为任何的web应用都是固定逻辑驱动下的数据状态转移。因此LAMP以前是如此的完美，直到“big data”的出现。在LAMP系统里面或者OLTP系统里面，数据其实是被当做变量看待的，大家关注的是对这个变量的查找、更新和清空(删除)。但是随着OLAP系统的出现，数据才被当做了事实状态看待(事实表)，数据一旦产生就不会变化，它是一个结果，变化的是驱动结果生成的动作，是不是和函数式编程或lambda演算类似？

    而随着big data场景的出现，我个人认为在对系统进行业务设计和工程实现上，应该更多的用OLAP的思想更多的来看待数据。

    举一个例子，12306.cn。尽管微博上有如此的多的笑话在讽刺12306.cn的工程实现，但是说实话面对如此变态的业务需求和场景，以及体制上的弊端能实现到这个地步已经是相当相当不容易了。

    但是如果能够重新审视一下数据的观察方法，从而变更一下业务模式也许结果会更好一些：

    1. 票永远是稀缺资源，这个也不能怪铁道部，因为不能仅仅为了迎接春节这个“秒杀”高峰，修建过多的铁路，而在其它时段闲置，其实是极大的浪费。所以不会因为是否网络、电话购票而让更多的人能买到票，只是转移了购票的难度和降低了整个社会的购票成本(基于通信费免费的假设)。

    2. 订票的数据不应该全部看做是即时交易变量，按照需求分成两个部分：

1. 预订购阶段。为什么一定要把购买15天后的火车票的行为当做实时订购而必须立刻返回结果呢？批量提交、批量处理岂不是很好。

2. 实时订购阶段。对于马上就要出发的人来说，这个部分是不可或缺的。

    这样的话，对于预订购阶段数据就变成了事实状态，通俗点说就是日志。处理就变成了批处理，有一堆成熟实现等着我们使用呢！呵呵。 由于大量的用户都在预订购的阶段得到了满足，所以实时订购阶段的压力陡然下降，好的数据库+好的DBA+好的sharding设计，解决起来也不是难事。

    好了，又偏题了，就先写到这里吧。 所以最后我们需要实现的其实是两个系统：

    一个需要AP：离线计算，批数据因为没有变更，所以不存在一致性的问题。

    一个需要CA：准实时计算。系统是集群，但是集群间的机器是完全独立的，所以它并不属于分布式。  

    先介绍一下离线计算：

    简单来说，一句话就可以介绍完：hadoop和它的朋友们(工具软件)。

    但这个系统很棘手的地方在于两个方面：集成和调优

    先说一下集成：

    集成又可以分为两个方面：

1. 系统、软件、工具的整合、监控和运维

2. 广义数据仓库的管理、监控、协同和运维

    第一个方面比较好理解，那我们先说说它的棘手之处以及我们的一些解决思路和办法。还是从工具的角度开始吧：

    1. hadoop是非常优秀的批数据处理工具，为了更好的提升开发效率，淘宝数据部门或开发或整合，并集成了下面的工具：

1. HIVE：利用SQL+UDF来完成数据的计算，是提升离线数据处理、数据仓库开发效率和产出稳定性的利器。存在的缺陷是：典型的数据仓库工程师开发方式，随着处理逻辑的复杂，SQL将非常复杂，调试、优化、重构的难度急剧提升。对于非数据仓库开发工程师学习曲线也偏高。

2. TT：实时日志数据收集工具。我们千万不要落入“乐观”的陷阱，这个系统要满足“实时”，“大容量”、“高可靠”、“不丢失”、“可扩展”这些特性，挑战是相当大的。而实时这个特性，不仅可以让业务能够做出更多精彩的产品，而且对于技术来说也至关重要，曾经有人问过我，我要跨机房传递海量数据怎么办(不影响现有业务系统、带宽有限……)，答案就是实时，将峰值削减到一个个时间片中。这块儿的一个开源实现是：Flume。

3. SkyNet+meta工具：任务管理和调度系统。这个系统主要是为了解决两个让数据开发人员头痛的问题：

1. 复杂依赖任务的调度和监控。首先要保证调度的正确性，换句话就是：数据生产流水线不能跳开依赖、不能混淆依赖、任务完整性保证。然后要保证调度策略的高效。还有一点就是部分的冗余是必要的，大公司最大的一个问题就是随着时间的前进，数据任务生产的链条会越来越长，也就是意味着越来越脆弱，一个简单的办法就是，对于可靠性要求非常高的任务，通过冗余计算和存储的方式，缩短生产链条，尽可能从源头开始。

2. 数据复用和冲突。Meta信息的管理是关键，方便易用的界面同样是关键。

这块儿的开源实现有：Cascading。

4. 数据装载工具LzLoader或者DataX：LzLoader是量子这边开发的更为特化的数据装载工具，负责将离线生产的数据装载进入Mysql展现数据库，优点是很好的封装了数据库分库分表的逻辑，和完善的数据导入监控。DataX是一个更为通用的工具，能够完成从hadoop到数据库的直接装载，我们也会在量子今后更通用的业务场景中使用。

    那接着说第二方面，数据仓库相关的。

    2006年的时候，我最开始是不怎么鸟数据仓库方法的，我轻率的认为数据仓库是把简单的事情搞复杂了。现在看来有对的地方，但是更多的是错误。

    对的地方就是：如果你的业务是通常的web产品，有时候需要统计、计算、分析一些数据的时候，的确不需要数据仓库(相关的思想嘛，不知道也不会有大麻烦)。但是对于一个数据部门就大错特错了，纷繁的需求、多样的业务、各种轻重缓急的ticket、许多或虚幻或实际的数据求证业务的假设……，没有良好的数据仓库系统，我们将寸步难行。

    数据仓库之所以叫仓库，目标直指“数据”的良好管理，由于业务逻辑分析的需要，多维数据分析是比较常用的方法，它通常的数据模型设计方式有：

1. 星型模型，简单来说就是维表直接和事实表关连，呈放射形的星光状。

2. 雪花模型，要复杂一些，更多的维表可以通过别的维表间接的和事实表关连，有点像分形的雪花。

    “big data”的出现，让大公司的数据仓库正在快速的抛弃传统的数据库方案实现，更多的使用了刚才前面列出的工具，更多的一些工具，感兴趣的同学可以看看《big data glossary》。

    那么数据仓库最大的困难点是什么呢？协同！不仅是仓库内部的数据协同，它是整个公司数据生态的协同。虽然都是数据，但是如果每个部门的定义、采集、处理的逻辑都有不同，那么数据仓库计算出的数据将是“灾难”。怎么办呢？主要的办法还是需要抓住数据源，把最源头的数据统一管理起来，建立起统一的meta信息，然后建立良好的数据接口人制度，确保系统能够螺旋上升，而不是逐步恶化。

    数据仓库最让人“抓狂“的点是什么呢？需求处理！大量的需求会来到数据仓库部门，进行数据提取、协助分析、报表建设。我的实践经验就是两条：

1. 流程化管理，要解决资源冲突的唯一方法。

2. 提升系统化能力，让工程师去做系统和工具，而让各业务分析员使用这个系统和工具来分析数据(呵呵，广义上的分布式概念了)。

    说了这么多数据仓库的事情，我应该是班门弄斧了，打住。更多的可以@eNeolithic,@淘依韵。

    罗列了这麽多工具或者软件，我想说明的就是：随着big data工具软件生态系统的壮大，我们有很多选择，但是整合至关重要。

    随着系统越做越大，你的运维能力将极大的制约你的发展，如果你的公司提供一个运维团队支持你，你一定要把他们拉到你的业务系统里面，让他们了解你的业务，吸取他们给你的建议，相信我他们一定会极大的帮助到你，虽然刚开始的时候会很痛苦。如果没有这样的运维团队，你也需要抽出专人来做这件事情。

    再说一下优化：

    优化分为两个方向，一个是业务方向的优化，另外一个是系统方向的优化(谢谢数据平台杭州的同学承担了这个部分)。业务优化有很多细节的问题，争取邀请团队一位别的同学来写这块儿，我写一些原则和粗的吧：

1. 减少IO，HIVE SQL 有很多hint的地方，可以让你根据数据的分布，来决定更好的IO方式。

2. 减少数据倾斜，http://www.tbdata.org/archives/2109讲的很好了

3. 减少任务中map-reduce的迭代次数，这个是Hive的一个小缺点，不太好控制。

    思路有些乱了。休息一下。