贝壳总监分享数据中台与大数据平台架构，数字化房企早该如此

今天给大家说一下贝壳一站式大数据开发平台实践，图片不太好看，还请见谅。

 

贝壳的大数据平台主要的数据源可以分为三类：

• 人：卖家（业主）、买家（买房的、租房的）、经纪人；
• 物：楼盘字典，之前我分享的文章里介绍过（文末有链接），贝壳08年就弄了一个团队专门整楼盘主数据，建了一个2亿套房子的楼盘字典，给每套房子都编了唯一的ID，这不就是数据中台的ONE ID么；

行为：线上浏览行为、线下沟通、看房、谈判等各种行为。

对于大数据平台来说，最重要的能力就是低成本、快速、准确的为各个部门提供各种形式的数据。但是如同每个公司一样，贝壳也是不断演进的。

 

其实这也符合架构的原理：够用就行，适度超前。

 

毕竟满足业务需求是第一要务，跟产品的MVP（最小可行产品）原则一致。现在很多公司搞大数据的套路是先找一个总监，总监再找一个架构师，然后瞅准最先进的数据中台搞。这种公司各位最好有多远躲多远。

 

 

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

 

大家不要觉得这个很Low，其实这套架构足够一个中小型公司用好久好久了。基本上招一个中级大数据工程师，带俩初级工程师，加一个报表工程师，能抗很久。

贝壳的同学很实在，把每个架构的优缺点都罗列出来了，我就不赘述了。

 

架构的演进要么是有高手前瞻性的规划，要么就是痛苦到被迫改进。我认为贝壳两方面的因素都有，判断有高手的原因是贝壳这次的5个负责人分享的时候都共同提到了架构的核心思想，所以他们内部应该有比较好的技术分享氛围和合作基础。

 

判断被迫改进的原因是贝壳发展太快了，对于喷涌而来的复杂业务和海量需求，应该也是非常痛苦的。

 

从这一版的大数据架构可以看到，整体是按照lambda的框架进行搭建的。增加了实时处理部分，用Storm、SparkStreaming处理后直接丢给Hbase，用API对外提供实时数据服务。

 

对比上一版，这边对数据处理这边做了很多改进，建了数仓和即时查询引擎，加了数据产品对外提供自助式查询和分析的服务。不过这ROLAP没太看明白，直接用MySQL+Rest API？这效率没法看了吧？

 

MOLAP主要用的是Kylin，后面的OLAP平台会仔细讲，贝壳是Kylin的深度用户。

 

这个架构看起来是不是就有数据中台的意思了？值得注意的是，贝壳也开始尝试TiDB了，这应该也是大趋势。

 

所以在这一版中，大量的增加了可视化编程工具，简化开发流程；增加了大量的管理工具和自动化运维工具，进行了数据标准化和质量管控，对外开放了大量的数据，实现了数据资产盘活。

 

数据管理没啥好说的，谁家的都一样。

 

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

 

不过介绍这张片子的时候，他们能自动接入新库和新表，数据结构变化也能自动同步。这点就有意思了，技术上好处理，先读一下业务库的数据结构就行了。但是在跟业务开发那边怎么协同的呢？

 

自动同步数据结构，不会导致数仓后续任务出问题么？所以我认为应该是监控数据结构发生变化，如果不会对后续任务产生影响，比如增加字段，则继续进行，如果是字段发生变化，应该会停任务，报警。

 

另外，业务开发那边应该还有其他的数据库结构变更上线的审批和通知，提前告知结构较大变动的情况。

 

作业调度这边，为了保证任务的健壮性，这边设置了几道防线：sql执行测试、数据准确性测试和最终的上线。

 

这边的数据质量基本上也是通过完善开发流程、完善任务监控体系和事后的数据质量监控来完成的。这部分略显薄弱，缺少数据质量分析、评估、验证和数据质量问题管理。我估摸着这边还是以先满足业务需求为准吧，反正数据错了有人会找上门来的。

 

 

最后是数据开放。贝壳的几位同事都共同提到一句话：数据的价值再大，不对外开放，那就是垃圾，我表示非常认同。数据放在那里就是成本，开放、共享出去才有价值。

 

后面的OLAP平台、DMP平台、推荐平台、算法中台都是从大数据平台这边获取的数据，贝壳的app也大量从大数据平台这边获取各种数据。

 

不过我发现大数据平台数据中间层用的是mysql、Hbase和clickhouse，貌似没用ES，不知道是处于什么考虑。

 

嗯，贝壳大数据平台的架构发展路径非常值得借鉴，活生生的案例啊！