PrestoDB在京东的应用实践

　　2015年3月28日，以“社区胜于代码”(Community Over Code)为主题的“开源技术大会·2015” (Open Source Technology Conference 2015，简称OSTC 2015)在北京丽亭华苑酒店召开，本次大会由全球最大的中文IT社区 CSDN 主办，来自全国各地30多位开源业界资深人士发表主题演讲，数十个开源社区现场互动，到场的开源软件开发者、贡献者与开源爱好者总计近1000人。

　　京东商城集团运维部数据库工程师吕信在为大家分享了京东在PrestoDB方面的使用经验和研究工作。以下是吕信的演讲速记：

　　吕信：大家好，我是本次演讲的吕信，来自于京东商城运维部。在京东商城期间，其实在这三年内我主要是从事大数据相关的开发、调研和架构数据的工作，由于我之前是在京东商城主要负责京东商城整个的Hadoop的运维管理和架构升级与改造，后来京东商城有一个在大数据方面有一个战略调整，我们急需要构建我们的数据仓库。要求很简单，要求实时和准实时的数据分析与计算。我们经过调研，后来选到了PrestoDB。这中间的就要求很多，是我们的首席科学家与Hadoop中间达成协议，通过内部的代码公开，我们会有深度合作，在京东推广PrestoDB，将PrestoDB作为京东实时数据仓库，其他的待会儿会我会跟大家做详细的介绍。

　　今天的主要内容首有以下几个：

1. 　　PrestoDB它到底是什么?
2. 　　它的架构是怎么样的?
3. 　　我们选择PrestoDB进行测试与对比，以及PrestoDB在京东商城的使用过程中存在哪些问题?
4. 　　跟京东商城的耦合度上有什么样的困难
5. 　　我们京东商城在使用PrestoDB过程中遇到的问题
6. 　　我们已经采取与实现了的解决方案。

　　最终我会跟大家简单介绍一下PrestoDB在京东哪些业务方面进行使用。

　　我相信大家应该都或多或少听说过PrestoDB，或者是有人已经在使用了，由于它是一个比较新的一个产品，它的出现其实主要是从Facebook，大家知道还是Facebook的产品，对于实时与准实时的交互分析它显得有点力不从心，由于大家都知道了Hadoop如果要做一个简单的数据查询，你可以输入一个简单的语句，喝杯茶过二十分钟就可以出结果了，对于我们京东商城来说这种现象是可以承受的，它有很多数据核查与比对的工作，你不能让我输一个很简单的语句等二十分钟，他们觉得不可接受，他们要求是能够让我在秒级，最多在20分钟之内出结果，所以在最后我们经过调研选择了PrestoDB。Facebook PrestoDB它也是为了解决同一个问题而发起的项目，他在解决这个问题之前也尝试了很多的开源的产品与工具，如mysql，这些都不能够达到他的要求，要不他支持的语法简单，就是功能性有一些限制。所以Facebook PrestoDB在2010年秋季启动了PrestoDB的项目，在2013年下半年它在公司内部已经大量地推广使用了，通过我们与他们这个项目的领导人交流，他们内部其实每天有一千个员工在使用集群，数据扫描能达到300P，每天能够执行上万个这样的查询，我们也相信在京东应该也可以这样使用。

　　PrestoDB现在在国内用得比较少，可是在北美的公司都在大范围地使用，因此我们相信PrestoDB在京东，甚至在不久的未来，在国内也会得到大量的推广和使用。因为这个PPT写得比较早，写这个PPT的时候很有幸京东占据了四个区，PrestoDB在0.54版本第一次发布，到今年两三年的时间已经更新了0.96，每两个星期会更新一个版本，这个社区还是非常活跃的。

　　那么PrestoDB是一个什么样的东西呢?PrestoDB是一个分布式的基于内存的分析工具，它有这些特点：

• 　　它能够支持这种交互式的数据分析和计算
• 　　它能够支持多大数据量
• 　　它只是一套纯数据框架，不涉及到数据存储，你能够处理的数据量是根据你的集群的规模是成正比的，如果你的集群规模节点数比较小，它处理的数据就会比较小。

