Google 理论背书与百度实践加持：百度 Palo 数据库宣布开源

今年 8 月 10 日晚上，百度内部服务于多个项目（包括凤巢、搜索、Feed 和金融等应用）的分析型数据库 Palo 正式登陆 GitHub，成为开源数据库项目大军中的一员。此次开源引起了众多技术人的关注，大家都对 Palo 的架构设计、性能以及 Palo 与其他数据库引擎有何不同充满了好奇。InfoQ 第一时间联系到了百度 Palo 项目负责人马如悦，并对他进行了采访，本文整理自采访问答。

Palo 是百度开发的面向在线报表和分析的数据仓库系统，可以对标于商业的 MPP 数据仓库系统，比如 Greenplum、Vertica、Teradata 等。Palo 主要基于 C++ 和 Java 开发，集成了 Google Mesa 和 Cloudera Impala 的技术。

Palo 由何而来

开发百度 Palo 的团队可以追述到几年前的广告部门的报表系统团队，最初这个团队主要是为百度广告系统开发供广告主查看的在线广告报表系统，由于在线广告报表系统需要满足上百万广告主的大量查询分析需求，这个使用传统 MySQL 分库分表的系统已经显示出诸多问题，比如运维复杂、性能跟不上、容量占用大等。而商业数据库成本高，且性能也没有想象的那么好，最大的问题是由于商业系统闭源，一旦出了问题，查找问题非常复杂。

鉴于此，当时的团队研发了第一代的 Doris 系统，并使用了 2-3 年。随着规模和业务需求的增加，他们开始借鉴 Google 的思路，研发了百度 OlapEngine，Google 叫 Stats Server。OlapEngine 当前一直服务于百度的凤巢和网盟广告系统，比较稳定。但是由于之前使用的是 MySQL 查询层，OlapEngine 实际上只是单一的为报表类型服务的存储引擎，而在分布式管理方面还比较弱。加之使用 MySQL 查询，查询引擎时常成为性能瓶颈。从 2014 年开始，百度开始将 OlapEngine 改造为分布式存储引擎，自带 sharding 和 replication, 然后采用 Impala 作为分布式查询引擎来替代 MySQL，产品名字也定为 Palo。

开源不仅是个人信仰

从百度云的官网上我们可以找到 Palo 的产品信息，也就是说其实 Palo 一直是百度云的一款商用产品，那么如今决定开源的原因是什么呢？

马如悦认为，作为任何一个技术人员，开源已经成为了一种信仰，一方面是解决更多人的问题所带来的成就感，另一方面就是社区的广泛参与必定为项目带来更好的活力。

抛开技术人员的个人追求，从商业角度来讲：当前大量底层技术产品都采用开源模式，客户也愿意采用开源产品，所以大环境也会逼着你去开源；另外，在商业市场中存在着 2/8 原则，即 80% 的收入来自 20% 的付费用户，而另外 80% 的用户贡献收入并不高，然而前者无论开源与否，都可能付费；而后者则更喜欢开源产品；但是，其中最重要的一条规律是，前面 20% 付费用户的选择会参考后面 80% 用户的选择。因此从商业上来看，让产品开源，让 80% 的用户免费使用你的产品，必然会带来很好的口碑，这直接会影响到那 20% 的高付费用户，20% 的这群高付费用户更多地关注服务。

所以，对于未来的技术产品，开源可能成为必须，这个必须不一定损害商业模式，反而会促进商业上的成功。

Palo 的架构设计

在介绍 Palo 架构之前首先说一下 Palo 和百度云上 Palo 产品的区别。Palo Cloud 版本不仅包含 Palo 这个 Core，还会为云端的按需部署进行产品化功能补充，所以可以粗略的认为 Palo Cloud 是 Palo 云化的一个产品，开源的 Palo 可以认为是 Palo Cloud 里面的 Palo Core。下面 2 张图分别给出了 Palo 的架构和 Palo 云化产品的总体产品架构。

