加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

从京东618数据井喷看大数据平台峰值处理制胜关键

发布时间:2018-09-15 07:53:38 所属栏目:教程 来源:博文视点
导读:9月15日技术沙龙 | 与东华软件、AWS、京东金融、饿了么四位大咖探讨精准运维! 一、大数据综述 随着DT(数据技术)时代的到来,人们能比以往更容易地获取更丰富的数据。数据作为一种新的能源形式,正在源源不断地发挥其巨大的价值,帮助我们激发更多的技术驱

京东实时数据平台一共包括三大部分:实时数据接入(MAGPIE),实时数据传输(JDQ)和实时数据计算(JRC)。

从京东618数据井喷看大数据平台峰值处理制胜关键

京东实时数据平台

下面就实时数据处理分析在京东的技术流程进行阐述:

实时数据接入

实时数据的源头是各个线上业务系统的各种类型数据源,在京东内部主要包括三个部门:

  • 线上业务系统数据库:MySQL、SQL Server、Oracle。目前京东内部线上系统基本都已经切换MySQL。实时数据接入系统Magpie完全支持上述三个关系型数据库的数据实时接入,原理为数据库的主从复制模式,通过伪装从库的方式,把关系型数据库的Binlog日志实时抓取并解析发送到JDQ内。对于MySQL数据库,实时接入程序按照服务粒度抓取MySQL单服务上的所有Binlog,在程序内部进行Binlog的实时解析并过滤出所需要的库表,再发送到表粒度的Topic上,方便下游用户进行业务表粒度的实时处理。
  • 线上业务日志系统:统一流量(用户浏览点击日志),统一日志(各业务系统服务日志)。业务日志由线上系统先发送到JDQ的写集群,再由Magpie任务实时同步到JDQ的读集群。通过这种方式做到了日志数据的读写分离,极大地提高了系统稳定性和服务能力。
  • 线上消息系统:JMQ。JMQ是京东内部线上系统的消息中间件服务,很多业务数据在落数据库之前都会经过JMQ系统在不同业务系统之间进行传递。Magpie同样可以把JMQ内的线上系统消息实时地同步到JDQ内,再面向数据处理用户进行消费,极大地提高了数据处理系统的服务能力。

京东内部所有系统的实时数据都会经过Magpie系统进行接入和转发到JDQ系统,统一由JDQ对数据处理的业务需求提供消息服务。该方案帮助业务用户在技术层面屏蔽了接入的复杂度问题,并把服务稳定性和能力提高到了大数据实时处理的要求。

实时数据总线

实时数据在由Magpie进行统一接入处理后,需要一个面向业务研发用户的消息消费服务。我们基于Kafka的JDQ服务就是满足这个需求的产品。

从京东618数据井喷看大数据平台峰值处理制胜关键

实时数据总线

在原生Kafka的基础上,我们封装了权限、限速、监控报警等一系列服务。针对重要业务进行了双机房读写分离的部署方案,大大提高了消息服务的可靠性和服务能力。618当天日生产291TB、8000亿行数据,日消费1000TB。各个系统越来越重视通过日志进行数据分析,每次618的业务日志量均以150%的速度增长。

生产日志系统向最近机房内的JDQ系统的写Topic发送业务日志消息,如遇机房故障,自动切换到可用机房的服务。

JDQ系统通过实时同步不同写集群数据到每个机房的读集群,实现每个机房都有一份完整的业务日志数据可供业务研发消费。

业务研发就近机房选择读集群进行消费,同时通过JDQ可以实现不同用户的消费限速,最大限度地保证集群服务的稳定可靠。

JDQ实时数据总线服务作为实时数据的中转缓存服务,屏蔽了业务研发对不同数据源的接入难度,同时通过一系列的数据格式使用方式的标准化,打通了实时数据从接入到业务处理的传输环节,实现了京东内部实时数据通道的目标。

实时数据计算

实时数据要想体现业务价值,最终还需要业务研发方进行计算和分析。京东内部主流的实时计算平台是JRC计算平台,该平台脱胎于早期的Storm版本,由平台研发进行了深度的改造和产品化,实现了业务研发用户完全的Web产品任务管理和监控的需求,同时整合了JDQ数据来源,实现了用户在数据计算平台的无缝对接实时数据。本次618达到1.1万亿次日处理次数。

2017年618,JRC基于容器的新架构已经开始支撑部分线上业务,未来容器化的JRC方案会进一步提高Storm平台的稳定性和资源利用率。JRC架构图如图:

从京东618数据井喷看大数据平台峰值处理制胜关键

该方案的特点如下:

  • 通过Kubernetes实现Topology执行节点的容器化,资源随用随申请,提高资源利用率。
  • 通过Kubernetes和二级调度的方案,把Topology调度逻辑放在Kubernetes层面和Topology内部,提高了调度的效率,避免了不同Topology之间的干扰。
  • 心跳只在Timbus和Topology Master以及Topology Master和Worker之间进行,避免了传统方案任务量大时的心跳压力。

由于实时计算的场景多样,针对不同场景业内提出了多个流行的计算框架。目前京东内部实时计算的场景也趋于多样,我们平台已经开始在线上正式提供Spark Streaming和Flink等多种计算框架的产品化服务。

由于实时计算程序必须由程序代码进行开发,对于传统离线业务,SQL研发人员进行离线需求转实时还有较高的门槛,我们平台正在进行SQL形式和拖曳形式的实时计算产品化研发工作。该方案上线后,将进一步帮助业务方把离线数据处理需求转移到实时数据处理上,帮助京东的业务更快速地服务于广大的用户和商家。

目前京东实时数据解决方案整套流程已经接入了线上的上千张业务表数据流和数百个业务日志数据流,覆盖京东内部所有核心业务系统和大部分实时处理业务,主要面向京东内部各个业务部门的个性化推荐、秒杀、实时运营、商家报表等。未来,离线数据处理需求会越来越多地迁移到实时数据处理上。

离线平台

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读