　　我们在京东使用的经验，我们的集群有94个节点，每天扫描数据量在500T左右。它快其实是针对于Hive，mysql相比，它是基于这种架构，它不会产生数据的堵塞和等待的过程，它的性能非常快。如果大家没有用过Hive的话，它完全支持标准的规范。

　　PrestoDB它最大的一个亮点就是：它作为一个纯计算框架，可以跨越多个数据源，简单地把一个表进行关联计算，是没有任何问题的。

　　PrestoDB整体的架构是这样的，因为PrestoDB它有一个框架，就是PrestoDB的整体计算框架，它的数据源是完全解藕的，如果你要去截取PrestoDB请求，它可以截取你所有的信息进行计算，整个的过程其实下面这些就是Presto可以支持的，它本身提供的有HDFS、MySQL等这些，红的这部分是我们京东自己开发的，原因是我们有这种业务需要，紫的这些是我们经过了改造，PrestoDB除了读取数据源之外，它会有这种概念。PrestoDB提供以下两种方式的访问：

• 　　提供JDBC去访问
• 　　提供客户端去访问。

　　我说的这个架构是官方提供的一个整体架构图，这个架构图其实说白了只是针对于Hive的架构，它在读取Hive的数据的时候会通过你的KLAN端，它从字面来说是协调者，把你的查询发给数据，会执行你的计划，它会根据你的要求来执行计划。它最终会把你的计划分成以下两种：

• 　　(S)是专门负责数据源和数据读取的，
• 　　(P)是用来做最后的全局排序，或者是最终要把这个数据输出给用户的时候，是要通过这个反馈的。

　　它对于DDL的支持会是比较弱的，但是它支持部分DDL的语句，所以说当你执行DDL语句的时候会在最终有一个过程。

　　这就是说比较深入代码的，也不算太深，这是一个很简单的一个客户端，往PrestoDB集群里面进行查询的过程，客户端这样一个对象，最后它启动的时候会在每个节点上启动一个LTP监控的框架，我的客户端发送一个请求，发送给我的Coordinator，然后通过这个地方去生成各个执行计划、子执行计划以及其他的执行计划，它会根据数据本地性发送到相应的节点去启动相应的步骤去完成查询。

　　刚才说了那么多，其实大概有以下这么几步：

1. 　　首先我Client发送一个请求，发送到本地，最终它会生成一个请求
2. 　　根据数据的本地性发送到相应的节点上，启动相应的(T)，任意的一个查询首先都是去读取数据
3. 　　读取数据之后，它下面会有直接的(S)，完成聚合、操作和计算
4. 　　最终反馈给你的Client。

　　这是我们在进行PrestoDB调研的时候做的一些对比的数据，如果说你的这个查询是涉及到计算的，你应该就能够看得到。如果说你的查询涉及到计算的，PrestoDB的性能会比Hive的性能高出来几倍，但是如果要是说你没有计算和查询，它们的性能是相当的，大家可以看到这个，如果我是在Hive里面，它是不涉及到计算的，只是作为一个数据文件的扫描而已。

　　这个是我们针对于单个查询语序做的测试，我们在PrestoDB上针对我们实际的业务做了相关的测试，我们实际相关的业务涉及到的场景比较多，我们涉及到有十二个实际业务场景，有我们的精准营销、个性化报表，以及安全性查阅分析等等很多业务场景。我们的测试的硬件环境是按照软环境下去做的，我们当时拿来测试的数据总量是6.7T，平均单次扫描量是450G，涉及到查询语句很多很多。最终我们得到一个结论，跟PrestoDB官方发布的测试结论是非常吻合的，因为我们知道有很多这种产品大家为了推销自己的产品有很多公司或者社区避重就轻，他在测的时候会专门选择适合他的场景去测。

