贝壳一站式大数据开发平台实践

1 开场

大家下午好,很荣幸来到这跟大家一起分享贝壳一站式大数据开发平台的落地实践。今天的分享主要分为以下四个部分：

• 贝壳的数据业务背景。

• 数据开发平台探索历程。

• 数据开发平台的整体情况介绍

• 未来规划与展望

2 贝壳的数据业务背景

在公司最早的时候，由于体量较小，基本上都是业务自行承担数据的获取需求的，随着公司规模的增长，对大数据的离线应用开发的需求越来越多。那么为了满足各类数据获取/计算等需求，我们在 14 年成立了大数据部门，专门针对大数据工作进行探索。首先我们针对贝壳数据需求进行了分析，基本上都是围绕物的数据、人的数据、行为数据这三大块来进行分析研究。

• 物：我们早在08年就开始进行筹建楼盘字典，用房间门牌号、标准户型图、配套设施信息等多维信息定义一套房屋，到目前为止，已经收录了2亿以上的房屋信息

• 行为：线上的浏览日志，下线的看房行程等行为信息

• 人：主要是经纪人、还有客户（买家、业主）以及品牌主的信息

然后我们针对大数据技术在业内进行了调研，一般都是遵循这三个逻辑：降本、增效、规范。

3 数据开发平台探索历程

接下来为大家介绍贝壳数据开发平台探索历程。在大数据部门成立伊始，我们进行 hadoop 搭建，使用 Kafka+Sqoop+HDFS+Hive 架构；随着业务需求量以及需求复杂度的迅速增加,我们开始有了平台化的需求,于是开始探索平台化架构；2019 年，我们已经开始进行数据资产管理。

3.1 最初阶段

贝壳最早的大数据开发平台，非常的简单粗暴。经典的 Kafka+Sqoop+HDFS+Hive，任务调度用 Ooize，处理完之后的数据放在 MySQL 中，报表平台直接读取 MySQL 的数据做展示

• 使用了开源组件，采用hadoop进行搭建集群，集成工具使用sqoop，数仓建设使用hive，任务调度框架使用的是ooize，然后直接同步到mysql进行报表展示

• 数仓使用 接入层、数仓层、应用层分层模型进行设计，大部分坑都已经被业界趟过了，可以避免踩一些不必要的坑

在早期这么做有一些好处：

1. 开源组件，方便扩展和运维

2. 业界成熟的数据仓库方案，分层模型设计

3. 有利于技术人员培养

但是随着业务需求的不断增加，出现了各种各样的问题：

1. 当决策层使用报表时发现总是慢了一拍，总会有新的需求出来。原因很简单：其实互联网公司的业务并不像传统行业（如银行、保险等）的业务那么稳定，因为互联网公司的发展比较快，业务更新迭代的也很快。

2. 业务分析总有各种临时的需求，原因和1类似。

3. 数据仓库工程师累成狗。因为所有的数据需求都需要数据仓库case by case 处理

4. 集群作业运维困难，每个运行日志都需要去对应集群机器查找，一般一个小问题，可能都需要好几个小时去定位修复。

5. 数据安全问题，对数据的申请需要进行集中的审批管理，对数据的使用需要进行持续的追踪备案，防止数据泄露。

3.2 平台化阶段

为了解决最初阶段出现的哪些问题，我们提出了平台化的方案，整体架构如下：

这个阶段我们干了几件事：

元数据管理系统上线

• 所有表的创建修改都经过元数据系统，可以实时清晰掌握仓库里的数据情况。

• 数据的接入和流出都通过元数据系统集中管控，所有的日志接入、mysql接入通过元数据来配置，数据申请也是走的元数据，方便集中管理运维。

• 用户可以通过平台进行搜索查询。

调度系统重构，之前我们采用 oozie+python+shell 解决，任务量有 5000 多个，维护困难，且遇到数据修复问题，难以迅速定位。为了解决这些问题，我们参考了 oozie、airflow 等开源软件，自主研发了新的任务调度系统，上线之后取得了非常好的效果：

• 任务配置简单，在图形上简单的拖曳即可操作。

• 提供常用的ETL组件，零编码。举个例子，以前发送数据邮件，需要自己写脚本，目前在我们界面只需配置收件人和数据表即可。

• 一键修复追溯，将排查问题修复数据的时间由一人天缩减到10分钟。Adhoc即席查询，之前我们使用的hue，速度比较慢。通过调研市面上的各种快速查询工具，我们采用了Presto和Spark SQL双引擎，搭配数据地图，可以满足大部分临时需求场景。API上线，主要是定制化开发restful 接口，直接对接业务。

搭建产品化的数据服务平台，数据仓库能量转移到数据建设方面，包括数仓建设和集市建设。数据工程主要职责不再是运维集群，而是搭建数据服务平台和构建业务数据产品。这样做的好处是：

