不负责任的聊下 Apache Doris
应读者的要求，这篇文章简单聊聊 Apache Doris。说实话，Apache Doris 比前面提到的 Impala 、Presto 这些交互式查询引擎还要不熟。仅仅以自己的经验简单评述下 Apache Doris。
Apache Doris 与大数据领域里的交互式查询引擎不同，一般要在大数据混出头，获得广泛的应用，大多都要兼容 Hive，如果不兼容 Hive SQL 的语言，至少也会兼容 Hive 的元数据库，这样的话，对于大部分已经把数据存储在 Hive 或者是 HDFS 上的公司，替换成本是最少的。但是，Apache Doris 选择了不兼容 Hive，并且选择了 MySQL 语法作为前端语言，对于很多公司来说，替换成本有些高，至少多了不少的 ETL 流程。
从历史上来说，Apache Doris 选择 MySQL 语法，应该是因为 Doris 刚开始诞生的时候，在百度本身是作为 MySQL 分库分表的替代方案去做的，而且主要需求也是为了分析，因此在数据模型上使用了类似 Kylin 的预聚合技术，还有物化视图等等 OLAP 常见的技术。
另外在 Apache Doris 的知乎专栏里有一篇关于 Apache Doris 诞生历史的文章，从这篇文章里可以发现一些 Apache Doris 的一些技术架构选型的问题。毕竟在了解一款软件的时候，要知道它的一些细节问题，比如为什么要这么设计，语言选型等问题，要么需要设计者亲自回答，要么就是从发展历史中寻找。
从架构上来说， Apache Doris 借鉴了 Google 的 Mesa 数据模型、Impala 的计算引擎架构设计和类似 Orc/Parquet 的存储格式。因此没有像亚马逊 Aurora 或者是谷歌的 MapReduce 那样给业界带来很多的新鲜感。使用这样的架构，性能想必是不差的，但可扩展性是会受到限制的，单集群估计几百台就到顶了。
要我评价这款系统的话，Apache Doris 的生态圈构建是一个大问题。对于离线领域，虽然兼容了 MySQL 的语法，但是 MySQL 本身不是 OLAP 领域的主要玩家，大部分公司还是更喜欢 Hive 那一套。在线实时分析的话，还面临着 Druid、Kylin 和 ClickHouse 等引擎的竞争，它们都选择了兼容 Hadoop 生态圈，而不是像 Apache Doris 另起一套。所以说，如果某个公司没有大数据的历史包袱，选择Apache Doris 作为主要 OLAP 分析引擎的话，还是可以试试。
参考文章：
https://zhuanlan.zhihu.com/p/66637804
http://doris.incubator.apache.org/index.html
https://www.infoq.cn/article/vXup94ub59yA*k0tNeFE