　　上面是PrestoDB公共的东西，以及我们对PrestoDB发布一些性能的验证，下面这一半主要是京东商城做了哪些工作，京东商城其实做的最大的工作是PPDO的开发，因为京东商城跟Facebook这边实现业务场景还是有所不同的，因为Facebook那边大部分的业务都是对于ETL完成之后的数据进行了分析和查询。但是京东它有一个很广的应用的业务场景，比如说6.18、或者双11我要实现查询我当前这一刻的成交量或者是订单量。以前京东商城6.18期间需要在6.19才能看到我当天的成交量，所以京东商城有迫切的需要我要看到我当时的成交量，我们当时采用的方案，我们用PrestoDB它跨数据源的特性，PrestoDB数据源我们选择的是线上从库的从库，直接去读取数据进行计算，这是我们TTBO完成的主要的功能。

　　我们做的第二个工作是数据瓶颈的突破这一块，因为大家用过Spark，可能我的主要精力在Presto上，Spark我也有所涉猎，虽然不深入，但是我们经过测试发现这种分布式的内存查询和分析引擎有一个很致命的短版，我的全局排序是我的短版。如果说我一个表数据量是20G，我们去做排序。但是据我们测试的结论，我们当时用Spark做过测试，但是一旦涉及到它有一些过程，这也是我们当时没有选择Spark的一个原因，去年上半年测试的，不知道现在Spark有没有把这个问题解决掉。

　　我们对这样一个问题进行了修正和更改，我们整个集群里面，它在做全局排序的时候，我们有一套完整的调度机制，会让它调度到我们的PrestoDB上，我们PrestoDB集群里面有四到八个专门完成全局排序的计算。

　　我们做的下面一点工作是PrestoDB是默认不支持身份的认证以及权限控制，我们对PrestoDB进行了改造，它可以支持身份认证和权限控制，从而可以在企业内部得到大规模的应用，PrestoDB是不对Lzo文件进行支持的，我们建议数据部门把数据重做一遍，我们修改了Hadoop，让它能够支持Lzo文件。PrestoDB我们进行了insert的功能开发，我知道现场每个人都知道Hive，所以我们PrestoDB为了满足我们工程师的使用方便他们，我们实现了完全覆盖Hive功能的开发。Presto它默认不支持Create功能的，我们在集群管理方面做了一些工作，我们运用官方的Presto可能在Facebook内部已经比较成熟了，不会我今天有个新的业务加入了你的集群，明天又有一个新的业务加入你的集群，这方面做得不是太完善，你业务加入集群之后，我可以直接放在你的文件夹下，我在接入新的业务或者更改新的配置的时候，我不需要集群准时、马上就可以刷新到你的更改。

　　因为Presto是强类型的，我在做数据查询，等号两边的条件要完全一致，所以说在使用过程中你如果想用Presto完成数据类型的转换，对于我们熟悉Hive的工程师来说比较麻烦，我们为了方便京东商城众多BI工程师的需求，我们也是完全向Hive靠齐。京东版的Presto跟Hive使用是一模一样的，但是它的性能比Hive要高。

　　下面我们详细介绍一下京东PDBO有哪些功能，它支持数据的缓存、并存、读取及性能的智能优化，京东商城大数据量的查询是在内部分表里面去做的，我们业务研发人员会通过业务代码把这些都给组织起来。但是我们在推广Presto的过程中，他们就提出一个要求，我有一个1024张分表，你能不能给我形成一个TABLE，你只让我查询我的逻辑名就可以了，我们京东的Presto可以做到这一点，默认的Presto只支持一个库一个表，我们对它进行了改造。我们可以支持只读你的逻辑表，把它抵成了所有的影射关系，大家可以看到我们到每个(W)上就可以有Cache，我查询完了之后，它是通过我们的RBD五去做查询的，我们会有一个表，记录了我各个分库分表的信息，我的路由器会把我各个分库分表的信息组织到一块，把所有信息读到我的集群里。

　　我刚才已经说了，Presto它默认你从社区上可以下载一个版本去试用，但是它都是单个Worker对应单个表，我们公司的网络是牵涉到的网络很大，比如说我达到了五百多G，我通过这个去读就读死了。但是我怎么样才能够加快它的读取的速率呢，我都个Worker去读这样一张表，我们的Presto集群有一个数据库，数据库里面就是我刚才说的信息，里面记录了我的目标表需要多少个Worker去读，在选择Worker的时候，会就近选择我的同一个(R)上的Worker去读我这一个表里面的数据。

