实时大数据系统的设计原则

Big data的管理是一个Internet-scale软件的最热门问题，随着Hadoop stack的发展，慢慢趋于完善

目前，File system、DB、DW、BI等一系列的层次结构都有相当代表性的开源产品

纵观DBMS的发展，新需求总是按照一个过程走的：从OLTP到OLAP，再到BI，下一个热点需求是什么？是的，Realtime

浏览到一个Slides如下

http://www.slideshare.net/nathanmarz/the-secrets-of-building-realtime-big-data-systems

文章提到的基础架构是：Batch+RT，这个和传统DW中的做法非常一致，典型的实现是SAP BW的Delta机制，其实对于SSD的几个相关论文也是如此的思路，差不多是Delta B-tree的结构，本质是适应SSD的特性：Random Write相比Random Read很差

有两个细节点值得玩味：

1. Page39指出：“Once data is absorbed into batch layer, can discard speed layer results”，也就是说，Batch过程的数据作为唯一的基准，这一点非常赞同，和同行就这个问题展开过激烈的讨论，本质上，该问题是ETL需要几路的问题，在Ralph的经典著作“Data Warehouse ETL Toolkit”中明确提到ETL本质上是需要Batch方式，除了Extract过程，数据的Clean、Conform和Load，在应用中无一例外需要批量的计算，RT会造成相当的困难，特别的，针对Internet-scale数据管理，有以下几个dilemma：

1.1 Log的Anti-spam过程，很多情况下，反作弊是需要等到超过一个阈值的重复点击才能判定的，这样，限制了Clean的实时性；但是非作弊的点击计算能很大程度上提高指标预估的质量；

1.2 Session的整合，理论上不可能识别用户访问的结束点（除非用户关闭浏览器），所以，基于Session的计算是很难实时的（惯例是30分钟没有交互认为结束，也就是说，30分钟之后，才能知道Session是否结束）；但是另外一方面，实时的Session是非常有价值的信息，例如，用户当前Session的时长等信息，据此计算的策略非常有效；

1.3 通常的Big data采用Append的方式批量载入数据，例如：Hadoop stack；另一方面，Low Update Lantency的系统是不允许这种方式的

抛开ETL，单从查询上看（特指DW系统），数据管理需要一个可信任的Snapshot，否则带来严重的Query Contention问题；然而，RT的数据从理论上是不能满足的

2. Page 44提出一个可爱的名词“Eventually Accuracy”，这其实是一个解释，帮用户理解RT流的特征：“可以提供给你RT的数据，但是要求别太高了”，呵呵

除此之外，我认为还应该考虑的论题是： Batch和RT系统本质上是Hybrid的，处理过程和质量不同，但是需要在ETL和Query两方面做到共享，那就是：

1. ETL中的共享，Parser？Cleansing？必要的Join和schema mapping？

2. Query中的共享，Schema？

3. Managibility上的问题，Data quality？特别的一个是ACL