【遇见 Doris】4.13 线下开发者沙龙分享 -- 搜狐团队

这次的 Apache Doris (incubating) 0.10.0 开发者沙龙在中关村国际会议中心圆满结束，各位嘉宾都带来了干货满满的分享。近期小编会给大家带来精彩的现场回顾和视频录像，敬请期待！现场录像请见文章最后链接分享。

今天是翟东波同学代表搜狐团队带来的关于 Doris 在搜狐的应用和分享。

搜狐团队本次带来的 Doris 分享主要分为 3 大部分，分别是背景介绍、使用案例和代码贡献。

 背景介绍 

首先介绍一下搜狐的团队——搜狐智能媒体，主要是对搜狐主站的文章进行管理、展示、推荐等。他们的数据业务主要分为两部分，一是传统的 BI 业务，包括数据报表、多维分析、数据挖掘等等；还有一部分主要是和文章相关，包括文章搜索、DMP、打标签等。

根据业务场景，数据处理计算范型主要分为两大部分，Batch 层和实时处理层，实际上就是目前典型的 Lambda 架构。

• Batch 又分为批量数据处理和交互式查询功。批量数据处理，主要是 ETL、数据挖掘，目前公司有大数据部门专门维护 Hadoop，提供 Hive 和 Spark，可以很好满足批量数据处理的需求了。交互式查询功能，满足报表和多维分析，目前公司主要提供 Impala、MySQL、Mongo，查询稳定性和响应延迟等，不能满足要求，影响用户体验。

• 实时层分为流式处理和实时数据统计。流式处理，主要是实时 ETL，复杂事件处理，目前公司提供的 Spark Streaming 完全可以满足需求。实时数据统计，主要是把实时处理和批处理的计算统一起来，可以理解为 Kappa 架构，目前主要应用 MySQL、Mongo，数据量大的时候处理不了。

因此，搜狐团队希望找到一个开源工具可以满足交互式查询和实时数据统计。

搜狐在选择产品的时候也做了大量的开源竞品分析。对以下五个产品的优缺点都有很好的说明。

• Impala+HDFS/KUDU

优点：可以实时导入、查询功能非常完善

缺点：部署依赖多，其实相当于要把整个 Hadoop 全部搭一遍，KUDU 只支持 Unique Key，在一些场景下速率不能满足要求

• Presto/Hawq

优点：SQL 查询功能完善

缺点：依赖 HDFS 作为存储层

• Druid

优点：查询很快，底层是 Bitmap 索引、支持 Rollup

缺点：Scatter/Gather 计算模型比较弱，对于 join 很难解决

• Kylin

优点：Cube=>Cuboid 转成 KV 存储，速度快

缺点：数据膨胀太厉害

• ElasticSearch

优点：Bitmap 索引、schema-free

缺点：查询功能不完善，对 join 支持弱

最终，之所以选择了 Doris，是因为这些显著的亮点。

• 首先是元信息管理和存储，部署简单，自依赖。

• 对于存储层，数据分区比较完善，支持 Range 分区和 Hash 分区，有强大的 rollup 功能，支持 Stream load 和 Batch load，可以针对实时和离线数据场景，可对接 Mysql、HDFS。

• 对于查询层，支持 MySQL 协议，可以说是使用零成本，方便迁移，查询功能也很完善。

• 还有很重要的一点是百度人肉在线支持，半夜 12 点还能在线回答问题。

但是相对而言也有一些小小的不足，比如 OLAP 查询性能和文档不够丰富等。

 实用案例 

接下来搜狐团队分享了两个使用案例，通过新旧方案的对比给大家带来直观上的感受。

实时数据分析案例

第一部分是实时数据分析案例。首先搜狐罗列了他们的业务需求：统计每 5 分钟粒度的 PV UV 汇总数据；统计每个 5 分钟时间点的当日累计 PV UV；查询当日及历史 30 天内数据，作为对比；查询需要秒级响应；数据延迟要求控制在 5 分钟内；原始数据约 2000 万/5 分钟；业务需求特点-统计分析维度固定：a/b/c/d ; a/b/c。

因为统计分析维度固定，所以原始方案就是通过 Spark Streaming + Redis + MongoDB 去实现的。但是原方案存在诸多问题，比如针对每个查询维度组合，生成一个 Spark 处理任务，对用户后续的需求不能很好满足；Redis 压力很大，导入任务运行不稳定，经常延迟；流程复杂，依赖多个系统，调了很长时间都不能稳定下来；时间维度只能使用 Processing Time，无法使用实践真实发生的时间 Event Time，数据计算无法保证准确性等等。

因此，后续就将其迁移到 Doris。这样查询的时候就很简单，只需要导入一份数据，就可以支持多种维度组合查询。

目前，根据业务情况，批量导入约 10 万行/秒，总共两千万行数据可以快速导入，线上使用以来未遇到延迟问题；聚合后数据 800 万行/天，单日查询延迟约 2 秒。

总之，开发流程极大简化，数据查询非常方便！

历史数据分析

第二部分案例是关于历史数据分析。目前业务痛点是客户每新增需求，就要相应的新增表，没有统一的表元信息管理。系统负担重，现在 Hive 上已有数千张表,数据延迟比较严重，每天还新增数十 T 的数据。数据开发人员负担重，由于有新增的表，需要花费大量时间补历史数据，并且由于数据查询口径多，细节上稍有出入就会导致数据不一致，业务方体验非常不好。

目前针对这个问题，只是规划了 Doris 方案，还未具体实施。

方案主要是将新增表改为新增 View，或者结合 BI 工具自定义 SQL 数据集，所有新增需求从表里提出来做视图，数据开发人员只需要写简单 SQL，减轻了负担。这样有可能会导致查询比较慢，但是由搜狐的 Doris 运维人员根据每天的查询统计，创建无业务意义的 Rollup 表，优化查询效率，一个 Rollup 可涵盖多个业务分析场景。

 代码贡献 

第一是 Docker 环境搭建。

这样可以很方便的在 Mac 和 Windows 上开发调试 Doris，可以在 Docker 容器中进行编译。比如可以在 Docker 容器里起一个 BE 进程，在 IDE 里起一个 FE 进程，就可以生成一个单实例的 FE-BE。最多一天，就可以搭建起环境。

第二是根据实时数据统计需求开发了 HyperLogLog Aggregation 计算函数。

不仅支持窗口函数，还支持聚合函数返回 HLL。其中第二个功能点是很有必要的，以前 Doris 不会产生中间的 HLL，写带嵌套子查询的复杂 SQL 时会带来很大困难。现在把 String 类型变成 HLL 类型，HLL 类型字段是带有聚合计算语义的，对后续建表和数据建模来说都可以提升效率。

第三是搜狐希望可以把 Parquet 数据直接导入 Doris。

目前 Doris 只支持 csv 格式，每天有大量数据需要做格式化处理，很耗费资源性能。搜狐希望日后 Parquet 作为大数据计算中统一的数据格式。目前设计的流程用 hive 或 spark 做离线的数据处理，把表在 hive 上生成出来，再 refresh 到 Impala 里面，Impala 用来支持高吞吐量的交互式查询，Hive 中产生的数据直接 load 到 Doris 中，Doris 就作为一个高并发交互式查询的引擎，做为业务系统统一的查询接口。

总之，搜狐希望针对不同的业务场景提供合适的工具，提升整体数据的研发效率。

现场录像指路⬇️

百度网盘：

https://pan.baidu.com/s/1N6kIHVmk1vbHyZns_ZpL2Q 

提取码: crah 

有关其他嘉宾的详细分享内容会陆续发出，敬请期待。欢迎关注 Apache Doris 官方公众号！

Apache Doris 官方网站：

http://doris.incubator.apache.org

Apache Doris Github：

https://github.com/apache/incubator-doris

Apache Doris Wiki：

https://github.com/apache/incubator-doris/wiki

Apache Doris 开发者邮件组：