Palo 的架构包括前端进程和后端进程。前端负责元数据管理、集群管理、查询接收、查询规划和执行协调；后端负责管理存储和查询执行。

(点击放大图像)

(点击放大图像)

Palo 的详细架构设计可以参考。

当前开源版本的Palo 版本高于百度云上的Palo Cloud 版本内的Palo Core，这个Palo 开源版本直接fork 了百度内部的Palo 开发分支，所以比较新，但是Bug 也可能会多一些。

另外，在百度云网站对Palo 的介绍中，小编发现了“Palo 云端产品目前只支持从百度的BOS 系统导入数据，用户需要使用BOS 相关工具，将自己的数据上传到BOS 系统再导入Palo”这样的描述。难道对于Palo 开源项目的使用者，一定要借助BOS 才能向Palo 中导入数据吗？这是否会给用户带来不便呢？

对于这个疑问，马如悦也给出了解答：Palo 当前支持通过http 的mini-batch 的 push 导入方式，也支持从BOS、HDFS 等进行拉取的batch 导入，还支持将很多计算offload 到hadoop 上的bulk-batch 的大批量导入。当前开源版本还不能支持bulk-batch 的大批量导入，未来代码整理好后会开源出来。

Palo 的应用场景

在百度, 数据分析典型会分为两层系统来完成，底层是由 Hadoop、Spark 构成的离线数据分析系统，这些系统提供对数据的批量和流式处理；上层系统主要由 Palo 这种数据仓库系统来提供在线的数据服务。底层的离线系统完成类似 ETL 的数据处理后，按照业务需求，将处理后的聚合数据灌入上层的 Palo 系统供在线用。Palo 最擅长报表、多维分析，而离线系统对 ad-hoc 的分析是比较有优势的。

在 Palo 之前，百度的各类分析主要是两种形式。

• 一个是写 MR 程序，例行的在 Hadoop 上计算，然后将计算的结果用邮件或者网页的形式呈现给用户。这种报表的问题是，很多报表基本都是从头计算，中间有大量的重复计算。另外，如果用户有新的需求，也需要 RD 配合写程序来完成，交付较慢。与此同时，很多报表用户是不会每次都看的，于是有很多报表的计算就浪费掉了。对于那些在线实时访问的报表需求，MR 计算这种方式更是支持不了。
• 另一个分析的形式是使用 MR 计算后，将中间结果写入 MySQL，然后上层的应用从 MySQL 中查询分析，但是受限于 MySQL 的处理能力，一般存储的都是要查询的最终结果，无法满足新的报表需求，也无法满足稍微耗计算的很多多维分析需求。

Palo 的出现就解决了上面两种形式的问题。根据在线可能对数据的需求，比如利用 Hadoop 这种离线系统，先将接近 TB 级别的原始数据处理成 GB 级别的中间数据，然后将这些中间数据写入 Palo，这之后上层业务就可以灵活地使用这些中间数据来按需查询，得出自己需要的结果。

Palo 的主要应用场景就是那些进行在线聚合分析的各类报表和多维分析，同时也支持分钟级别的数据小批量导入。Palo 专注于小批量导入，废弃了实时导入，主要是为了解决导入原子性和一致性的需求，比如同时导入两张表，可以做到要么全部导入成功，要么都导入不成功。同时小批量导入大大增强了系统的导入性能。除此之外，Palo 能够满足互联网这种在线系统的需求，即无论是查询前端节点，还是后端存储执行节点，还是元数据节点，全部都是高可用的，并且查询节点和存储节点都可以按需扩展。这一点是离线系统和很多商业数据库难以达到的。

大家对百度统计这个产品可能有所了解，它类似于 Google Analytics 系统。百度统计系统的后端数据库系统使用的就是 Palo，只用了大约 60 多台 SATA 的硬盘机器，就支撑了近几百 TB 的存储，和峰值 2000qps 的查询，这都得益于 Palo 的列式存储带来的高效压缩和高查询性能。

性能不该是唯一关注点

