大数据产业创新服务媒体
——聚焦数据·改变商业
本文来源：大数据架构师彭文华
这算是今年参加的第二场线下活动。最近活动略密集啊，之前报名的三个活动全赶一块了，只好选择最感兴趣的贝壳来看看。贝壳总算没有让我失望，全部都是我喜欢的内容。贝壳一直没有让我失望，全部都是我喜欢的内容。贝壳CTO线也是把家底都抖搂出来了，分别分享了大数据平台、OLAP平台、DMP平台、推荐平台和算法中台的架构演进之路。
全程干货满满，收获颇丰。其中很多经验，对于从0开始的公司来说，非常有借鉴意义。
这次我就给大家搬运一下《贝壳一站式大数据开发平台实践》，文末有ppt下载。由于本人拍照技术渣，没法解决大屏荧光的问题，所以图片不太好看，还请见谅。
先把大数据开发平台实践的分享人贴出来镇楼。
贝壳的大数据平台主要的数据源可以分为三类：
人：卖家（业主）、买家（买房的、租房的）、经纪人；
物：楼盘字典，之前我分享的文章里介绍过（文末有链接），贝壳08年就弄了一个团队专门整楼盘主数据，建了一个2亿套房子的楼盘字典，给每套房子都编了唯一的ID，这不就是数据中台的ONEID么；
行为：线上浏览行为、线下沟通、看房、谈判等各种行为。
对于大数据平台来说，最重要的能力就是低成本、快速、准确的为各个部门提供各种形式的数据。但是如同每个公司一样，贝壳也是不断演进的。
其实这也符合架构的原理：够用就行，适度超前。毕竟满足业务需求是第一要务，跟产品的MVP（最小可行产品，MinimumViableProduct）原则一致。现在很多公司搞大数据的套路是先找一个总监，总监再找一个架构师，然后瞅准最先进的数据中台搞。这种公司各位最好有多远躲多远。
西门吹税同学，祝好！
贝壳最早的大数据开发平台，非常的简单粗暴。经典的Kafka+Sqoop+HDFS+Hive，任务调度用Ooize，处理完之后的数据放在MySQL中，报表平台直接读取MySQL的数据做展示。
大家不要觉得这个很Low，其实这套架构足够一个中小型公司用好久好久了。基本上招一个中级大数据工程师，带俩初级工程师，加一个报表工程师，能抗很久。
贝壳的同学很实在，把每个架构的优缺点都罗列出来了，我就不赘述了。
架构的演进要么是有高手前瞻性的规划，要么就是痛苦到被迫改进。我认为贝壳两方面的因素都有，判断有高手的原因是贝壳这次的5个负责人分享的时候都共同提到了架构的核心思想，所以他们内部应该有比较好的技术分享氛围和合作基础；判断被迫改进的原因是贝壳发展太快了，即便是有链家的基础，对于喷涌而来的复杂业务和海量需求，应该也是非常痛苦的。
从这一版的大数据架构可以看到，整体是按照lambda的框架进行搭建的。增加了实时处理部分，用Storm、SparkStreaming处理后直接丢给Hbase，用API对外提供实时数据服务。
对比上一版，这边对数据处理这边做了很多改进，建了数仓和即时查询引擎，加了数据产品对外提供自助式查询和分析的服务。不过这ROLAP没太看明白，直接用MySQL+RestAPI？这效率没法看了吧？
MOLAP主要用的是Kylin，后面的OLAP平台会仔细讲，贝壳是Kylin的深度用户。
这个架构看起来是不是就有数据中台的意思了？值得注意的是，贝壳也开始尝试TiDB了，这应该也是大趋势。数据接入方面，开始用阿里的dataX、DataBus等产品，可视化那边自建了一个奥丁，数据开放也增加了数据交换和数据订阅，管理层面增加了元数据管理、数据质量和数据权限。基本上数据中台的基础层面就已经比较完善了。所以在这一版中，大量的增加了可视化编程工具，简化开发流程；增加了大量的管理工具和自动化运维工具，进行了数据标准化和质量管控，对外开放了大量的数据，实现了数据资产盘活。
数据管理没啥好说的，谁家的都一样。不过我对贝壳的房源主数据-楼盘字典是真的很感兴趣，这个绝对是大杀器。现场提了一个关于楼盘字典融合的问题，可惜宗强不是这个组的，没详细解答。
早期的数据集成都是特别粗暴的Sqoop和kafka任务，那玩意谁用谁知道，维护简直是要了亲命了。现在改用DataX、DataBus等工具，效率杠杠的。不过介绍这张片子的时候，宗强说他们能自动接入新库和新表，数据结构变化也能自动同步。这点就有意思了，技术上好处理，先读一下业务库的数据结构就行了。但是在跟业务开发那边怎么协同的呢？自动同步数据结构，不会导致数仓后续任务出问题么？所以我认为应该是监控数据结构发生变化，如果不会对后续任务产生影响，比如增加字段，则继续进行，如果是字段发生变化，应该会停任务，报警。另外，业务开发那边应该还有其他的数据库结构变更上线的审批和通知，提前告知结构较大变动的情况。
贝壳的哥们是真猛，把内部系统都截图出来了（ppt里有更多截图，在这里我就不放那么多了）数据产品经理可以抄一下作业哈（抄其他数据中台产品的作业更完整）。作业调度这边，为了保证任务的健壮性，这边设置了几道防线：sql执行测试、数据准确性测试和最终的上线。
这边的数据质量基本上也是通过完善开发流程、完善任务监控体系和事后的数据质量监控来完成的。这部分略显薄弱，缺少数据质量分析、评估、验证和数据质量问题管理。我估摸着这边还是以先满足业务需求为准吧，反正数据错了有人会找上门来的。
最后是数据开放。贝壳的几位同事都共同提到一句话：数据的价值再大，不对外开放，那就是垃圾，我表示非常认同。数据放在那里就是成本，开放、共享出去才有价值。后面的OLAP平台、DMP平台、推荐平台、算法中台都是从大数据平台这边获取的数据，贝壳的app也大量从大数据平台这边获取各种数据。
不过我发现大数据平台数据中间层用的是mysql、Hbase和clickhouse，貌似没用ES，不知道是处于什么考虑。
嗯，贝壳大数据平台的架构发展路径非常值得借鉴，活生生的案例啊！真的是非常感谢贝壳CTO线的大佬们，希望以后能多来几次。另外，茶歇的蛋糕也很好吃O(∩_∩)O哈哈~
另外，我把内容整理成PPT：
下载链接: