我所读过的最好的一篇分布式技术文章学习笔记:The Log( 三 ) _log

的財富，事实上，是由一个建立在(用户)点击流和好恶印象(体验)之上的相关性产生的，而点击流和印象，就是事件。
各种各样的专业数据系统的爆发
这些系统存在的原因：
显然。要将数据整合进这样的系统中，对于数据集成来讲，极为困难。
2.3.3 基于日志结构的数据流
每种逻辑意义上的数据源，都能够根据log进行建模。
数据源能够是记录了事件(点击和PV)的应用程序。能够是接受更改的数据库表。
每一个订阅者。都尽可能快地从这些数据源产生的log中获取新的记录，应用于本地的存储系统。而且提升其在log中的读取偏移() 。订阅者能够是不论什么数据系统。比方缓存、、还有一个站点的数据库。或者搜索引擎。
Log，实际上提供了一种逻辑时钟，针对数据变化。能够測量不同的订阅者所处的状态，由于这些订阅者在log中的读取偏移不同且相互独立，这样的偏移就像一个时间意义上的“时刻”一样。
考虑这样一个样例，一个数据库。和一些缓存：
Log提供了这样一种能力，能够使得全部的缓存得到同步，并推出它们所处的“时刻” 。
假设我们写入了一个编号为X的log 。要从某个缓存读取数据，为了不读到老数据，仅仅须要保证：在缓存将数据(同步)拷贝到X这个位置前，我们不从这个缓存中读取不论什么东西就可以。
此外。log还提供了作为缓冲区的能力，以支持生产者和消费者的行为以异步的方式进行。
最关键的一个支持异步的原因，是订阅系统可能会发生崩溃、因维护而下线。接着恢复上线，而在这样的情况下。每一个订阅者都以自己的步调消费数据。
一个批处理系统，比方，或者一个数据仓库，是以小时或天为单位消费数据。而一个实时系统，通常在秒级消费数据。
而数据源或者log，对消费数据的订阅者一无所知。所以，须要在中做到无缝的加入订阅者和移除订阅者。
更重要的是，订阅者，仅仅须要知道log，而不须要对其所消费的数据的来源有不论什么了解，不管这个数据源是RDBMS、，还是一个最新流行的K-V数据库，等等。
之所以讨论log，而不是消息系统。是由于不同的消息系统所保证的特性不同，而且用消息系统这个词，难以全面和精确表达某种语义，由于消息系统。更重要的在于重定向消息。
可是，能够将log理解为这样一种消息系统。其提供了持久性保证及强有序的语义，在通讯系统中，这称作原子广播。
2.4 在
眼下的主要系统包括(注：2013年)：
每一个系统。都在其专业的领域提供专门的高级功能。
(这一段太长太长了。Jay兄十分能侃啊，所以挑重点的来记吧。)
1) 之所以引入数据流这个概念，是由于要在数据库的表之上，建立一个抽象的缓存层，为搜索引擎的索引构建和社交图谱更新，提供拓展能力。
2) 为了更好的处理的一些推荐算法，開始搭集群。但团队在此块的经验尚浅，所以走了非常多弯路。
3) 開始时。简单粗暴地觉得仅仅要将数据从数据仓库中拉出来，丢进就能够了。结果发现：第一，将数据从数据仓库高速导出是个噩梦；第二。也是更糟糕的一点。数据仓库中某些数据的处理不正确。导致了的批处理任务不能按预期输出结果，且通过批处理运行任务，通常不可逆。特别是在出了报表之后。
4) 最后。团队抛弃了从数据仓库中出数据的方式，直接以数据库和logs为数据源。
接着，造出了一个轮子：K-V 存储() 。
5) 即使是数据拷贝这样不高大上的活儿，也占领了团队大量的时间去处理。更糟的是，一旦数据处理的中有个点出错，立刻变得废柴，由于再牛逼的算法跑在错误的数据上。仅仅有一个后果，就是产生很多其他的错误数据。

我所读过的最好的一篇分布式技术文章 学习笔记:The Log( 三 )

我所读过的最好的一篇分布式技术文章学习笔记:The Log( 三 )