对于众多大数据人高度关注的 Palo 的性能测试数据，非常遗憾，由于 Palo 性能测试数据目前还在整理中，今天的文章里暂时无法给出详细的测试数据了。但数据整理完很快会放到 GitHub 上，相信不会让大家久等。为了不让大家失望，马如悦也和我们分享一些粗略的数字。

Palo 使用了 Mesa 的存储模型，所以如果你的存储是可以按照维度聚合的，建议根据业务需求建立不同的 rollup 表，比如天表、月表，也可以按照其他维度建立相应的 rollup，并且建议根据日期为表建立两层分区。如果按照这种方式建表，对于大部分的查询，Palo 比很多大家已知的数据库可能会有 5 到 10 倍的性能提升。

大家如此好奇 Palo 的性能，马如悦对此也有话要说。

小米的雷军卖手机时曾在 PPT 上打出了“不服跑个分”的豪言壮语，苹果和小米手机的高低之分难道仅仅是那个性能跑分吗？

马如悦认为系统性能固然重要，但不该是选型和使用的唯一关注点。他提到了两点：第一，很多系统大家可能因为不了解，所以感觉系统性能很差。数据库产品需要大家认真去了解其擅长之处后，去努力用好，基本上这一领域还不能达到傻瓜式的使用方式。他所在的团队曾经接触过一个政府部门，向他们进行数据库咨询，其不断抱怨 Oracle 性能太差，结果检查后发现竟然一个 Index 都没有建立，根据业务需求帮其建立了 Index 后性能提升了上百倍；第二，Palo 从产品设计之初就不是为了追求高性能去做的，这一点在 GitHub 页面的 Overview 里也有体现。Palo 更多的是追求系统的设计简单和使用简单，当然前提是能满足性能的要求。当前刻意追求系统的高性能，很多时候造成了系统的功能缺失或者过度复杂。对于在线系统，易用易部署易维护更加重要。百度内部也有很多用户用过 Impala+HBase+HDFS，还有 Kylin（依赖 HBase 和 Hive），这些系统的性能暂且不提，主要是依赖很多其它系统，部署维护都很成问题，尤其对于在线系统。所以这些用户最后都转向了 Palo，原因就是 Palo 不管是部署还是维护用起来都太简单了。总得来说，一个好用的系统，不能仅仅是性能好，而是其他方面也优秀。

Palo 的不同之处？

如今业界已经有了这么多大数据分析和搜索引擎，如 Druid、Kylin、Impala 等，还有同样采用 MPP 架构的实时查询系统 EMC Greenplum、HP Vertica 和 Google Dremel，Palo 与这些数据库引擎或系统相比有何不同？Palo 的优势在哪里？

从宏观上来说，互联网公司对分析型数据库的需求远高于传统企业对分析型数据库的需求，这其中包括性价比、高可用、高扩展、高稳定性。Palo 是在百度内部大量使用的系统，在功能取舍上都是为了满足实际业务问题去解决和优化，并且 Palo 系统由百度自己运维，团队了解其在一线急需的需求。马如悦认为，很多研发这些系统的公司，自己并不是其用户或典型用户，所以很难拿到最直接的用户需求，这是 Palo 的优势之一。

从其他方面来说，Palo 的优势还有以下几点。

1. 易用性。从百度团队了解到的当前用户的很多需求，易用性已经排在了选择产品的第一要求下。而很多开源产品，部署使用都非常复杂，很多商用产品也不便于使用。而 Palo 本身不依赖任何第三方系统，只有 2 个进程，使用 MySQL 协议，所以易用性非常好。
2. 高可用。 Palo 为了满足在线系统的需求，考虑到了 24*7 的高可用需求，全系统无任何单点设计。这个在很多商用系统上并不是第一考虑，因此很多系统都存在单点。
3. 易扩展。很多系统，尤其商业系统，后端系统虽然可以扩展，但是查询节点是单点，而越来越高的并发查询需求是原来传统商业数据库未曾考虑到的，毕竟很多传统商业数据仓库是为了满足内部数据报表和分析的需求，而没有考虑到当今大量报表的时效性和面向大量外部用户的需求。大家可以考虑一下，为什么像电信或者银行很多系统都不让你查超过半年或者一年以前的详单或者账单，这些系统很多都使用了商用数据库，而这些数据库应对这种数据规模时就会捉襟见肘。百度统计每年花费 50 万人民币的成本，可以让上百万网站主实时查询 10 年的网站统计数据。

