QCon2019大数据平台架构相关总结

1. 快手万亿级别Kafka集群应用实践与技术演进

应用实践

快手对Kafka的三个重要应用场景:

  • 在线集群:在线服务消息中间件
  • Log集群:业务系统日志收集和传输的缓存介质,之后面向重要的实时消费和数据处理
  • 离线集群:是所有各种日志的最终汇聚点,一方面落地到数仓;另一方面面向次重要的实时消费和数据处理

业务场景架构如下:

kuaishou-kafka-1

其中,通过Mirror Service将多个在线集群和Log集群中数据汇总到离线集群

技术演进

对kafka的使用做了如下优化:

优化一:kafka集群平滑扩容优化,解决了扩容节点时导致kafka集群物理资源大量消耗,影响producer写入
  • 问题:社区kafka对partition的迁移是从最初的offset开始的,触发读盘,物理资源大量消耗 => produce延迟增高且 抖动;扩容不平滑
  • 优化思路:从最新offset开始迁移,并同步一定时间,保障所有consumer都已经跟上(据说这一改进已经向社区提交了issues
优化二:Mirror集群化建设,摒弃了Apache Kafka的Mirrormaker,基于uReplicator做了改进
  • 问题:Apache Kafka的Mirrormaker是静态管理,运维成本高,易出错;当增加topic或集群时导致正在运行的数据Mirror整体断流
  • 优化思路:基于uber的UReplicator做了改进,通过Mirror服务集群化管理,可减低运维,避免出错,支持快速调整,应对突增流量
优化三:资源隔离,将不同业务线的topic进行物理隔离,保证互不影响
  • 问题1:不同业务线topic缺少物理隔离,会相互影响
  • 优化思路:根据不同的业务做到Broker级别物理隔离
  • 问题2:Kafka Rpc队列缺少隔离,一旦某个topic处理慢,会导致所有请求hang住
  • 优化思路:多RPC队列,进行隔离
优化四:对PageCache的改造,避免Consumer的lag读和Follower进行replica时可能产生的PageCache污染
  • 问题:Kafka高性能依赖page cache,但page cache不可控(由操作系统管理),可能会被污染
  • 优化思路:让kafka自己维护数据cache,严格按照时间顺序cache,并控制follower的数据不进入cache
优化五:消费智能限速,解决了某个Consumer lag延迟后读盘导致的producer写入受阻的问题
  • 问题:某个Consumer lag延迟后读盘导致的producer写入受阻
  • 思路:当磁盘繁忙,针对lag的consumer进行限速控制

总结

从应用实践中了解了kafka的三个重要应用场景,并对多kafka集群的Mirror Service有了新的认识,之后可以对uReplicator进行一些调研,看是否可应用到跨kafka集群的数据同步中。

从技术演进中也就收获了一些kafka使用中可能遇到的问题和优化思路,看似思路都很简单,但是真正实施起来难度还是相当大的。

2. 滴滴大数据研发平台最佳实践

简介

大数据研发平台设计的初衷是:设计一个平台满足所有数据开发人员的数据分析、数据加工、模型训练等工作,同时做到数据安全的使用和管理,以及统一式的开发和运维,开发人员只关心自己的业务,不需要过多的底层。

整个功能类似阿里的DataWorks。

整体架构如下:

didi-bigdata-platform-1
didi-bigdata-platform-2

主要工作

工作一:开发与生产隔离

由于大数据开发的特殊性,经常会基于线上已有表的数据进行开发测试,这样就难免对线上的任务和数据有影响。

解决这一问题的思路就是将开发和生产进行逻辑上的隔离,开发环境里允许对线上数据进行查询,但是结果落地时,写入的是测试的库,避免对线上库和表造成污染,待真正上线时,将发布包提交到生产环境,数据才会写入线上的库。

这一点可以借鉴,但是需要平台化的管理,这块我们还是比较欠缺。

工作二:统一的任务执行平台

其实也是个逻辑的东西,将底层的执行引擎透明化,用一个统一的任务执行平台进行管理,在这个平台上可以提交离线任务、实时任务、机器学习、提数、特征分析等多种任务,任务在真正执行时是根据任务的具体类型来提交到不同的处理引擎上的。

主要工作还是上层的抽象和封装。

didi-bigdata-platform-3

工作三:实时表元数据化

要实现开发实时就写SQL一样简单,首先要实现的就是实时表元数据化。

其实Flink SQL已经实现了这种的写SQL来完成实时数据的处理,但是在开发时需要人为的创建表的Schema。

他们做的工作就是提前将用到的各种实时表元数据化,用户在开发时只需要指定某个具体的表就可以实现实时任务的开发,不需要关心元数据是否创建。

工作四:基于列进行权限管理

这部分工作还是为数据安全来考虑的,向手机号、身份证等敏感信息,不应该向所有大数据开发人员可见,如何做到列基本的权限管理呢,这是这部分工作的初衷。

我们其实已经基于Hue和Sentry有了对表级别的权限做了管控,但是在字段级别还没有好的解决思路。

他们的实现方案:

  • 划分列的安全等级,1,2,3,4
  • 为列进行等级打标
  • 借助自研的安全管家服务,为用户实现授权
  • 底层基于Apache Ranger实现,安全管家会生成安全策略和授权传递给ranger

didi-bigdata-platform-4

总结

这种平台化的东西也只有那些大厂才有能力和资源来做,也就收获了一些实现思路,具体怎么应用到我们的工作中,还需要很多路要走。

3. 苏宁OLAP引擎发展之路

没get到太多干货,讲的最多的就是对查询引擎SparkSQL的进行了一些优化。

主要包括:

  • Spark-HDFS
  • Spark-Druid
  • ES-Hadoop
  • PG-Spark-JDBC

优化思路就是将查询SQL谓词下推,要充分利用各存储自身的查询性能,尽量避免把数据全部拉到集群中进行计算。

suning-olap-1

其OLAP整体架构:

suning-olap-2

数据中台架构:

suning-olap-3

4. ClickHouse在头条的技术演进

主要从两个部分进行介绍,一是头条为什么选择了ClickHouse及如何使用的,二是主要做了哪些优化

由于自己对ClickHouse没做过多了解,第二部分优化没get到什么。

简介

ClickHouse 2016年开源的,由俄罗斯IT公司Yandex开发,是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS),而且查询性能优越。

