京东大数据产品

京东大数据产品

      对于刚刚成长起来的京东大数据平台来说，数据产品并不是一个新鲜事物，2011 年自建数据仓库上线的同时，第一款数据产品调度平台也一同上线并正式投入使用。在Tiger 的指导下，调度平台无论是UI、功能还是用户体验各方面都获得一致的好评。

调度平台

      订单交易，仓储物流等众多京东系统都会产生数据，仅日志内容每天的大小约为1TB，大量的数据如何统一汇总到数据仓库来呢？这就需要调度产品来实现 数据生产。京东调度平台发展至今已经是3.0 版本，每一次的更新迭代都凝聚着阿敏等几位开发工程师的许许多多个日夜的心血，也是我们技术突破与功能升级的具体体现。

      1.0 版本于2011 年8 月上线，一台服务器作为中心节点指挥调度，另外3 台服务器负责相关数据作业，任务之间通过后置变量的方式设定前后依赖关系，调度机制便运行起来了。数据仓库建立之初的任务并不太多，数据量没有太过庞大， 数据ETL 过程所需计算资源也都完全应付得来。但随着仓库收纳数据的增加，数据生产任务越来越多，任务之间的依赖关系也变得越来越复杂。每个BI 工程师需要根据自己的生产任务设定后置变量的值以建立任务依赖关系，任务多了之后不但设置起来耗时费力且不易管理，当一个人的任务需要重跑时后置变量的修 改可能会影响到别人的任务。

      2.0 版本上线了新的调度引擎，彻底解决了这个问题。新任务上线只需要选择依赖的父任务即可建立关系，且流程独立，不会因同一个任务被多个依赖而造成干扰。除此 之外，任务可视化配置与浏览功能也在这个版本上线，任务运行状态监控预警功能也投入使用。这之后的功能升级也一直在进行，较大的功能改进莫过于虚拟节点 了。数据生产过程中，尽管几率很低，但仍然还是会出现一些物理节点挂掉的情况，而这种情况一旦出现，影响将会很严重。于是，虚拟节点的功能应运而生，原理 就是在原来的物理机集群上做一层虚拟化，如果遇到生产节点故障的情况自动切换到另一个节点。同时，根据不同节点的负荷，将新的任务自动分配到负荷较小的节 点，做到负载均衡。这一系列功能的上线使得平台的稳定性大大提高。

      3.0 版本从功能上更加丰富，并且实现了数据生产的半自动化运行机制。所谓的半自动化是指数据任务可在配置目标数据库、表之后自动生成ETL 模板并完成数据清洗，之后是人工创建调度任务完成数据生产。另外，自主研发的抽数模块Plumber 也在这个版本中上线，Plumber 技术实现了异构数据库之间的快速数据交换，且具有较高的稳定性，数据导入导出的维护成本也大大降低。还有服务器运行状态的监控系统Phenix 也集成到了调度监控中，实时采集服务器运行状态数据并对服务器心跳、存储空间使用、CPU 资源消耗等进行预警。对于上游系统故障造成的历史数据补充问题，之前的版本中需要人工查找相关依赖任务，然后一个一个配置参数后点击重跑，而在新的版本中 BI 工程师们期待已久的一键重跑功能上线了，并且支持批量操作一千多个重跑任务，BI 工程师加班到半夜一个一个点鼠标的日子永远成为了过去。

      作为大数据平台的核心系统，调度平台不仅承担着数据生产的重要使命，同时也负责集市数据推送、模型数据加工等任务，部门有超过1/3 的人都在围着它转，重要性可想而知。今后的功能升级迭代将在增强生产能力的同时更加注重自动化服务及开放运营等平台产品的特性，为大数据管理及挖掘大数据 价值提供可靠保障。