　　Presto做的另一个比较高大上的工作，我们实现了PDBO的智能优化，这个智能优化是怎么来的呢?是基于这样一个并行读取来做的，我读一个数据，有一个十个Worker去读，每个Worker就要读一片数据，我这一片数据应该怎么分呢?你需要指定你切割自断，一般情况下我们通过逐渐切割，如果说逐渐从1到1万去分布，我每一个Worker去读一千个记录，我们读的是线上的从库，这个数据是实时变化的。所以说你切割的主件有可能分布不均匀，你起始是1到1万，这样我们就面临一个问题，你分了十个Worker去读，你第一个节点读了一千，第二个节点是零，第三个是一千、第四个是一千，我所有的Worker节点没有得到充分的利用。然后我们就是学习里面的一个机制，我们能够对它动态度曲的数据进行动态的分析和智能的优化，是一个学习和改进的过程。我刚开始做一个初始化的配置，第一次查询性能低下，每一个Worker会实时采集到数据，我根据每一个结点上读取数据的疏希程度，最后拿到一个结果。我不管切分的主件是否均匀，也能够满足我的每一个节点读的数据大致相似。

　　再一个就是现在这个主题是我要讲的我们Presto集群在使用过程中，不光是Presto集群，Spark集群读取过程中不想看到的，它给你一个排序，你就去等，等很长时间才出结果，甚至等了很长时间它的查询失败了。我们在使用Presto的过程中也发现了这个问题，我读的这个数据量超过128G的时候它就会失败，当时我们给内存搞到256G不就完了呢?Presto在各个节点选取的过程中就是一个随机选取的过程做这样一个排序的节点，如果你要满足这样一个查询所有的都要升级，我们修改了Presto的调度机制，它在调度Spark的机制，我们加入了一种概念，我在集群里面选择少数的几排节点作为头级节点进行升级，同时我整个就会形成非对称式的结构，我里面有十分之一的节点。平时它只会用到它内存的50%以下，一旦有全局排序的过程过来之后，我在调度的时候，我其他任何都不会在我这个节点上分配任务，这个就完全支持我的全局排序的计算，从而能够在很小的成本基础上达到我集群的计算性能。

　　我们在京东推广Presto的过程中，很多业务部门刚开始的时候不想使用，为什么呢?就是Presto本身它是不支持身份认证和权限控制的，默认情况下你发现我只要知道你的地址，我随便从网上下载一个端只要能够连到你的服务器，我就可以用你的计算机完成计算，这是个很严重的问题。另外一个更严重的问题，有很多业务涉及到很多敏感的数据，这个数据只能他自己查看，他不想让别人去查看，所以说Presto也不支持这种权限的控制，我们就遇到了很大的阻力，我们专门组成一个小组，花费了两个月的时间自主研发出来一套在Presto上运行的一整套的权限管理系统。它的整个过程其实从逻辑上来说很简单，就是我的Client端会对你的数据进行解析，解析出来我需要得到哪些?我就会去我的服务器上我的所有的用户的权限信息都是通过我们的DB系统进行申请和发放的，它申请和发放完这些数据之后会在一个表上，我会通过这张表去查询，它有没有这样一个权限去查询?如果没有这样一个权限你最后反馈有没有查询的信息，如果你登录的时候没有提供任何密码是登录不进来的。如果要是说通过了身份认证，后面的机制完全就是Presto本身的计算机制，就可以成功愉快地运行你的数据了。

　　下面是我们进行的Insert的操作，你可以插入多列或者多行都没有问题的，其中最大的一个亮点是让我们使用Hive的BI工程师可以支持动态分析的插入，这个语法我就不用跟大家说了，大家应该都知道这种动态分区，它也支持了我们Hive里面的操作。现在也就是我们在京东商城推广Presto，线上有四个业务都在大范围地使用Presto，因为我们已经做到了权限的认证、控制，所有的用法都跟Hive一样。