• 解决了数据仓库的瓶颈问题。

• 让BI和业务同学自行进行数据自助提取&分析，效率更高。

• 业务数据产品可以直接使用数据服务平台提高效率，缩减公司成本。

但是这么做有缺点：

1. 数仓表/任务量剧增，造成集群资源相当紧张；

2. 集中的几个人 -> 分散到业务，质量无法把控。

3.3 数据资产化阶段

1. 大量的增加了可视化编程工具，简化开发流程；

2. 增加了大量的管理工具和自动化运维工具，进行了数据标准化和质量管控；

3. 对外开放了大量的数据，实现了数据资产盘活。

4 数据开发平台的整体情况介绍

4.1 数据管理

特点：

• 统一元数据模型，管理包括结构化数据、半结构数据、非结构化数据的相关元数据。

• 贯穿全域，元数据打通数据源、数据仓库、数据应用，记录数据从产生到消费的完整链路。

向上对内数据资产管理、对外提供价值释放。这块，我们通过数据地图

• 用户可以快速注册HIVE表：包括库、表、字段等这些技术信息；分类、标签等业务信息；还有负责人、安全等级、审批人等管理信息

• 用户可以快速查找指定数据，并能够自助的理解信息。

• 还可以通过平台，能够看到贝壳的数据资产，我们引入工作空间的概念，针对资产进行合理资源划分

4.2 数据集成

早期的数据集成都是特别粗暴的 Sqoop 和 kafka 任务，那玩意谁用谁知道，维护简直是要了命了。现在改用 DataX、DataBus 等工具，效率杠杠的。

• 自动化接入，针对集中管理的MYSQL数据库，新库/新表申请创建时，可以消息同步，并自动接入；

• 针对表结构变更时，如果不会对后续任务产生以影响，例如增加字段，则继续进行，如果是字段发生跨类型变化，就会进行通知报警。

针对业务开发出现数据库重大结构变更时，与 DBA 合作实现了审批和通知的线上化，提前告知结构较大变动的情况。

4.3 作业调度

当数据集成到大数据之后，数据开发人员怎么去数仓 &集市建设呢？我们提供了一套从建表、逻辑研发到测试上线整个流程。一个数据开发人员在逻辑处理无误的情况下，一般在 10 分钟内就能搞定。

为了保证任务的健壮性，这边设置了几道防线：sql 执行测试、数据准确性测试和最终的上线。大数据的批处理基本上都是周期性执行的，所以需要引入调度模块，调度系统是支撑批计算任务的管理、分发和执行，充当数据全链路中的心脏中枢。

4.4 数据质量

现在这些数据已经按照既定逻辑周期性执行了，那么怎么保证中间的数据质量呢，例如：

• 一个核心指标，业务需要在每天早上8点看到，这个怎么保证

• 一个报表数据，怎么保证跑出来的数据没有基本的错误

• 当逻辑变更时，怎么保证逻辑准确。

这边针对这些问题，也提供了一些解决方案：

4.5 数据开放

数据的价值再大，不对外开放，那就是垃圾，数据放在那里就是成本，开放、共享出去才有价值。贝壳大数据这边通过两个途径进行数据开放

• 针对人，我们提供了一个自研的odin平台（类似tableau的工具）以及adhoc即席查询，满足用户怎么直接看到大数据里面的数据，进行分析。

• 针对系统，我们提供了数据开放平台，满足下游系统进行获取大数据的数据。

这次我们介绍数据开放平台这块，关于对系统的数据开放方式，也是随着应用场景不同，我们提供了多种交付方式，灵活搭配使用。这里面数据交换 没什么说的，实际上就是借用了 datax 能力，将 hive 里面的数据按照既定的逻辑交付到对应的目标存储 大数据 API 这块，在贝壳的使用还是比较广的，覆盖了贝壳 C 端、B 端绝大部分业务系统，日平均调用量在 2 亿+，而怎么去服务这么大的业务调用呢，我们的架构如下：

其中由于大数据底层是 hadoop+hive，查询效率满足不了业务需求，所以会数据中间层，进行数据对外输出。

5 未来规划与展望

大数据平台建设情况，目前看来我们取得了非常不错的一个成果。在未来，我们将集成更多的能力，赋能前台，实现智能管理，提升整体利用效率。

• 数据资产化管理，全链路数据追踪和分析，提升数据价值

• 加密、脱敏、敏感监控等多种安全策略，全方位保障数据的存储、访问、传输过程

• 沉淀一系列的技术能力和组件集合，构建共性能力和通用服务，打造企业级大数据平台

我的分享就到这，谢谢大家。

本文转载自公众号贝壳产品技术（ID：beikeTC）。

原文链接：

贝壳一站式大数据开发平台实践