京东大数据技术.docx
《京东大数据技术.docx》由会员分享，可在线阅读，更多相关《京东大数据技术.docx（25页珍藏版）》请在冰点文库上搜索。
京东大数据技术
京东大数据平台调研
1背景及意义
我国已将大数据发展确定为国家战略，强调要瞄准世界科技前沿，集中优势资源突破大数据核心技术，加快构建自主可控的大数据产业链、价值链和生态系统。
大数据产业在国内发展得如火如荼，据统计，到2022年将突破万亿元。
大数据技术已经在如电子商务、政务、民生、金融、工业、医疗等多个领域中广泛应用。
大数据正在从单纯的技术概念向实际部署应用转变；从少数领域向众多领域渗透；从企业内部向各产业与公共服务方向扩展。
目前，无论国内还是国外，大数据技术都在经历前所未有的快速演变，以满足各种应用的需求。
从国内的大数据技术和行业应用发展来看，大数据技术的基础架构技术已日趋成熟，大数据领域由技术创新驱动转向应用创新驱动的趋势开始显现，但更多的传统企业在如何建设大数据平台，如何利用大数据来驱动企业业务发展上仍然缺乏经验，这在一定程度上制约了大数据技术的大规模产业应用。
京东作为一家业内领先的互联网科技公司，完整的产业链条带来了价值可沽的海量大数据，丰富的业务场景也为技术发展提供了最佳创新土壤。
从认知、探索到今天京东技术上的百花齐放，京东经历了最为艰苦的创新和付出。
业务的复杂与多元化，数据的飞速增长，但也使得大数据平台拥有更强大的能力，形成了一套完整的技术体系和有效的数据管理方法，并在实践中得以验证和夯实。
京东拥有全渠道零售和端到端的高质量大数据，包含了用户的浏览和消费行为、商品制造和销售、物流仓储配送以及客服与售后等丰富完整的信息。
同时，京东业务中包含有大量丰富的大数据应用场景，是大数据实践的最佳场所。
早在2010年，京东集团就启动了大数据领域的研发和应用探索工作，经过八年来的持续投入，京东大数据平台无论从规模、技术先进性，还是体系的完整性等方面均已达到国内一流水平。
作为支撑公司数据运营的重要阵地，目前已拥有集群规模40000+服务器，数据规模达800PB+，每日的JOB数100万+，业务表900万+，每日的离线数据日处理量30PB+，单集群规模达到7000+台，实时计算每天消费的数据记录近万亿条。
京东大数据平台建设了完整的技术体系，包括离线计算、实时计算和机器学习平台，可以满足多种复杂应用场景的计算任务。
元数据管理、数据质量管理、任务调度、数据开发工具、流程中心等构成了全面的数据运营工具。
分析师、指南针等数据应用产品提供了便利的数据分析功能，以及敏感数据保护、数据权限控制等策略方案，能够最大程度地保护数据资产的安全。
京东大数据在驱动企业业务增长，提升运营效率，为客户提供个性化、高品质产品及服务上发挥了重要作用。
利用大数据分析和挖掘，京东打造了个性化商城，自主研发了智能门店解决方案，打造了智能供应链体系，提高了物流配送的效率，实现了知人、知货、知场景的购物体验。
京东大数据的应用已渗透到了业务的各个环节。
大数据平台的发展是随着京东业务同步发展的，由原来的传统数据仓库模式逐步演变为基于Hadoop的分布式计算架构，如图1所示。
技术领域覆盖Hadoop、Kubernetes、Spark、Hive、Alluxio、Presto、Hbase、Storm、Flink、Kafka等大数据全生态体系。
目前拥有研发团队500+人，累计获得技术专利400+个。
图1.1京东大数据发展历程
2京东大数据的技术体系
京东大数据平台构建了完整的技术体系，通过一系列的技术方法实现了更可靠、高可用、具有京东自身特色的平台环境。
如图2.1所示，平台覆盖Hadoop、Kubernetes、Spark、Hive、Alluxio、Presto、Hbase、Storm、Flink、Kafka等技术全栈，满足各类应用场景对数据平台的要求。
图2.1京东大数据平台系统架构
2.1数据采集和预处理
数据采集是大数据的基石。
京东包含了电商所涉及的营销、交易、仓储、配送、售后等环节，每个环节都会产生大量的业务数据，同时线上的业务日志系统和消息系统也会产生海量的数据。
为了将上述结构化和非结构化数据进行采集，以便后续被数据应用类系统所使用，京东搭建了一套标准化的数据采集系统—数据直通车。
数据直通车为京东线上数据接入京东数据仓库提供了一套完整解决方案，为后续的查询、分发、计算和分析提供数据基础。
直通车提供丰富多样、简单易用的数据采集功能，可满足离线计算、实时计算、集成分发等多种需求，并进行全程状态监控。
根据不同业务场景对于数据时效性的不同要求，直通车支持离线数据采集和实时数据采集两种数据采集方式。
离线数据采集主要支持的数据类型为：
MySQL、SQLServer、Oracle、MongoDB、HBase、ElasticSearch、离线文件；实时数据采集主要支持的数据类型为：
MySQL、日志、HTTPAPI、JMQ等，并支持API接口实现实时数据上报。
离线采集每天在零点后抽取前一天增量的数据（T+1），然后将T+1的数据与已有的全量数据合并形成新的全量数据，并将数据储存到目标表对应的分区中。
图2.2展现了离线数据采集的完整架构：
图2.2离散数据采集架构
数据直通车同样为实时数据采集提供了一套标准化的解决方案，实时数据采集目前支持MySQL、SQLServer、Oracle、JMQ、日志等多种数据源类型。
对于MySQL数据库，系统参照数据库的主从复制模式，通过把关系型数据库的Binlog日志实时抓取并解析发送到实时数据总线（JDQ）内。
实时采集按照数据库实例粒度抓取MySQL实例上的所有Binlog，在程序内部进行Binlog的实时解析并过滤出所需要的库表，再以表粒度发送到不同的Topic上，方便下游用户进行业务表粒度的实时处理。
JMQ是京东内部线上系统的消息中间件服务，很多业务数据在落数据库之前都会经过JMQ系统在不同的业务系统之间进行传递。
数据直通车可以把JMQ内的线上系统消息实时地同步到实时数据总线（JDQ）内，再由数据消费者按需处理，极大地提高了数据处理系统的服务能力。
京东内部所有系统的实时数据都会通过数据直通车实时采集到JDQ系统，统一由JDQ对下游业务需求提供实时数据消费服务。
该方案帮助业务用户在技术层面屏蔽了实时数据采集的复杂度，并使得系统能够提供稳定的服务能力。
2.2流量数据采集
目前京东拥有丰富的入口平台，包括PC上看到的网站，无线客户端上访问的H5页面，移动端应用，微信手机内的购物入口，京东自主研发或合作的智能设备，微信生态下的小程序，以及通过开普勒开放赋能给其他合作的APP等等。
多样的数据展示形式使得不同的访问入口每天都有大量的用户访问，流量数据采集成为了京东大数据的一个重要环节。
由于入口平台实现原理不同，数据采集的诉求也不同，包括针对不同的事件，不同的场景有着特定的采集诉求等，以下我们将开始介绍在京东流量数据采集的相关技术。
2.2.1浏览器页面的采集
（1）采集流程
浏览器的日志采集，主要包含两大类日志：
页面日志、点击及自定义日志，其中页面日志采集主要是指浏览器中页面被加载时的日志，而点击及自定义日志则是相关行为被触发后产生的日志，页面日志采集的流程如图2.3所示。
图2.3页面日志采集流程
页面日志采集主要包含以下几个环节：
1.日志采集。
网站的页面在上线前，会在页面内植入一段JS的采集脚本，当用户在访问网站的页面时，浏览器会进行加载、解析并执行JS脚本，JS脚本在执行过程中会收集当前页面的一些信息、浏览器环境的相关信息、用户访问上下文的信息（例如第几次访问网站，当前访问页面的上一页面信息等等）以及业务特性的相关数据。
2.日志上报。
JS脚本执行在执行完毕后，会将所有收集到的信息拼装到一个请求内，通过日志请求将数据发送到日志服务器。
一般情况下，在JS执行完成后就会立即向日志服务器发送。
3.日志接收。
日志接收服务器在接收到客户端发送来的日志请求后，会向浏览器返回一个请求成功的响应。
日志服务器在接收到上报的日志后，还会在服务器上执行业务定制的特殊处理，对日志进行过滤筛选，然后再将日志存储在本地磁盘或者发送至实时平台中，供下游使用。
4.日志存储。
目前采集到的日志通过两种方式进行存储：
离线和实时。
其中离线主要指服务器在接收到日志请求后，会将请求进行简单处理后落地到本地的磁盘中，然后通过日志抽取的方式将本地的日志及时抽取到相应的数据仓库中，实时则是将请求的消息体实时地分发到相应的实时处理平台中进行缓存，下游则根据该缓存的数据进行后续的应用。
5.日志解析。
下游业务在拿到原始日志后，结合自己的业务需求对数据进行过滤筛选，同时结合统计分析的需求对数据进行加工处理。
日志经过了以上的几个步骤后，我们就完成了用户的流量数据收集。
（2）页面日志
网页页面是网站最基本的载体，通过页面的形式将希望展示的内容呈现给用户。
为了更好地了解页面的访问情况，就需要我们采集页面的访问日志，有了页面日志后，我们可以统计分析页面的浏览量（pv）、页面的访客数（uv）、页面的加载时长、页面的停留时长等情况，也可以进行上下游的分析，访问用户的分析，为营销策略调整提供数据支撑。
页面日志主要是在用户访问页面的时候进行采集的，目前主要采集了页面的基本信息、页面上下文、页面业务信息、页面的其他基本信息。
1.点击及自定义日志
点击及自定义日志，主要用于收集用户在网站中除浏览以外的日志，主要包括交互日志、曝光日志、自定义日志等。
对于交互日志，例如用户通过鼠标的相关操作，移动、点击鼠标等操作与页面发生交互，页面会根据交互行为得到相应的结果，在用户触发这些交互行为时，会触发页面采集的脚本，从而将该部分交互日志采集到。
曝光日志则是根据用户访问页面后，页面自发展示的一些其他内容形式，例如弹窗、轮播图等等形式。
为了看到曝光之后用户对该内容的转化效果，就需要知道目前曝光的具体情况，例如在什么时间、曝光给了那些用户等等。
自定义日志则是根据业务特性定制的一些特殊日志，例如采集页面停留的位置，用户在页面中的访问路径等等。
点击及自定义日志的采集方法主要为用户特定标记的信息采集，即在网页上预设采集脚本，当该网页的某个位置被点击或自定义的行为被用户触发了，则会产生相应日志并上报给日志服务器。
随着触发条件被同时采集的还包括用户的基本信息、页面的基本信息、浏览器的基本信息，以及访问历史相关的信息等。
点击及自定义日志的采集，更好地还原了用户在网站页面中的访问情况。
有时为了更好地记录用户的访问行为，需要使用相应的标识用来做各种场景的区分，同时在采集代码植入时就标记下来，这样在用户的行为发生时，相应的日志就能够采集到更完善的信息，为我们后续的数据统计分析及业务应用提供了帮助。
2.移动设备日志采集
随着用户对移动设备的依赖越来越重，用户的访问也逐步向移动端迁移，移动端的数据采集也越来越重要。
目前移动设备基本以APP应用的方式进行对外应用，针对APP应用的数据采集，京东提供了自主研发的SDK工具。
该SDK可以收集用户在APP的各种事件行为数据，收集APP的性能日志，也支持研发采集一些自定义状态，自定义事件等场景的数据。
SDK被预置在APP应用内，用户在使用APP的过程中，如果触发了预先设计的场景，将会触发SDK的采集方法，进而生成相应的用户行为日志，并收集到APP应用内，并在合适的时机下上报的日志接收服务器。
3.页面标识
网站页面在浏览器内访问时，会有相应的页面链接，而用户在移动设备上访问时，由于移动端的特殊性，页面都是以接口的形式展示，但接口不直观，数据人员无法直接访问展示，直接判定该页面具体信息，因此需要针对页面接口进行重新标识。
京东提供了相应的管理界面，可以备注具体接口对应的别名信息，接口描述信息，业务可以快速地查阅和使用。
4.页面事件
用户在移动设备上留下各种事件行为，事件行为都是由后台实现的一些通用接口方法来实现，为了标识这些事件，并且以更简单易懂的信息来标识，我们提供了页面事件管理的功能，通过事件管理来标识具体的行为事件。
研发通过埋点开发，将这部分事件行为植入到对应的接口中，再通过SDK进行采集上报，就可以快速地标识出用户的事件数据。
5.特殊场景
电商行业包含了两大特殊的业务场景：
引流、跟单。
引流：
引流主要指的是广告渠道的引流效果跟踪，业务在站外投放广告，用户通过点击广告坑位进入网站，然后在网站中进行后续的访问，为了跟进各个广告位的流量进入及订单转化效果。
京东目前对站外广告渠道进行打标，在用户通过点击广告位跳转到京东后，来源的链接上会有相应的广告参数，再借助业务制定的广告覆盖规则更新广告渠道信息，而这部分广告渠道信息将会保持在后续访问的所有页面内，通过页面的广告渠道信息就可以统计分析出各个广告渠道的引流效果。
跟单：
跟单主要指的是订单来源的跟踪，跟单效果包含两大类，一个是站外的订单效果跟踪，一个是站内的订单效果跟踪。
其中站外跟单效果分析，由于页面中包含了广告渠道的信息，因此可以通过页面中包含广告参数信息来统计分析，站内活动或者坑位的引入效果没有标识，我们设定了相应的跟单逻辑，通过对应的跟单逻辑可以跟踪各个坑位的订单引入效果。
6.设备标识
目前移动设备可以通过MEID，IMEI，IMSI，MAC，以及苹果的UDID信息来识别，但是随着用户的自我保护意识加强，苹果系统禁用设备标识，Android新系统也对设备信息做了权限控制，用户的基本设备信息获取愈发困难，想要进行设备标识成为了一个需要攻克的难题。
为了更好地分析用户，识别一个用户的所有访问记录，将用户的画像信息描绘得更完善，就需要一个设备唯一标识。
京东通过移动设备相关的硬件信息，并结合一定的历史数据及算法，融合出自己的唯一标识JDID，通过该标识唯一标识一个设备。
7.H5与APP原生页
我们在访问一个APP设备时，通常会包含两种页面形式，一种是APP原生页，一种是H5页面，其中APP原生页的数据采集通过SDK的方式来采集，H5页面则是通过页面中的JS来进行采集，由于是在同一个APP内访问，业务人员通常希望将APP内的H5的数据算作APP的一部分，而由于采集方式的不同，数据需要进行统一，同时也需要相应的交互处理，即H5页面可以标识出来具体是在哪个APP应用内访问带来的。
8.日志采集控制
用户在移动设备上访问后，每个操作都会产生一个操作日志，但并不是每生成一条日志就实时上报至服务器，而是在产生日志后，先暂存在客户端本地，再结合着相应的上报控制策略进行数据上报。
其中上报策略主要指根据日志的业务特性，数据的时效性，用户的网络特性等等信息设定不同的上报策略，有些日志会因为其数据时效性的要求进行实时数据上报，而有些日志则会在用户启动应用，或者间隔一段时间后将日志上报上来。
9.客户端与服务器日志采集
除了浏览器和移动设备外，用户可能有自己的客户端或者服务端的日志需要进行采集，京东提供了相应的数据采集方案。
其中客户端也主要以服务器端方式进行日志采集，通过相应的接口调用，在后台组织好相应的日志形式，然后向日志接收服务器发送日志请求。
日志接收服务器则根据约定的协议判定该日志是否为合法日志，最终将业务日志落地到相应的服务器上。
2.3数据存储体系
2.3.1HDFS存储
JDHDFS是京东基于HDFS自研的大数据分布式存储平台,采用分布式存储技术，满足大数据高效可靠的存储需求，提供较高的持久性、较高的吞吐量和较低的延迟速度,具备高可用性和高可靠性的特点，容易扩展,并支持水平扩展至百PB级存储容量,同时拥有较高的硬件故障容忍能力,提供全面的安全性和多样化的权限功能。
相对于开源版本的HDFS，，JDHDFS主要改进的技术点如下：
（1）基于路由的Federation方案（Router-BasedFederation）
随着集群规模的增长，Namenode存储成为集群性能的关键瓶颈。
我们参考社区版本设计文档,研发功能模块RBF（Router-BasedFederation基于路由的Federation方案）,支持动态映射、嵌套映射等功能，可以解决hadoop集群无限横向扩展的规模问题。
（2）数据生命周期管理（DataLifecycleManagement）组件
基于数据生命周期管理的策略，该组件定期调度进行过期Job日志聚合目录app-logs、中间结果文件、Cgroups文件的清理以及固定周期小文件的整理合并。
（3）基于资源利用率的智能选块
改进后的Namenode节点可以实时感知集群所有Datanode的繁忙状态，根据CPU、内存、磁盘、网络的繁忙程度进行副本的位置选择，规避繁忙状态的Datanode节点，可以对整个集群的负载实时平衡。
（4）跨集群容灾
集群往往不在同一个数据中心，甚至是跨地域的。
集群间网络延迟较高，交换数据成本昂贵。
原有执行同步的方式会造成数据延迟。
我们基于集群数据同步方式代替distcp,同时做到数据低延迟访问,支持双主访问,降低额外物理资源冗余。
京东分布式存储采用将元数据集群与数据集群分离并可实现独立扩展，用户既可以通过扩展元数据集群获得更多文件管理的能力，又可通过扩展数据存储集群获得更大的聚合带宽与存储容量。
灵活、无缝、平滑的扩展方式可以为用户高效的计算环境提供坚实的数据保障。
图2.4展示JD-HDFS的技术架构。
图2.4JDHDFS技术架构
数据高可靠和平台高可用
平台可用性是最重要的指标之一，需要保证在机器发生故障时，系统可用性不受影响。
我们使用多副本策略，副本分布在不同的机器,机器故障引起某些副本失效时，其它副本仍然能提供服务。
平台允许对虚拟存储池中不同的目录设置不同的副本数，可手动设置1-4个文件副本,可保证数据在多块磁盘甚至单台服务器损坏的情况下存储系统的服务正常运转。
为了保证任何一台存储服务器失效或者是任何一块硬盘失效都不会影响数据的可靠性和一致性，使用pipeline机制保证数据写入顺序，所有的数据副本以及数据校验有严格写入顺序，如图2.5所示。
当正在进行数据写入的磁盘和存储服务器发生故障时，元数据服务器会为此数据对象分配新的空间，以继续进行数据写入，而之前在失效磁盘上写入的数据则会通过另一份数据副本恢复到相应的磁盘和存储服务器上。
图2.5JDHDFS存储架构图
集群水平扩展能力
存储平台中的元数据服务器和存储节点是拥有横向水平扩展能力。
存储节点扩展是存储节点数量的扩展，存储节点扩展带来容量上的增长。
扩展过程中无需中断存储系统上应用的运行，扩展的容量即插即用。
而且随着存储服务器数量的增多，整套存储平台的流量也会线性增长，成为核心存储集群之一。
元数据服务器的扩展带来的是文件数量存储能力的增长。
如图2.6所示，整个扩展过程对整个应用平台完全透明，扩展的元数据服务器即刻能够提供服务，前端应用无需进行任何配置。
随着元数据服务器数量的增多，整套集群存储系统所提供的元数据服务能力也会呈线性增长，能够管理的文件总个数也线性增加。
图2.6元数据服务器
2.3.2HBase存储
JDHBase是一个分布式存储系统，具有高效的实时读写性能。
可以支持每秒千万级数据记录写入和毫秒级的查询响应，当数据量达到PB级别，仍然保持高性能读写。
目前京东HBase集群规模5000多台，支持京东600多个业务系统，典型业务有：
Ø商城：
商品评价、会员PLUS、个性推荐、用户画像、POP订单、商家营销
Ø智能：
JIMI机器人、AI图片、图像识别、门禁刷脸
Ø金融：
风控、白条、支付、资管
Ø物流：
订单追踪、物流仓储、销量预测
Ø监控：
统一监控、服务器监控、容器监控、大数据监控、大屏监控
JDHBase集群的服务端（如图2.7所示）是京东HBase的核心，它保障了HBase集群的性能和稳定，并提供了安全认证、主备切换、分组隔离、SQL支持等重要功能。
JDHBase的客户端是京东HBase的重要支撑，所有业务程序都使用标准客户端来访问HBase集群，实现了用户身份认证、主备切换、实时监控等功能。
JDHBase服务中心实现了各集群之间的统筹管理，通过它我们可以控制业务数据在多个集群中的流向形成数据流向拓扑，方便地进行数据的迁移。
同时提供对业务端透明的主从、主主策略的动态变更。
图2.7JDHBase服务架构
京东HBase特点:
（1）4+1架构
针对京东的业务场景和使用方式，我们对JDHBase的使用方式做了很多思考与优化。
如图9所示，我们将整个JDHBase平台逻辑拆分成存储层、内核层、中间件层、用户层和一个辅助系统。
底层部署上我们支持将HDFS和HBase分开部署，同时可以利用容器技术快速扩容和创建新的HBase集群。
满足各种场景的读写需求。
在HBase内核部分我们通过修改源码让HBaseRegionServer能够识别运行的硬件类型并根据其预设值自适应到最佳性能状态，支持多种硬件混合部署集群。
在中间件部分我们通过接口服务的方式向外围系统提供支持，如主备容灾、数据治理服务、集群分组管理服务、权限管控服务、配额&限速管理服务，多语言支持组件等。
在用户层我们向最终用户提供多种可选的数据加载方式和查询引擎满足不同业务场景和需求。
图2.8JDHbase技术架构
多活灾备
为了满足业务对JDHBase读写的实时性要求和数据安全性的要求，京东团队自主研发了一套基于策略的多集群切换机制。
在集群拓扑上每个集群都会有备份集群来保证跨机房的数据备份。
从安全维度上我们分别做到了集群级、namespace、表级的支持，可以针对每个级别设置不同的容灾切换策略，如手动、自动、强制等。
通过这种方式我们可以随时调整策略将部分业务分批、分级切换，如隔离、降级、防雪崩等场景。
多集群切换机制的主要工作组件由服务中心、HBasePolicyServer、客户端三部分构成：
客户端会定期以心跳的方式访问HBasePolicyServer获取所操作对象的集群服务信息和切换策略信息，当发现主集群信息改变之后客户端会根据切换策略进入切换流程。
PolicyServer是对外提供查询和修改策略的服务，它所有策略数据会存储在MySQL中，可以通过加节点的方式动态扩展形成一个服务集群，避免单点问题。
ServiceCenter提供一个界面化的多集群管理服务工具供管理员使用。
在极端情况下，如果主集群彻底瘫痪，我们可以通过强制切换的方式把所有业务快速切换到从集群。
同时触发主备数据同步校验机制，后台会自动在主集群状态恢复后将校验主从集群的数据一致性并同步数据，保证数据安全性。
HBase默认的使用方式是一个业务一个集群，资源利用率低，维护成本高。
也可以多个业务共用一个集群，但是会有资源竞争和故障扩散等问题。
例如，一个业务出现异常可能会影响整个集群的可用性。
基于以上的原因，我们引入了HBase2.0的rs分组功能（目前官方仍然是beta版）并进行了改进完善，实现了将HBase集群动态切分成多个分组，每个分组中有多台物理服务器
这样既能将业务进行物理隔离防止资源竞争和故障扩散，还能在618和11.11大促时期动态调整集群资源，提升硬件资源利用率。
2.4离线计算环境
大数据离线计算为多种应用场景提供基础计算功能，其特点为：
（1）数据量巨大且保存时间长；
（2）在大量数据上进行复杂的批量运算，能够方便地查询
升级会员 