From 089df0a066579a8762848403bc7d238ab936127d Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Tue, 18 Aug 2015 20:59:29 +0800 Subject: [PATCH] =?UTF-8?q?=E5=AE=A1=E6=A0=A1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../part2-data-integration.md | 54 ++++++++++--------- 1 file changed, 28 insertions(+), 26 deletions(-) diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md index 06e3ad0..77be5cf 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md @@ -157,7 +157,7 @@ 有些东西在我面前开始渐渐清晰起来。 首先，我们已建成的通道虽然有一些杂乱，但实际上是极有价值的。 -仅在一个新的处理系统（`Hadoop`）让数据可用于处理 就开启了大量的可能性。 +仅在一个新的处理系统（`Hadoop`）中让数据可用于处理 就开启了大量的可能性。 基于这些数据过去很难实现的计算如今已变为可能。 许多新的产品和分析技术都来源于把多个数据片块放在一起，这些数据过去被锁定在特定的系统中。 @@ -193,7 +193,7 @@ 集成工作只需连接这个新系统到一个单独的管道，而无需连接到每个数据消费方。 这样的经历使得我专注于创建[`Kafka`](http://kafka.apache.org/)，把 我们所知的消息系统的特点 与 在数据库和分布式系统内核常用的日志概念 结合起来。 -我们需要首先一个实体作为所有的活动数据的中心管道，并逐步的扩展到很多其他使用方式，包含`Hadoop`之外的数据、数据监控等等。 +我们首先需要一个实体作为所有的活动数据的中心管道，并逐步的扩展到其他很多的使用方式，包括`Hadoop`之外的数据、数据监控等等。 在相当长的时间内，`Kafka`是独一无二的（有人会说是怪异） —— 作为一个底层设施，它既不是数据库，也不是日志文件收集系统，更不是传统的消息系统。 @@ -206,14 +206,16 @@ `ETL`与数据仓库的关系 ------------------------- -我们再来聊聊数据仓库。数据仓库旨在包含支撑数据分析的规整的集成的数据结构（`clean, integrated data structured`）。 -这是一个伟大的理念。对不了解数据仓库概念的人来说，数据仓库方法论包括了： -周期性的从源数据库抽取数据，把它们转化为可理解的形式，然后把它导入中心数据仓库。 -对于数据集中分析和处理，拥有高度集中的位置存放全部数据的原始副本是非常宝贵的资产。 -在高层级上，无论你使用传统的数据仓库`Oracle`还是`Teradata`或`Hadoop`， -这个方法论不会有太多变化，可能[调整](http://searchdatamanagement.techtarget.com/definition/Extract-Load-Transform-ELT)一下抽取和加载数据的顺序。 +Having this central location that contains a clean copy of all your data is a hugely valuable asset for data-intensive analysis and processing -数据仓库是极其重要的资产，它包含了原始的和规整的数据，但是实现此目标的机制有点过时了。 +我们再来聊聊数据仓库。数据仓库旨在包含支撑数据分析的规整的集成的结构化数据。 +这是一个非常好的理念。对不了解数据仓库概念的人来说，数据仓库的用法是： +周期性的从源数据库抽取数据，把它们转化为可理解的形式，然后把它导入中心数据仓库。 +对于数据集中分析和处理，拥有高度集中的位置存放全部数据的规整副本对于数据密集的分析和处理是非常宝贵的资产。 +在更高层面上，无论你使用传统的数据仓库`Oracle`还是`Teradata`或`Hadoop`， +这个做法不会有太多变化，可能[调整](http://searchdatamanagement.techtarget.com/definition/Extract-Load-Transform-ELT)一下抽取和加载数据的顺序。 + +数据仓库是极其重要的资产，它包含了的和规整的数据，但是实现此目标的机制有点过时了。 @@ -223,23 +225,23 @@ 这就意味着，如果一个系统需要 实时数据输入的实时系统（如实时处理、实时搜索索引、实时监控等系统），这些数据是不可用的。 依我之见，`ETL`包括两件事。 -首先，它是数据抽取和数据规整的处理 —— 本质上就是释放被锁在组织的各类系统中的数据，去除特定于系统的约束。 +首先，它是数据抽取和清理的处理 —— 本质上就是释放被锁在组织的各类系统中的数据，去除特定于系统的约束。 第二，依照数据仓库的查询重构数据，例如使其符合关系数据库类型系统， -强制使用星型`schema`（`star schema`）、雪花型`schema`（`snowflake schema`），可能会打散数据成高性能的[列](http://parquet.io/) [格式](http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/orcfile.html)（`column format`），等等。合并这两者是有困难的。 +强制使用星型`schema`（`star schema`）、雪花型`schema`（`snowflake schema`），可能会打散数据成高性能的[列](http://parquet.io/) [格式](http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/orcfile.html)（`column format`），等等。同时做好这两件事是有困难的。 这些集成仓库的规整的数据除了要索引到实时存储系统中，也应当可用于实时或是低时延处理中。 -在我看来，正是因为这个原因有了额外好处：使得数据仓库`ETL`大大提升了组织级的可伸缩性（`scalable`）。 -数据仓库团队的典型问题是负责收集和整理组织中各个团队所生成的全部数据。 -对各个团队的激励是不对称的：数据的生产者常常并不知晓在数据仓库中数据的使用情况， +在我看来，正是因为这个原因有了额外好处：使得数据仓库`ETL`大大提升了**_组织级_**的可伸缩性（`scalable`）。 +典型的问题是数据仓库团队要负责收集和整理组织中各个团队所生成的全部数据。 +两边的收益是不对称的：数据的生产者常常并不知晓在数据仓库中数据的使用情况， 结果产生的数据，为了转成为可用的形式，抽取过程很难或是很繁重，转换过程很难统一规模化。 -当然，为了中心团队的规模不可能跟上组织中其它团队增长， +当然，中心团队的规模不可能跟上组织中其它团队增长， 结果数据的覆盖率总是参差不齐的，数据流是脆弱的，跟进变更是缓慢的。 较好的做法是有一个中央管道即日志，用定义良好的`API`来添加数据。 集成这个管道和提供良好的结构化的输入数据所需的职责由提供数据的生产者承担。 这意味着作为系统设计和实现一部分的生产者，在交付到中心通道时， 必须考虑其输出和输入的数据要有良好结构形式的问题。 -新的存储系统的加入对于数据仓库团队是无关紧要的，因为他们现在有的是一个中心结点去集成。 +新的存储系统的加入对于数据仓库团队是无关紧要的，因为他们现在只有一个中心结点去集成。 （**_译注_**：原来要集成的是其它各个相关的系统，工作是被简化了的） 数据仓库团队需只处理更简单的问题，从中心日志中加载结构化的输入数据、完成特定于他们系统的数据转换。 @@ -248,7 +250,7 @@ 从上面讨论可以看出，当考虑采纳传统的数据仓库之外额外的数据系统时，组织级的伸缩性（`organizational scalability`）显得尤为重要。 例如，想为组织的所有的数据集提供搜索能力。 或者想为数据流的监控的次级监控（`sub-second monitoring`）添加实时数据趋势和告警。 -无论是哪个情况，传统的数据仓库的基础设施，甚至是`Hadoop`聚簇都将不再适合。 +无论是哪个情况，传统的数据仓库的基础设施，甚至是`Hadoop`集群都将不再适合。 更糟的是，用于支持数据加载的`ETL`处理管道可能输入不了数据到其它系统， 和带动不了要动用数据仓库这样的大企业下的那些基础设备。 这样的做法应该是不可行的，可能可以解释为什么多数组织对他们的所有数据很难轻松具备这样的能力。 @@ -272,7 +274,7 @@ 原始日志仍然是可用的，但这样的实时处理生产了包含增强数据（`augmented data`）的派生日志。 最后，只有针对目标系统的聚合操作才应该加到加载过程中。 -比如可能包括在数据仓库中为分析和报表而做的把数据转化成特定的星型或者雪花状模式。 +比如可能包括在数据仓库中为分析和报表而做的把数据转化成特定的星型或者雪花状`schema`。 因为在这个阶段（一般比较自然地对应到传统的`ETL`处理阶段），现在处理的是一组规整得多和统一得多的流， 处理过程已经大大简化了。 @@ -283,10 +285,10 @@ 在`Web`行业取得活动数据的典型方法是把打日志到文本文件中， 然后这些文本文件分解进入数据仓库或者`Hadoop`用于聚合和查询。 -这做的问题和所有批处理的`ETL`做法一样：数据流耦合了数据仓库系统的能力和处理的计划。 +这做的问题和所有批处理的`ETL`做法一样：数据流耦合了数据仓库系统的能力和处理计划（`processing schedule`）。 -在`LinkedIn`，我们以中心日志的风格构建事件数据处理。 -我们使用`Kafka`做为中心的多订阅方的事件日志，定义数百种事件类型， +在`LinkedIn`，是以在中心日志完成处理的方式构建事件数据。 +`Kafka`做为中心的有多个订阅方的事件日志，定义数百种事件类型， 每种类型都会捕获一个特定动作类型的独特属性。 这样的方式覆盖从页面浏览、广告展示、搜索到服务调用、应用异常的方方面面。 @@ -302,7 +304,7 @@ 1. 推荐系统可能需要记录浏览，以正确的跟踪作业的流行程度 1. 等等 -有不了多久，简单的作业显示变得相当的复杂。 +用不了多久，简单的作业显示变得相当的复杂。 与此同时，还要增加作业显示的其它终端 —— 移动终端应用等等 —— 这样的逻辑必须继续实现，复杂程度被不断地提升。 更糟的是，我们需要交互的系统是多方需求交织缠绕在一起的 —— @@ -322,15 +324,15 @@ 那么可伸缩性就会成为你所面临的首要挑战。 如果我们不能创建快速、低成本和可伸缩的日志以满足实际大规模的使用，把日志用作统一集成机制只不过是个美好的幻想。 -人们普遍认为分布式日志是缓慢的、重量级的抽象（并且通常只把它与『元数据』类的使用方式联系在一起，`Zookeeper`可能才适用） +人们普遍认为分布式日志是缓慢的、重量级的抽象（并且通常只把它与『元数据』类的使用方式联系在一起，可能用`Zookeeper`才合适）。 但有了一个专注于大数据流的深思熟虑的实现可以打破上面的想法。 在`LinkedIn`，目前每天通过`Kafka`写入超过600亿条不同的消息。 （如果算上[数据中心之间镜像](http://kafka.apache.org/documentation.html#datacenters)的消息，那么这个数字会是数千亿。） -为了支持这样的规模，我们在`Kafka`中使用了一些小技巧： +为了支持这样的规模，我们在`Kafka`中使用了一些技巧： 1. 日志分片 -1. 通过批处理读出和写入来优化吞吐量 +1. 通过批量读出和写入来优化吞吐量 1. 规避无用的数据拷贝 为了确保水平可扩展性，我们把日志进行切片： @@ -348,7 +350,7 @@ 事实上，与日志的交互一般来源于成百上千个不同的处理流程，所以为所有处理提供全局顺序没有意义。 转而需要的是，我们提供的每个分片有序的保证，和`Kafka`提供的 同一发送者发送给同一分区的消息以相同的顺序交付到接收者 的保证。 -日志，和文件系统一样，对于顺序读写可以方便地优化。日志可以把小的读写合的大的高吞吐量的操作。 +日志，和文件系统一样，对于顺序读写可以方便地优化。日志可以把小的读写合成大的高吞吐量的操作。 `Kafka`非常积极做这方面的优化。客户端向服务器端的数据发送、磁盘写入、服务器之间复制、到消费者数据传递和数据提交确认 都会做批处理。