乳胶片解读京东数字化
京东作为一家业内领先的互联网科技公司，完整的产业链条带来了价值可沽的海量大数据，丰富的业务场景也为技术发展提供了最佳创新土壤。京东技术形成了一套完整的技术体系和有效的数据管理方法，并在实践中得以验证和夯实。 一、京东大数据
目前京东已拥有集规模 40000+服务器，数据规模达800PB+，每日的JOB数100万+，业务表900万+，每日的离线数据日处理量30PB+，单集规模达到7000+台，实时计算每天消费的数据记录近万亿条。
京东大数据建设了全生态核心产品体系，涵盖数据采集、存储、加工、分析、可视化、机器学习等专业化产品和服务，在保障数据安全的前提下，提供更可靠、高性能的服务，大幅降低大数据使用门槛，帮助京东大数据业务快速落地，助力京东实践以数据为驱动的业务变革与发展。
（一）大数据平台技术架构
上图为大数据平台技术架构，分散在四处的线上系统数据（多为结构化的业务数据），或者是各种日志文件、文档、图片、音频、视频等非结构化数据，需要进行采集。我们分别借助实时和离线的数据处理平台，将数据抽取至实时数据仓库和离线仓库，然后借助平台内的工具对数据进行加工处理，同时辅以各种平台产品对数据进行统一管理、监控、处理、查询、分析等， 并结合具体的业务需求，形成相应的数据应用产品。 1、数据采集
目前京东的数据采集方案主要分为两大类：用户行为日志采集方案（点击流系统）和通用数据采集方案（数据直通车）。低频放大器
plc一体机浏览器端的日志采集。①日志采集。浏览器的日志采集方式，首先需要在统计页面日志的页面中预先植入一段JavaScript 脚本，当页面被浏览器加载时，会执行该脚本。脚本中预设了一些采集需求， 包括收集页面信息、访问信息（访次、上下文）、业务信息、运行环境信息（浏览器信息、访问时间、访问地址）等信息。日志采集脚本在被执行后，会向服务器端发送一条HTTPS 的请求，请求内容包含了收集到的日志信息。②服务器日志接收。日志服务器在成功接收到浏览器发送的日志请求后，立刻向浏览器发送一个请求成功的响应，日志请求的响应不影响页面的加载。日志服务器在接收到日志请求后，会对日志请求进行分析处理，包括判断其是否为爬虫、是否为刷流量行为、是否为恶意流量、是否为正常的日志请求等，对日志请求进行屏蔽和过滤，以免对下游解析和应用造成影响。③日志存储。服务器接收到日志请求后，会依据请求的内容及约定的格式对其进行格式化落地。例如，当前页面、上一页面、业务信息、浏览器等信息以特定的字段标识，字段之间使用特定的分隔符，整条日志以特定的格式记录下来。结合业务的时效性需求，将日志分发到实时平台或者落地成离线文件。
七芯电缆
移动设备的日志采集。移动设备的页面有别于浏览器页面，移动设备主要为原生页 组成的App 应用，原生页使用原生预研开发完成。例如Android 系统使用Java 语言，iOS 系统使用Objective-C 原生语言开发，原生页运行速度快，效率高。①采集方式。移动设备上App 应用的数据采集主要使用的是SDK 工具，App 应用在发版前将SDK 工具集成进来，设定不同的事件行为场景，当用户触发相应的场景时，则会执行SDK 相应的脚本，采集对应的行为日志。②日志存储。用户的各种场景都会产生日志，为了减少用户的流量损耗，我们将日志先在客户端进行缓存，并对数据进行聚合，在适当时机对数据进行加密和压缩后上报至日志服务器，同时由于数据的聚合和压缩也可以减少对服务器的请求情况。
数据直通车。数据直通车为京东线上数据提供接入京东数据仓库的完整解决方案，为后续的查询、分发、计算和分析提供数据基础。直通车提供丰富多样、简单易用的数据处理功能，可满足离线接入、实时计算、集成分发等多种需求，并进行全程状态监控。图所示的数据直通车接入数据类型，根据抽取的数据量及抽取对线上的影响，会分为定时的离线接入和实时接入两种抽取方式。每种抽取方式支持不同的数据类型，每天在零点后可以获取前一天完整的数据，然后将一整天的数据进行集中加工处理，并将数据最终储存到目标表对应的分区中。
2. 数据处理
● 实时平台。业务数据处理的需求已经逐渐从离线转向了实时，在电商的应用场景中， 越来越多的需求更加倚重实时数据的处理和分析，越来越多的面向用户和商家的业务场景开始尝试实时技术带来的收益。京东实时技术平台协助业务更快地帮助用户发现自己想要的商品（推荐搜索），帮助商家更快地制订销售策略（实时数据分析报表）提供了强有力的支撑。
京东实时数据平台一共包括三大部分：实时数据接入（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 的基础之上， 我们封装了权限、限速、监控报警等一系列服务。针对重要业务进行了双机房读写
分离的部署方案，大大提高了消息服务的可靠性和服务能力。生产日志系统向最近机房内的JDQ 系统的写Topic 发送业务日志消息，如遇机房故障，自动切换到可用机房的服务。JDQ 系统通过实时同步不同写集数据到每个机房的读集，实现每个机房都有一份完整的业务日志数据可供业务研发消费。业务研发就近机房选择读集进行消费，同时通过JDQ 可以实现不同用户的消费限速， 最大限度地保证集服务的稳定可靠。JDQ 实时数据总线服务作为实时数据的中转缓存服务，屏蔽了业务研发对不同数据源的接入难度，同时通过一系列的数据格式使用方式的标准化，打通了实时数据从接入到业务处理的传输环节，实现了京东内部实时数据通道的目标。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议