　　我们还做了一些功能的改造，上面黄色的部分是Presto官方的版本，我只是创建这样一个表，并且这样一个结构是OK的。然后我也可以创建分区表，大家用过Hive的应该都知道，我可以指定一二三级分区都是OK的，出了新版本之外其他的可能没有。有一个最大的亮点Hive没有这样的功能，这个功能也是我们的业务提出的，他们提出一个什么要求呢?我在使用你的Presto，我的成本很高，我要做一个数据的初始化，我做一个数据的初始化，我要先把结构建起来，我再写更多的Insert语句，你能不能把这部分工作合成一条完成呢?我们可以得到，我们实现了这样的一个动态分区的工作，Coordinator会把你动态查询语句的最后两列作为你的分区的值，完成动态分区并创建表，完成数据的导入，所以说在我们的业务部门使用Presto的过程中会感觉到很愉快，为什么呢?因为它已经完全可以摆脱繁琐复杂的工作。

　　我们整个Presto执行架构是这样的，

1. 创建了一整套的IDE的调度机构
2. 完成任务的定时
3. 能够定频率的调度
4. 所有的调度通过CLI的方式去读取

     这就是我们整个的架构，架构很清晰。

　　下面我说一下Presto在京东上的使用场景，它可以满足数据查询，能够短时间内反馈出一个结果。它可以做准实时的查询，在京东我们使用的业务是精准营销和个性化报表，大部分的查询都能够在一到两分钟之内完成。我刚才也说了，也很方便地完成数据的抽取，我们以前用Hadoop都很繁琐，你所有的ETL的工作都可以用一条语句去完成。其实我们也很欢迎各个有志人士加入我们一起去完成这样一个非常酷的工具类的开发，如果大家对我们的Presto产品以及想要和我们一起做这样的一个很伟大的事情，大家可以通过扫二维码加入我们的技术群，也可以加入我们的中文社区，这个是得到Facebook授权的，Facebook在中国区的Facebook网，技术由京东商城的集团运维部来负责，可以加入到这样一个社区网站大家一起交流，如果有深入的问题可以找我们的接头人，这是他的联系方式，加入我们，谢谢大家!

　　以下是提问环节

　　1.提问：如果说资料毁损的话你怎么去做?

　　吕信：Presto是完全数据源解藕，我可以查询我们LDF的数据是三备份的，我损失一份它会自动完成第三份的复制，这其实是LDF的机制，对于其他的数据，也就是说我的从库，比如说我的从库挂了，我们京东会有一个事实切换的机制，它切换之后我们Presto会去探测你的两个主从库用的是哪一个IP，我们探测之后会回写到我们的表里头，有稍微的服务中断，不会超过一分钟。

　　2.提问：这个主要用于报表?

　　吕信：我们在京东实际在线上使用的业务有一个精准营销，还有一个个性化报表，就是这位朋友说的个性化数据的分析，各个报表，这是一个很大的业务场景。另外，我们京东还有安全部门要对所有的用户存在的风险进行分析查询以及比对，还有另外一个业务我们现在正在逐步取代ETL的工具，用Presto完成数据的导入和到处的工作，一共有这四个应用领域。

　　3.提问：你们联机基本上没有什么大的压力是吗?平时做的业务，我们在京东上买东西，那个压力比你这个分析还大吧?

　　吕信：是这样，Presto它是不支持事务的，它是一个跟你的想法不一样，京东订单的处理没有这些，但是Presto主要做我出报表是OK的，分析型的工作，非事务性的，ORAT的工作，我们京东的订单没有在这上面，如果在这上面可能就会出大乱子了。

　　4.提问：我还想问一个问题，我看到你们做了很多对Presto的扩展，这些扩展我个人感觉不一定是符合Presto当初的架构的本意的，那你们是自己分出来了?

　　吕信：这些代码PDBO的代码已经提交给Facebook了，这方面的代码量很大，设计得也很复杂，我们与Facebook正在进行交流，他们最初交流的意见是我们Presto最初的定位是完成数据的导出，他们暂时不会接受我们的代码，我们Insert这种功能提交给社区了，Presto马上发布1.0，有可能在1.0看我们做的很酷的功能，转换已经提交上去了。