对于 Palo 系统的扩展性，马如悦进行了补充说明。根据当前硬件节点的配置，对于绝大部分公司，100 节点基本是上限，已经可以支持到 1PB 的存储，部署 5 到 10 个 FE 节点，即可达到 10w-20wqps，对于绝大部分业务够用了。工商银行使用了 Teradata，也就 100 节点左右，百度内部的 Palo 单一业务还未到达 100 节点。所以 Palo 当前可以扩展到 100 节点，10w-20wqps， 1PB 存储是设计的目标，并且经过实际测试和验证。更高的扩展还没有测试过，但马如悦认为扩展到 200 或者 300 不成问题。
4. 最新技术的使用。 Palo 使用了当前很多最新的技术，比如 Nvme SSD，两层存储介质；LLVM 和向量化执行；最新的列式存储技术；Hyperlog、bloomfilter；Cgroup 等资源隔离技术。面对计算新技术 (GPU，FPGA)、存储新技术（Nvme SSD）、网络新技术 (RDMA)，百度一直在不断改进 Palo，以便吸收这些新技术。而很多传统商业数据库对这些新技术的跟进速度太慢。
5. 与开源数据库对比。 Druid 没有原生 SQL 查询支持；Kylin 需要大量预计算，存储会暴增，而没有预计算的可能无法查询；Impala 只是查询引擎，而没有存储引擎。同时这些系统都存在前面提到的重大问题，就是依赖复杂、部署复杂。

随着各种硬件技术的进步，产生了越来越多的系统依赖，很多用户现在迫切需要的是尽量用一套系统完成更多的工作，而不是为了完成很多近似的需求而去部署多套系统。Google 在今年年中发布的 Spanner 论文就提到，未来 OLAP 和 OLTP 一定会逐渐融合。马如悦说到：“很多人还是很期待‘LAMP’走遍天下的感觉，现在的各种系统太多了，优秀的太少。在这方面，不管 Spark 未来能走多远，但是 Spark 那种追求尽量在一套系统解决大部分数据分析问题的志向，我还是为其点赞。在 OLTP 领域，NewSQL 已经进行的如火如荼，我自己是这个领域的极大推动者，在百度我们已经投入了大量人力去开发 NewSQL，NewSQL 系统的出现和成熟未来会取代 OldSQL 和 NoSQL 的绝大部分使用场景，这是个高维对低维的战争，要么不成功，要是成功，对老系统是摧枯拉朽的替代。”

未来展望

当然 Palo 也并不完美，目前 Palo 较大的缺点是产品化比较差，周边工具、文档等较少，还不如商业产品那样完善。

从技术上来说，Palo 下一步要支持实时导入、支持更多索引，也会融合 Elasticsearch 的一部分功能进来；从更长远的角度来看，包括 GPU、FPGA 的加速支持也在调研之中。很多使用 Palo 的用户对上层的可视化系统也有较大的需求，所以百度也投入了很多人力去开发新一代的可视化分析系统。马如悦透露，这个新的可视化分析系统将不同于大家现在见到的 Tableau 和 Qlik 等系统，会有一些新的创新理念。

采访嘉宾介绍

马如悦，百度开源技术委员会成员，百度大数据主任架构师。百度分布式计算和存储团队的创始人，曾领导 Hadoop 团队、在线数据库团队，当前是百度大数据架构技术及产品的研发负责人。其团队负责百度所有大数据相关技术和产品的研发，同时也支持百度云大数据相关产品的研发。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。