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

6) 即使团队构建的东西抽象层次非常高，针对每种数据源还是须要特定的配置，而这也是非常多错误和失败的根源。
7) 一大批程序猿想跟进，每一个程序猿都有一大批的想法，集成这个系统，加入这个功能。整合这个特色，或者想要自己定义的数据源。
8) Jay哥開始意识到：
第一，尽管他们构建的还非常糙，可是却极其有价值。即使是攻克了数据在新的系统(如)中可用的问题，也解锁了一大批可能性。曾经难做的计算開始变为可能。新的产品和分析。仅须要解锁其他系统中的数据，而且进行整合。就能够easy地做出来。
第二，非常明显，可靠地数据装载须要更坚实的支撑，假设能够捕获全部的结构。就能够让数据装载全然自己主动化，不须要加入新的数据源或人工改动数据的模式。
数据会奇妙地出如今HDFS中。而新的数据源加入后。Hive的表会用合适的列自己主动化地、自适应地生成。
第三。数据覆盖度远远不足。
由于要处理非常多新的数据源，非常难。
9) 为了解决新数据源加入后的数据装载问题，团队開始了这样的尝试：
非常快。他们发现这样搞行不通，由于公布和订阅、生产和消费。数据流通常还是双向的，这成了一个O(n^2)的问题。
所以，他们须要的是这样的模型：
须要将每一个消费者从数据源隔离。理想的情况下，这些消费者仅仅和一个data 进行交互，而这个能够提供它们訪问随意数据的能力。
10)消息系统 + log = Kafka 。kafka横空出世。
2.5 Log和ETL、数据仓库的关系 2.5.1 数据仓库
1) 一个装有干净的、结构化的、集成的数据，用于分析。
2) 尽管想法非常美好，可是获取数据的方式有点过时了：周期性地从数据库获取数据，将其转换为某种可读性更佳的格式。
3) 之前的数据仓库问题在于：将干净的数据和数据仓库高度耦合。
数据仓库，应该是一组查询功能的集合，这些功能服务于报表、搜索、ad hot 分析。包括了计数()、聚合()、过滤()等操作，所以更应该是一个批处理系统。
可是将干净的数据和这样的一种批处理系统高度耦合在一起，意味着这些数据不能被实时系统消费。比方搜索引擎的索引构建、实时计算和实时监控系统。等等。
2.5.2 ETL
Jay哥觉得，ETL无非做两件事：
1) 对数据进行抽取和清洗，将数据从特定的系统中解锁
2) 重构数据，使其能通过数据仓库进行查询。
比方将数据类型变为适配某个关系型数据库的类型，将模式转换为星型或者雪花模式，或者将其分解为某种面向列的存储格式。
可是，将这两件事耦合在一起，问题非常大，由于集成后的、干净的数据，本应能被其他实时系统、索引构建系统、低延时的处理系统消费。
数据仓库团队，负责收集和清洗数据，可是，这些数据的生产者往往由于不明白数据仓库团队的数据处理需求，导致输出非常难被抽取和清洗的数据。
同一时候，由于核心业务团队对和公司的其他团队保持步调一致这件事儿不敏感，所以真正能处理的数据覆盖度非常低，数据流非常脆弱，非常难高速应对变化。
所以，更好的方式是：
假设想在一个干净的数据集上做点搜索、实时监控趋势图、实时报警的事儿，以原有的数据仓库或者集群来作为基础设施。都是不合适的。
更糟的是，ETL所构建的针对数据仓库的数据载入系统，对其他(实时)系统点儿用没有。
最好的模型。就是在数据公布者公布数据之前，就已经完毕了数据的清洗过程，由于仅仅有公布者最清楚它们的数据是什么样的。而全部在这个阶段所做的操作，都应该满足无损和可逆。

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

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