数据集成开发平台

      数据集成开发平台是京东大数据发展的一个里程碑产品，它的出现结束了数据分析师和业务部门数据需求人员通过客户端工具手工提取数据的痛苦经历，并对后来的数据知识管理平台等产品的出现产生直接影响。当前平台用户接近1000人，数据订阅任务总量逾40000 个。

      早期版本的数据集成开发平台就命名为提数工具，提数也是当时寄予这款产品的最重要的期望。相信每一家公司对于数据的需求都是“刚需”，快速发展的京 东，流动并且快速流动的数据更是像一个人身体里的血液一样不可或缺。毫无疑问，数据提取的任务由数据部来承担，无论是拆分状态时还是合并一体时的数据部， 数据分析师总是最繁忙的，每到月初需要支持财务经营分析的人员提取数据时，还要拉上不少工程师共同参与这场提数大战。前后台数据部拆分状态时的最后几个月 里，财务经营分析的数据提取任务几乎被平均的分到了这两个部门，每到月初，提数情况便成了两个部门最直接的竞争内容，完成得不错的话业务方可能会发个感谢 信，当然，就算不提出批评，完成的不好的部门也会觉得很没面子。前后台数据部合并后最疯狂日子里，数据部实行“全员提数”，业务方通过公司的服务管理平台 发起数据提取需求，部门内几名负责人会将需求分配给不同的人来处理。一段时间内，数据提取的数量和难易度甚至与绩效考核挂钩，提数，成了大家工作中非常重 要的一部分。

      正是在这样的背景下，数据集成开发平台的1.0 版本诞生了。这是一款查询数据并且支持周期性数据订阅的产品，同时打通了京东私有云服务Jbox，可以供已授权人员安全、便捷的查询和提取数据，尤其对于 需要定期提取大量数据做分析的人员（如财务经营分析同事）有很大帮助。功能上来讲，通过Web 端在线数据查询和数据订阅是两大主要功能，同时，SQL 编写界面还支持元数据信息的查看，并且可以在线保存编辑中的代码，这给提数人员带来很大便利。底层接入的数据库包括当时存在的SQL Server、MySQL 和Hive，SQL 语法上根据不同的数据库类型选择不同的语法即可，其他执行逻辑都是一样的。产品开发主要由彦伟团队负责，从初期版本上线到后期功能升级，Tiger 也给出了很多极具参考价值的意见，不断完善的产品吸引了大量用户的注册使用。

      同样采用Extjs 的前端页面偶尔存在一些滚动条失灵的小Bug，这给用户体验上带来一定影响。另外，虽然Extjs 强大的表单功能成就了集成开发平台这样的富客户端应用，但是其UI 风格的局限性也是非常明显的。随着后期产品线的丰富，新推出的产品已经弃用Extjs，转而采用Bootstrap 前端，于是在2014 年7月，采用新的前端技术，数据集成开发平台与后期推出的数据知识管理及数据质量监控产品融合后统一在一个系统上线。

数据知识管理平台

      数据知识管理平台产品的出现是个水到渠成的结果，在数据仓库模型规范确定之后，元数据信息也有了标准的分类体系。按照标准的分类体系将元数据信息分 门别类管理起来，同时提供内容搜索、类Wiki 的编辑维护以及咨询评论功能，数据知识管理平台就呈现在大家面前了。后期版本升级过程中又提供了维度表的维护功能，给模型开发维护的同事带来很大便利。

京东分析师

      Apricot（杏子）、Blueberry（蓝莓）、Cloudberry（云莓），水果连连看？不，这是报表展现平台三个版本命名的代号，也是 产品域名的首段字符串，首字母分别是ABC 也代表了产品演进的过程。当前版本代号为Cloudberry，产品正式名称为京东分析师，毫无疑问，我们赋予这款产品的除了基本的数据可视化能力，还有 数据分析的能力。体验过Tableau 的用户都会被其灵活的控制台和美妙绝伦的图表展现所征服。我们所做的就是在Web 系统中尽可能的实现Tableau 桌面系统所能达到的效果，并且在产品服务能力上更加强调自助服务的智能软件分析平台。

      技术架构上，京东分析师前端自主开发可自定义的展现布局，封装了丰富的图表展现组件，后端报表配置系统支持MySQL、SQL Server、Oracle、API 及Hive等作为数据源，并支持在线接入。交互方面，报表收藏、基于图表的条件过滤、数据排序、深度钻取是其基本功能，自定义报表页面还提供邮件推送报表 的功能，当某个报表数据比较重要，系统可通过邮件的形式定期发送报表供查阅。对于自己权限范围内可浏览的表，系统还可根据浏览记录将经常查看的表排在靠前 的位置以提升体验。

数据挖掘平台

      大数据的数据挖掘与传统意义上的处理方法存在很大区别，京东数据挖掘平台产品定位于构建一站式的数据挖掘算法平台，在基础的机器学习算法之上，可根 据具体实际业务开发订制算法，满足算法应用场景。这一产品主要利用分布式计算，采取适用于机器学习算法的计算模型进行迭代，以解决大数据量的算法处理问 题。平台封装的Cross Validation（交叉检验）、Grid Search（网格搜索）等基本数据挖掘流程给数据挖掘人员提供简单、易用的挖掘工具。

      为减少数据实体化的开销，挖掘平台采用基于内存的存储引擎，集群资源调度与管理基于Hadoop Yarn 框架，保证了集群计算性能的高可利用性和高可扩展性。平台自2014 年年中正式推出后，已经开始为广告系统、推荐系统等提供个性化的数据挖掘算法服务。

数据质量监控平台

      数据的及时性、准确性和完整性关系到一系列数据应用的效果，大数据平台建设之初便已着手实施数据治理的相关工作，统一数据计算口径，设置数据校验规 则，以保证数据质量。数据仓库升级之后，对于数据质量的关注程度更高，于是便从产品层面进行管理。从数据生产过程来看，数据质量监控平台的基本功能包括数 据生产过程中的质量检验、数据入库后的质量评估以及全部生产日志的扫描存档并生成数据质量分析报告。数据生产过程中的质量监控主要对数据生产中源表结构的 变化、字段信息的一致性进行规则校验，并依据校验结果进行质量评估，对存在质量问题的数据将进行自动重跑并通知后续依赖任务。入库之后的数据将进行具体到 字段粒度的数据检查，可以对枚举值、字段类型，甚至数值型字段的最大最小值及均值等进行规则校验，以确定数据是否在合理的范围内变化。