主要特点:

  • 面向列+向量执行
  • 自己管理存储(非Hadoop)
  • 线性可扩展,高可靠(通过shard+replication实现)
  • 面向SQL查询

性能优越的原因:

  • Data Skipping
    • 分区及分区剪枝
    • 数据局部有序,类似LSM树的查询引擎
  • 资源垂直整合
    • 并发MPP+SMP架构
    • 执行层是SIMD实现(单指令多数据流)
  • 底层C++实现

使用的场景:

  • 单表分析,这个表可以很宽
  • 分布式Join性能并不出色

不足:

  • 没有事务
  • 批量数据接收
  • update or delete支持较弱
  • 查询重写优化较弱
应用

头条选择ClickHouse的原因:

  • 产品需求
    • 交互式分析能力(in seconds)
    • 查询模式多变
    • 以大宽表为主
    • 数据量大
  • 开源MPP OLAP引擎 - (性能、特点、优质)

在头条的应用:

toutiao-clickhouse-1

总结

目前ClickHouse商业应用还较少,只有部分大厂有使用,而且他们在使用过程中如果遇到一些问题,自己有能力和资源进行二研优化;更主要的是ClickHouse不理睬Hadoop生态,走自己的路。我们暂且了解观望。

5. 美团点评常态、异地、多机房、单集群Hadoop架构实践

原生Hadoop在跨机房,跨地域进行搭建时,网络的延迟会大大影响hadoop的管理和任务处理性能。

但是有时候随着业务发展,集群节点越来越多,同地域的机房没办法承载,但是又不想搭建多个hadoop集群,此时就需要搭建这种跨机房、跨地域的hadoop集群了。

美团通过二研实现了单集群异地多机房Hadoop服务,并且保证了管理和任务处理的性能,实现了架构前向兼容,机房对业务透明。

整体思路,通过优化Hadoop,使得其有对地区的感知,尽量避免跨机房流量

实现

第一步:多机房Hadoop资源管理
  1. 多机房存储资源管理
  • NameNode机房感知中增加了对地区的感知
  • NameNode副本分布属性增加了地区的支持
  • HDFS读写响应:保证吞吐,避免跨机房流量(仅向默认机房写⼊,就近读取)
  • 具备初级多机房存储资源管理理能⼒
  1. 多机房计算调度
  • 基于Label Scheduler的多机房计算资源调度,即在提交作业时附加上机房的标签,禁⽌止跨机房作业调度
  • 基于YARN Federation的跨地域计算资源调度,优先请求本地机房
第二步:多机房Hadoop资源管理
  1. 跨机房数据Cache处理,就是基于数据⾎血缘产⽣和读写规律进行构建副本cache的规则(在本地机房冗余一些数据,减少重复跨机房的数据读取)
  2. 带宽管控,充分利用好带宽
第三步:HDFS机房容错
  1. HDFS分区容忍设计粒度为节点级别,而不在是块级别
  2. 实现机房、机架粒度容错,保证网络故障时,DataNode没有故障,数据没有丢失

总结

收获了一些解决这样问题的思路,具体是否值得实现还得看业务。
技术换运营,站在平台运营视⻆角进行架构设计,才能保证架构平稳落地。

6. 阿里巴巴新一代交互式分析引擎-Hologres

主要介绍了Hologres是啥,其设计理念是啥,性能有多么优越。。。

Hologres是啥?

  • 新一代海量数据交互式分析引擎
  • 一套引擎支持Point Query(hbase场景),Ad-hoc Query(Druid场景),
    OLAP Query(Impala场景)
  • 快。。
  • 存储计算分离
  • 支持实时数据与批量数据导入
  • 支持External Storage,与阿里云大数据产品无缝对接

亮点&理念?

  • 统一的引擎架构,保证数据的一致性
    • 解决数据在Hbase存一份、Druid存一份、xxx存一份造成的浪费和数据不一致
  • 存储和计算分离
    • 据说新的NVME SSD盘可以达到150000IOPS,磁盘IO不再是性能瓶颈,问题转变为如何把CPU高效利用起来
    • 存储计算分离是未来大势所趋,存储和计算非对齐采购,成本更低,部署运维更方便
  • 更加聪明的Optimizer
  • 使用新技术
    • 近几年硬件性能提升的很快,N年前的技术方案不一定能够很好的利用现在的硬件性能发挥到极致
    • 使用全异步架构,把CPU利用到极致
  • 向量化计算

具体架构就略了,目前还在开发迭代中,后期在看。

整体get到的点可能就是:在未来的某一天磁盘IO不再是性能瓶颈,它可能比CPU处理更快,到时候现在已有的操作系统可能就需要重新设计。

注:

对相关内容感兴趣的可以下载各分享PPT

© 2019 GuoYL's Notes All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero