峰哥买房用的贝壳app，他们的大数据平台如何实现的？
点击上方 "大数据肌肉猿"关注, 星标一起成长
后台回复【加群】，进入高质量学习交流群
贝壳找房作为“科技驱动的新居住服务商”，致力于推进居住服务产业数字化、智能化进程，通过助力优质服务者，为三亿中国家庭提供包括二手房、新房、租赁、装修等全方位的高品质、高效率居住服务。
贝壳大数据平台部构建和支撑了全集团多个场景应用，覆盖的业务线多，业务复杂度高，因此对数据分析平台的要求也非常高。OLAP平台需要支撑如指标分析、Ad hoc探索性分析、可视化报表等常规业务，还需要支持如用户行为分析、风控、DMP等典型业务。OLAP平台需要适配不同类型、负载以及场景的分析要求，为此大数据平台部需要同时运维的平台上已经存在有6、7种不同的分析引擎。
从2021年开始通过引入DorisDB，作为主要的分析引擎开始了公司大数据分析引擎的整合。在指标平台、报表平台上基本实现了通过一个组件（DorisDB）来适配多样的数据分析场景。通过DorisDB构建一站式全场景的极速数据分析平台，提升了数据分析效率，降低了运维复杂度，充分释放了数据价值。
业务背景
指标平台
指标平台作为全集团多场景的统一指标管理平台，提供了以下功能：
对外提供统一的API
指标统一定义，口径统一管理
实时指标查询
前期使用Apache Kylin支持汇总指标查询。随着明细查询的需求增加，又引入了Druid、ClickHouse和Apache Doris等多个组件。
目前应用情况：
上万级别指标应用
几千万调用/天
TP99查询在3秒以内
可视化报表平台
运营人员可以在可视化报表平台上，基于Hive表或指标来创建自助报表。基于指标创建报表时，通过指标平台将请求转化为SQL语句，大部分使用Impala执行查询。
目前应用情况：
活跃报表数千张
每天数十万次调用
业务痛点
历史数据Update支持差
由于贝壳大部分的业务场景都需要对数据进行更新操作。如果是离线指标通过批量的方式处理，但实时指标就需要实时的对历史数据进行更新。
例如在经纪人带看场景中，某些带看记录，如果触发了风控规则，会被判定为无效带看记录，数据状态就会发生变更。再比如新房交易流程，新房记录的状态需要在报备、带看、签约、成交直接互相流转。整个业务流程都需要对新房状态进行在线更新。
Druid作为原架构中的主要分析引擎，不支持Update功能，只能用于对离线数据进行指标分析，无法支持实时指标计算。ClickHouse虽然提供了Update和Delete两个mutation操作，但是修改的代价比较大。经常积累过量mutation无法完成数据更新，而且导致了多次线上ClickHouse集群整体宕机。另外，由于mutation是一个异步的线程，所以并不能保证Update的数据实时可见，从而指标的实时性也无法得到保障。
多表Join功能的支持能力差
平台现有的OLAP引擎(Kylin、Druid、ClickHouse)多表Join时的性能都比较差，甚至不支持多表Join。以前通常只能采用宽表形式来构建数据模型。但贝壳是一个线上线下结合产业互联网公司，一个典型的场景是有经纪人经常在门店中间跳动。在计算最新的业绩，或者计算奖金指标的时候，就需要去关注组织架构变动。使用宽表模型的话，只要维度发生变化，就需要重刷整个宽表，导致有些指标刷新的时间过久，数据时效性就会变差。
现有的引擎Druid虽然有lookup表的能力，但经过实际测试后性能不佳。Apache Kylin实际上也不支持Join，多表的Join需要通过在cube构建的时候底层打成宽表来实现。ClickHouse只支持本地Hash join的模式，不支持分布式Shuffle join，多数情况下灵活性受限，性能表现不佳。
无法同时支持明细与聚合
在贝壳指标不仅仅需要给管理人员看汇总指标，如果发现指标有问题，还需要下钻到明细，查看导致指标异常的具体原因。随后根据明细数据的情况，再采取一系列的管理动作。也就是说，OLAP引擎需要同时具备明细数据查询和数据聚合的能力。由于Apache Kylin、Druid不能较好支持明细数据查询，之前只能将聚合后的数据存储在Apache Kylin、Druid中，明细数据存储在Clickhouse中。没有把聚合数据放到Clickhouse是由于Clickhouse的物化视图是不透明的，对上层的应用程序来说查询明细的时候需要切换到对应的明细表，操作也比较繁琐。不论是查询引擎还是表的切换都需要我们维护额外的查询代码逻辑。而且对前端的数据分析人员也不够友好，他们需要同时了解明细数据与聚合数据不同的存储位置以及之间的对应关系，增加学习，沟通的成本。
OLAP引擎较多，运维复杂，用户学习成本较高
目前贝壳的数据分析平台中引入了六、七种不同的分析引擎（Impala、Presto、Kylin、Druid、ClickHouse、Hive）。而团队只有十几个人，技术栈过多，导致我们对每一种引擎的掌握程度都不够深，运维压力非常大，出问题的时候很容易hold不住。
特别像ClickHouse 的集群，虽然性能很好，但是对运维的要求比较高。ClickHouse集群的分片、副本信息，都是通过静态的配置文件的方式进行配置。当整个集群需要扩缩容的时候，就必须通过修改配置文件的方式进行刷新，数据的均衡都需要运维人员介入。此外ClickHouse通过zookeeper来做副本管理，当集群规模变大时，副本数过多会导致zookeeper的压力变大，集群的稳定性也就会相应变差。
另一方面，多个引擎对用户来说学习成本也很高，不同分析系统的SQL语句不一致，每一种都需要额外的学习成本。
DorisDB与其它OLAP引擎的比较
主要因为DorisDB具备以下特性：
MPP架构 + 高效列式存储引擎
高性能、高可用、高弹性
标准ANSI SQL支持
支持多表Join
支持MySQL协议
支持预聚合
支持物化视图
支持预聚合结果自动更新
支持数据高效的批量导入、实时导入
支持数据的实时更新
我们对DorisDB与其他OLAP引擎做了全面的对比测试，对比项包括ClickHouse、Duird和Apache Doris。测试环境配置信息如下：
查询性能：DorisDB vs ClickHouse vs Apache Doris
查询性能对比测试使用SSB测试集，数据量最大的表lineorder约60亿(scale 1000)。在ClickHouse最擅长的宽表模式下，分别在限制线程数不超过8，不限制线程数两种情况下对比了DorisDB和Clickhouse的性能。
在DorisDB和ClickHouse单节点都使用不超过8个线程的情况下，13个查询中有9个DorisDB的性能好于ClickHouse。
(宽表模式，设置ClickHouse max_threads=8）
不限制ClickHouse线程数情况下，13个查询中有7个DorisDB性能好于ClickHouse。
(宽表模式，不限制max_threads）
在多表Join模式下，对比了DorisDB和Apache Doris的表现。整体上DorisDB比Apache Doris有5-10倍的性能优势。
没有对Apache Doris的宽表性能进程测试，是由于在60亿的数据量下，DorisDB可以直接使用insert into select语句将数据转成宽表，Apache doris执行相同语句会报oom。由此也可以看出DorisDB在内存的管理和执行效率上比Apache Doris要好不少。同时也了解到DorisDB后续也有开源的计划，所以我们在应用中都使用了DorisDB作为OLAP分析引擎。
高并发：DorisDB vs Druid
线上实际环境，以宽表模式对Druid和DorisDB进行了高并发的压力测试。Druid集群的QPS可以达到600-700左右，平均响应时间100ms左右，最大响应时间300ms左右。相同规模的DorisDB集群，QPS可以达到1500-2000，平均响应时间在50ms左右，最大响应时间在100ms左右。
（压力测试下Druid并发量）
（压力测试下DorisDB并发量）
此外，我们额外对DorisDB的Join模式进行了高并发的压力测试，QPS可以到200-300，平均响应时间470ms。可以看出即使在Join模式的复杂查询场景下，DorisDB的并发性能还依旧维持在一个不错的水准。
其他指标
如下表所示，我们也对其他方面的指标进行了比较：
DorisDB在贝壳的应用
目前贝壳的DorisDB集群使用35台物理机（80core、192GB内存、3TB SSD），部署了35 BE，3 FE。支持了如指标平台、可视化报表平台、典型业务场景等多个应用。
指标平台
1、 高QPS指标查询
通过DorisDB强大的并发能力支撑以往Druid所不能满足的高QPS场景。如房屋经纪人业绩考核时段，QPS会瞬间从几十飙升到3000。以往使用Durid应对这类瞬时高压场景没有很好的解决办法，集群会不停告警乃至宕机。使用DorisDB支撑的指标平台就能很好的解决这个问题。
2、 可自动更新的物化视图
DorisDB有非常好的物化视图能力。对慢查询指标通过rollup聚合，在查询时可以自动命中物化视图，自动路由，加速整个查询。同时物化视图支持自动更新，当明细表发生变化时，物化视图自动刷新聚合结果。
3、 实时的大屏指标
原有的实时指标是通过ClickHouse来支持的，但是需要建大量的视图。ClickHouse物化视图不支持自动路由，在查询时需要指定对应的物化视图表名字。而且ClickHouse对Update的支持也非常有限，查询最新的记录需要额外的函数支持，不符合标准的SQL语法。总体来说使用ClickHouse来计算实时指标，实现过程非常复杂。通过DorisDB来支持实时指标场景，能自动对指标进行实时更新，只需要创建对应的物化视图即可，无需额外的任何操作就可以指标的实时更新。
4、 更灵活的数据模型
DorisDB同时也具备非常强的单表查询能力和多表Join能力，可以支持宽表模式和多表Join模式。在应对部分灵活指标，如前文提到的经纪人组织架构变更场景，基于DorisDB就无需构建宽表。使用在线Join的方式，当维度发生变动的时候，更新维度表重新进行关联查询即可。
奥丁可视化平台
此前我们基于MySQL做了大量的报表，如市场管理看板等。随着数据量增大，数据量达到千万级别MySQL已经完全不能支撑。目前已将这些可视化系统报表全部迁移到DorisDB上。由于DorisDB对MySQL协议的支持，整个迁移的过过程比较平滑，只需要很少的工作量。
典型业务
原有的典型业务如A/B试验平台、交易平台、风控平台、直播中台等，之前是基于ClickHouse和Apache Doris构建的。现在我们已经开始将这些业务应用逐步迁移至DorisDB。此外，后续构建的新应用，如用户行为分析等，我们也会基于DorisDB来进行构建。
下图是直播中台从Apache Doris迁移到DorisDB后的查询效率对比。可以看到查询效率均有成倍的提升，在数据量大的情况下（全量表）性能提升尤为明细，性能提升均在7倍以上。
（直播平台使用DorisDB后，所有查询的延时都显著降低）
写在最后
在近半年的使用过程中，从整体来看DorisDB在稳定性和查询性能上要优于Apache doris。宽表性能和ClickHouse不相上下，多表Join能力要胜于ClickHouse。DorisDB在保持甚至超过ClickHouse性能的同时，极大降低了我们的运维压力，简化了数据开发的链路。
DorisDB对hive外表的支持也给我们很大的想象空间，尤其是一些Ad hoc查询场景。现在我们的小查询用Spark SQL，大的查询用hive或者是presto。后续使用DorisDB来分担一些热查询的流量，整体的查询效率也可以得到进一步的提升。使用DorisDB查询ElasticSearch外表也在我们下一步的规划中。
后续我们会将DorisDB覆盖到更多的业务场景，使用DorisDB逐步替代Druid、Clickhouse、Kylin等其他分析引擎，来构建我们全场景统一的极速OLAP分析平台。
DorisDB团队的同学支持也十分给力，在此表示感谢。
--end--
扫描下方二维码 添加好友，备注【交流】 可私聊交流，也可进资源丰富学习群
更文不易，点个“在看”支持一下👇