江苏龙网

  1. 首页 > 人文 > >

InfoQ|重新思考日志：业务系统竟然是一个大数据库？( 三 )


日志与ETL、数仓数据仓库以适合离线数据分析的方式将企业内部的所有数据结构化地集成到一起 ， 这是一个伟大的想法 。 数仓的建设需要周期性地从各种源数据库中抽取(Extract)数据 ， 转化(Transform)成更好理解的形式 ， 最后加载(Load)进中心化的数据仓库 。 一个存储所有企业数据的中心数据仓库内部拥有许多等待挖掘的价值 。
然而 ， 这种通过批处理的将数据整合到一起的方式并不能解决所有问题 ， 其短板在于 ， 一些消费数据的系统需要更加实时的反馈 ， 比如搜索引擎建立索引、推荐系统持续优化、监控系统实时观察 。 将数据集成到一起的思想仍然是伟大的 ， 但我们也许能够找到弥补批处理方案缺点的其它方案 ， 来满足特点不同的数据需求 ， 这就是日志为中心的方案 。
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
在这样的设计中 ， 原来在ETL中的数据转化的工作应该放到哪个位置？大致有以下几种选择：
数据生产者在将数据写入日志系统前
对原始日志进行实时流式处理
在最终加载到数据消费系统时
其实这里我们并不需要做三选一的决定 ， 而是将ETL的工作分类后分别放入这三部分中 。 数据生产者在生产数据时 ， 需将数据转化成与系统内部逻辑无关的数据结构；在实时流式处理的过程中 ， 可以将数据补充(如join)的工作放入其中；在数据消费系统可以做最终的数据聚合(aggregation) 。
日志与流处理为什么需要日志日志与流处理是两个互相独立的概念 。 我们可以让分布式系统中的不同进程直接通信 ， 直接实现流处理 ， 那么我们为什么需要日志？有三个方面原因：
每个数据集可以被多个需求方订阅
维护单个消费者消费数据的先后顺序
提供缓冲区 ， 让生产和消费的过程解耦
TheLambdaArchitectureNathanMarz基于以日志为中心的思想 ， 提出了LambdaArchitecture ， 来同时满足流处理和批处理需求 ， 如下图所示：
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
数据流同时被打向两个系统 ， 流处理系统和批处理系统 。 你需要分别在流处理系统和批处理系统实现两次相同的写入处理逻辑 ， 两个系统处理后写入最终向外提供查询接口的数据库中(可能是不同的数据库) 。 LambdaArchitecture的好处在于 ， 原始的输入数据会被原封不动地保留 ， 同时也为重处理(reprocessing)留下空间 ， 重处理是很重要的的功能 ， 逻辑会随着业务变化而变化 ， 这时候就需要对历史数据重处理 ， 解决存量问题 。
LambdaArchitecture的劣势在于需要维护两份类似的处理逻辑 ， 一份用于流处理 ， 一份用于批处理 。 当然也许你希望基于流处理和批处理再抽象出一层通用语言 ， 就能复用逻辑 。 但这并不现实 ， 即便是ORM的场景 ， 将不同关系型数据库的接口聚合 ， 都会遇到各种抽象泄漏的情况 ， 就更不用说这种底层差异更大的数据系统场景了 。
用流处理代替批处理如果我们能用流处理代替批处理 ， 就能让架构更加简洁 ， 设计更加统一 ， 开发者也无须维护两份相似的处理逻辑：
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
其实整个过程很简单：
使用类似Kafka的日志系统保存你需要重新处理的一段时间内的日志 ， 订阅者就可以从任意时间点开始重处理数据 。 假如你希望提供重处理最近30天数据的能力 ， 就将Kafka的留存策略设置成30天 。
当你想要重处理时 ， 启动一个新的job从头开始消费数据 ， 执行处理逻辑 ， 并将结果写出到新表(output_table_n+1)
当新的job处理完成或追上旧的job时 ， 就可以让应用从新的表中读取数据


推荐阅读


上一篇：国防时报排头兵|无人机出没！无人车穿梭！这场演练第一次见

下一篇：跨境电商小周|shopee不值的做？详细讲解，新手做跨境电商shopee的误区