京东大数据的思考和探索

京东大数据的思考和探索

作者：刘彦伟

来源：《软件和集成电路》2018年第08期

京东大数据平台是京东大数据业务的基础服务平台，为京东大数据业务的实现提供一站式、自助式的大数据处理全流程解决方案。涵盖数据接入、存储、处理、分析、挖掘、可视化、机器学习等产品和服务，致力于大幅降低大数据消费门槛，帮助京东大数据业务快速落地，助力京东实践以数据为驱动的业务变革与发展。京东在大数据方向上的思考和探索非常多，今天主要和大家分享实时数仓、存储计算分离与容器化。

我针对京东大数据的业务场景和特点，对实时数仓这个领域大概做了三个分类，即实时应用、实时分析、实时数仓。关于实时应用，比如，实时大屏、京东聊吧等，京东内部用的实时报表，为京东的高层或京东业务人员提供决策支持类系统，就是非常典型的实时应用。这些实时应用类业务的技术，在业内发展得比较成熟，比如Storm、Flink、SparkStreaming等的技术框架已经非常成熟，京东基于技术框架再去落地这些应用。这些应用的特点是：门槛高。正因为用了这些比较流行的实时计算框架，京东在数据时效性上可以达到秒级的延迟。

关于实时分析，实时分析是实时应用里一个非常典型的产品。大家在访问京东App、京东网站时，当你浏览一些商品之后，京东能够根据你的实时浏览行为，为你推荐需要的产品，因为每个人在京东看到的商品或广告不一样。实时主要是体现在数据时效性上，通过实时OLAP 分析平台，可以让我们的业务人员或分析师看到分钟级或秒级延迟数据。通过技术手段提升OLAP引擎的数据时效性，从而解决实时分析对数据分析场景的支持。实时分析的场景具有不确定性，分析人员需要获取什么样的数据相对不确定。分析人员需要的订单类型数据可能基于地域分析，也可能基于渠道分析，也可能基于不同时间窗口分析。总之，需求相对不确定。数据相对确定，要么基于订单数据分析，要么基于流量数据分析。实时分析需要研发人员和研发资源的参与，研发人员需要构建OLAP产品底层的模型，研发资源的投入永远不够。京东的业务非常广泛，除了物流、配送、供应链等核心业务之外，还有大量长尾需求。对于长尾需求在实时性上的需求没办法满足，因为没有这么多研发资源投入进来去帮他们构建实时应用或实时OLAP的基础产品。随着实时分析的广泛应用，各个部门对实时计算的需求非常迫切，为了更好地满足客户的需求，我们提出了实时数仓概念。

实时数仓概念是相对于传统数据仓库而言，通过技术手段把传统数据仓库升级为实时数仓，可以达到分钟级时延，实时数仓可以满足有长尾需求的所有用户。实时数仓平台是通用型解决方案，京东的任意一个业务部门可以基于体系内的引擎，通过流式计算引擎的方式，实时写入实时数仓平台中。通过实时数仓的构建，京东所有业务人员的采销、运营都具备了获取实时数据的能力，有了实时数仓的体系之后，业务人员上线业务的第一天，就能看到他实时的数据。所以，我们认为，实时数仓可以改变整个大数据体系的未来。实时数仓通过实时数据总线，将存在数据库里的数据、放在服务器上的日志型数据、结构化数据、非结构化数据等，全部接入流式计算引擎中，流式计算引擎将数据分发到不同存储中。第一类是在线存储，第二类

是放在OLAP引擎中，第三類是通过流式计算引擎将流式数据同步到数据仓库中。京东通过这三类存储，构造三位一体的实时大数据解决方案，让整个实时业务在京东的落地变得更加简单。

接下来我们谈谈存储计算分离与容器化，存储计算分离与容器化的常规方案有：存储计算混合部署、数据本地化、硬件配置均衡、独立于在线集群。计算不再去找存储，减少数据的搬运，从而减少对网络的带宽消耗，存储和计算部署在一个节点上。而今，常规大数据平台一般独立于在线系统，他们互相物理隔离。常规方案形成以来一直广受欢迎，随着技术和业务的发展，常规方案已经暴露出很多问题。第一个问题，存储与计算相互制约，包括机器选型、机器拓展等。比如，如果机器的存储不够了，你要买机器，但是你买的机器可能没办法照顾到某一个资源，这样一个模式制约了机器的选型以及拓展。

庆幸的是，最近几年，容器化技术逐渐成熟，10G网络是标配，25G网络逐渐普及，机器间的网络传输不是问题，这是一个硬件升级带给我们整个平台的机遇。基于这个机遇，我们提出了存储系统、计算系统的未来发展方向，他们应该去做存储与计算分离，存储节点和计算节点应该分开，不应该像现在这样耦合在一起，相互制约，影响各自发展。解决存储、计算遇到的问题需要做很多工作：第一，关闭数据本地化，优化远程读写；第二，存储、计算独立发展，比如，存储机型、计算机型以及存储引擎、计算引擎需要独立发展；第三，通过路由实现多集群的统一；第四，基于容器化的在线、离线计算资源弹性互补。通过存储计算分离与容器化，可以极大地提升整个数据中心的资源使用率。

（根据演讲内容整理，未经本人审核）