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

全部丰富语义、或加入值的实时转换，都应在原始的log公布后处理(post-)，包括为事件数据建立会话。或者加入某些感兴趣的字段。
原始的log依然可被单独使用，可是此类实时应用也派生了新的參数化的log 。
最后，仅仅有相应于详细的目标系统的数据聚合操作，应作为数据装载的一部分，比方转换为星型或雪花型模式，以在数据仓库中进行分析和出报表。由于这个阶段，就像传统的ETL所做的那样。由于有了非常干净和规范的数据流，(有了log后)如今变得非常easy 。
2.6 Log文件和事件
以log为核心的架构，还有个额外的优点，就是易于实现无耦合的、事件驱动的系统。
传统的捕获用户活动和系统变化的方式，是将此类信息写入文本日志，然后抽取到数据仓库或者集群中进行聚合和处理。这个问题和前面所述的数据仓库和ETL问题相似：数据与数据仓库的高度耦合。
在，其基于kafka构建了事件数据处理系统。
为各种各样的定义了成百上千种事件类型，从PV、用户对于广告的赶脚(ad )、搜索。到服务的调用和应用的异常。等等。
【我所读过的最好的一篇分布式技术文章学习笔记:The Log】为了体会上述事件驱动系统的优点，看一个简单的关于事件的样例：
在工作机会页面上，提供一个机会。这个页面应该仅仅负责怎样展示机会，而不应该过多地包括其他逻辑。可是。你会发现，在一个具有相当规模的站点中，做这件事，非常easy就会让越来越多的与展示机会无关的逻辑牵扯进来。
比方，我们希望集成以下系统功能：
1) 我们须要将数据发送到和数据仓库做离线处理。
2) 我们须要统计页面浏览次数，以确保某些浏览不是为了抓取网页内容什么的。
3) 我们须要聚合对此页面的浏览信息。在机会公布者的分析页面上呈现。
4) 我们须要记录某用户对此页面的浏览记录。以确保我们对此用户提供了有价值的、体验良好的不论什么适宜此用户的工作机会，而不是对此用户一遍又一遍地反复展示某个机会(想想老婆不在家才干玩的游戏吧，那红绿蓝闪烁的特效。配合那劲爆的DJ风舞曲，或者那摇摆聚焦的事业峰和齐X小短裙的girls，然后点进去才发现是标题党的ad吧！) 。
5) 我们的推荐系统须要记录对此页面的浏览记录，以正确地追踪此工作机会的流行度。
非常快，仅仅展示机会的页面逻辑。就会变得复杂。当我们在移动端也添加了此机会的展示时，不得不把逻辑也迁移过去，这又加剧了复杂程度。还没完，纠结的东西是，负责处理此页面的师，须要有其他系统的知识。以确保上述的那些功能能正确的集成在一起。
这仅仅是个极其简单的样例，在实践中，情况仅仅会更加复杂。
事件驱动能够让这件事变得简单。
负责呈现机会的页面，仅仅须要呈现机会并记录一些和呈现相关的因素，比方工作机会的相关属性，谁浏览了这个页面。以及其他的实用的与呈现相关的信息。页面不须要保持对其他系统的知识和了解，比方推荐系统、安全系统、机会公布者的分析系统，还有数据仓库。全部的这些系统仅仅须要作为订阅者，订阅这个事件，然后独立地进行它们各自的处理就可以，而呈现机会的页面不须要由于新的订阅者或消费者的加入而做出改动。
2.7 构建可扩展的log
分离公布者和订阅者不新奇，可是要保证多个订阅者能够实时处理消息，而且同一时候保证扩展能力，对于log系统来说。是一件比較困难的事。
假设log的构建不具备高速、低开销和可扩展能力。那么建立在此log系统之上的一切美好都免谈。

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

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