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

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

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

实时数据接入

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

• 线上业务系统数据库：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服务就是满足这个需求的产品。

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

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

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

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

（编辑：惠州站长网）

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