贝壳 OLAP 平台架构演进
source link: https://www.infoq.cn/article/Mx3zbT2dNAqZF549dK5Z
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
本文根据贝壳找房资深工程师肖赞老师在 2020 年"面向 AI 技术的工程架构实践"大会上的演讲速记整理而成。
1 贝壳 OLAP 平台架的构演化历程
如上图所示，贝壳 OLAP 平台架构的演化历程大致可以分成三个阶段：
-
第一个阶段是从 2015 年到 2016 年，Hive to MySQL的初期阶段，这是一个无到有的阶段；
-
第二个阶段是从 2016 年到 2019 年初，基于Kylin的OLAP平台建设阶段，这个阶段围绕着 Apache Kylin引擎构建OLAP 平台；
-
第三个阶段是从 2019 年初到现在，灵活支持多种OLAP引擎的OLAP平台建设阶段，这个阶段解耦了OLAP平台与Kylin的强绑定，具备灵活支持Kylin之外多种不同OLAP引擎的能力；
首先是第 0 阶段 - Hive2MySQL 初期阶段
在这个阶段，数据处理流程比较简单，数据包括日志、Dblog 等，经过 Sqoop 批量或 Kafka 实时接入大数据平台 HDFS 里，在大数据平台完成 ETL 处理后，通过大数据调度系统 Ooize 每天定时写入到关系型数据库 MySQL 中，然后再以 MySQL 中的数据为基础产出各种报表。
这是一个从无到有的过程，很多公司初期也都是这么做的。这种方式的优点是简单，很快能够落地跑通，但是问题也很明显：
-
整个平台受限于MySQL的能力，MySQL无法支持大数据量的快速查询和分析，一般几百万上千万后，MySQL就难以支撑；
-
这种方式缺少共性能力的沉淀，Case by Case的处理用户需求，需求开发时间长；
这也是我们为什么称为第 0 阶段，因为这个阶段平台化工作比较少，严格说还称不上一个平台。
随着公司业务的迅速发展，数据应用需求的急剧增加，Hive2MySQL 的问题逐步突显，对这种原始架构进行升级改造是一个必然的选择。改造的目标很直接，首先解决 MySQL 无法支持海量数据分析查询的问题；第二就是要平台化，沉淀共性能力。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK