基于ES构建贝壳找房搜索中台
贝壳找房搜索架构演进
品牌架构
集团品牌矩阵
平台品牌
资管品牌
贝壳
T o C:找房大平台 ToB：以技术驱动的品质居住服务平台
（
0贝壳经纪 0贝壳新房0贝壳租房 0贝壳装修 0贝壳海外 0.…..
新经纪品牌
自如
创造品质租住生活
链家
德佑
•■•■■•
国民链家品质为先 ToC：更用心的社区专家
＼｀、、、 、 ．
关键词 中文文文文本
⻉贝壳搜索-V2架构-公司级平台(2016~2017)
域名负载
http
搜索服务 搜索服务 搜索服务…
SolrCloud集群 （Collection）
DAS服务集群 全量量 增量量
二二手手房在售 成交
xx服务 楼盘字典
Link 新房 未知服务
索引服务 索引服务…
binlog
HTTP HTTP HTTP 接口口1 接口口2 接口口3
ElasticSearch: •社区活跃，发展势头好 •人人才更更充足足，补充人人才容易易 •Zen Discovery节点发现 •JSON友好 •ELK日日志分析，⻉贝壳内应用用广广泛 •多语言言(Java,Php,Go等)开发者 •底层基于Lucene，定制化复用用 •优秀的可扩展能力力力 •支支持Nested功能 •良好的跨索引查询能力力力
2016
2017
2018
12,000,000,000 9,500,000,000 7,000,000,000 4,500,000,000 2,000,000,000
2016
月月hits
2017
2018
搜索服务-基本构成
DB 文文件
人人工工录入入
贝壳找房数据中台建设实践
贝壳找房数据中台建设实践贝壳楼盘字典®构建了覆盖全国主要城市2亿多套房屋的楼盘数据库楼盘字典®套真实房屋信息2.07亿万张小区景观图542万覆盖全国50万个小区50万万张房屋标准户型图387万覆盖933万个单元信息933万436万大体量丰富数据个楼幢分布信息采集（除新疆、西藏、海南）所有＞30个楼盘的县级以上行政区覆盖全国25个省份25省覆盖全国326个地级市326市覆盖全国1352个地级县&县1352县楼盘字典®数据库在十一年的建设中形成了全国独一无二的楼盘表精准坐标7级门址管理房屋楼层单元楼幢楼盘城区城市小区城区城市小区层级：小区别名行政地址绿化率物业公司车位数量开发商……楼幢层级：产权年限建筑结构水电费供暖类型交易权属物业费……单元层级：电梯数量有无门禁楼层数……房屋层级：统计用途交易权属建筑面积用水类型用电类型建成年代户型信息产权年限套内面积……周边：超市门店社区地铁医疗教育……举例：北京世纪星城，从小区到楼幢到房间的各层级信息在楼盘字典®的建设中，贝壳积累了标准化数据建设方法论采集定位外业采集内业审核数据存储数据建设标准化流程数据标准数据展示基于楼盘字典®数据库，贝壳已经具备了平台化的服务能力REDS InfoREDS Map楼盘字典®楼盘字典全量数据的楼盘表及字段数据服务从⼆维商圈图延伸到三维场景中，支持多种三维数据展示和特效渲染；包含三维分析⼯具；BIM快速成图，并可以定制化REDS Navi小区内精准导航，带看路线规划，支持定制化搜索REDS LabREDS Eva基于楼盘字典的数据，与客、⼈数据，以及⼤数据算法结合，开发各类BI决策支持产品，比如户型图解读对外估价及市场⾏情的整体情报预测服务，服务包含基于地理信息的整体服务REDS Play数据可视化的⽅向，拥有丰富的模板库REDS Play-全国→城市→城区→商圈→小区价格波动一目了然将楼盘库的数据应用起来，并设计开发对应的数据看板数据可视化之后就能更加精准的管控着城市的房屋数据楼盘管理系统数据展示层数据应用层数据支撑层数据看板应用系统楼盘库数据大屏楼盘地图数据看板楼盘管理数据初始化数据接口调用地址匹配服务*同步全量楼盘字典数据（楼盘、楼栋及所需属性字段数据）*可实时调用接口获取楼盘、楼栋数据*可根据地址信息匹配楼盘字典对应的楼盘、楼栋管理楼盘库的内容，进行新增、删除、修改等等操作租赁管理基于楼盘库，将所有租赁的情况进行管控，大大增加城市的稳定押品管理管控全市所有的按揭抵押的房屋，通过房价监控控制整体市场风险人员流动管理将人与房屋的数据进行挂接，那么针对整个城市的人员流动就可以更有效的控制… …… …更多基于城市楼盘表的应用Agenda•为什么建数据中台•什么是数据中台•如何建数据中台•数据中台的实战。
贝壳采购数字化项目二期签约,商越助力打造互联网行业全场景全链路采购数字化平台
贝壳采购数字化项目二期签约，商越助力打造互联网行业全场景全链路采购数字化平台近日，贝壳找房(北京)科技有限公司（以下简称“贝壳”）与北京商越网络科技有限公司（以下简称“商越”）完成二期签约，双方将继续扩大合作。
在商越与贝壳项目组的密切配合、精诚合作下，贝壳一期采购商城项目已成功上线并稳定运行一年多，此次二期合作贝壳将从采购业务全流程、财务协同、合同管理等方面着手，构建采购全链路、全品类、全场景的数字化管理闭环，打造互联网行业采购数字化标杆。
作为商越的第一家客户，贝壳在2019年4月完成了企业采购商城建设（详情点击：链家签约商越，搭建采购互联网平台）。
贝壳采购商城上线后,通过商越为其提供的持续运营服务,现已覆盖贝壳全国8000多门店, 使采购周期由原来平均的25天缩减至2天，协议采购比例由30%提升至90%，采购效率显著提升。
相比一期单一的目录化商城采购需求，双方二期合作将完成寻源招标采购、场景化采购的上线和聚贤阁接口范围的升级，可进一步支持贝壳定制类商品和服务的电商采购，满足贝壳在快速发展中诞生的非目录化采购需求。
贝壳二期将以更个性化、多样性、多场景的方式，满足贝壳全链路采购，实现所有采购业务集中在商越的系统中完成，替换原有的SRM系统。
在实现全链路采购的同时，贝壳二期合作也将从财务视角打造从采购预算、核算到支付的全流程协同，并切入合同管理功能，实现业财一体化的管控，以财务合规推动业务高效发展。
据悉，贝壳二期合作启动会已于6月28日在商越北京总部召开，贝壳采购中心总经理方瀛，商越北方区总经理张雁明及双方项目组成员参加会议。
从本次合作启动会上了解到，未来越来越多的房子都将用数字化串联，贝壳的数字化优势将持续彰显。
贝壳是一家互联网企业，将数字化建设视为企业头等战略。
贝壳高度认可商越在采购数字化领域的专业度,极为稳定的系统和持续有效的运营服务是贝壳继续选择商越的原因。
商越北方区总经理张雁明表示，感谢贝壳对商越的信任，贝壳是商越在互联网领域的战略级合作伙伴。
房源搜索中台搭建实战(上)
房源搜索中台搭建实战（上）编辑导语：中台简单地说，就是抽象和复用，类似软件开发中“面向服务的体系架构”的概念，中台也有不同的分类，根据企业不同的需要搭建不同的中台体系；本文作者根据自己搭建房源搜索中台的案列进行经验分享和总结，我们一起来看一下。
中台只是一种形式，归根到底是需要解决真实的业务问题；为了中台概念而打乱现有的业务部署，强行拆前台搭中台往往是得不偿失的。
从19年初我接手房源搜索业务开始，不断在内部讨论和推演是否要建立一个全局搜索配置中心（也就是现在所说的中台），一直到19年底才正式确认要搭建一个独立的中台系统。
目前已经接近上线，回过头来与大家分享下期间的经验和总结。
1. 什么是中台？中台这个概念在19年前后火遍互联网，马云参观Suppercell后提出的“大中台小前台”战略调整已经被传为佳话。
那么到底什么是中台？网络上已经有各种角度的解读，简单地说就是：抽象和复用，类似软件开发中“面向服务的体系架构”的概念。
下面根据前人的总结和我自己的理解，简单描述下典型中台的三种分类：1）数据中台数据中台大多数情况都是作为BI产品的基础，无论是面向外界的服务类产品还是服务于本身企业的内部工具，数据中台存在的意义就是整合和规范数据，方便业务方基于标准和统一的数据规范进行二次开发。
2）技术中台顾名思义，这类中台主要是服务于技术人员的；对于业务方来说，除了服务稳定性和接入方式，对原本的业务流程是没有任何影响的，理论上最前端的业务人员是没有任何感知的。
开发同学的工作也可以简单概括为：抽象出可复用的功能模块（接口），方便各个业务端快速的自主化配置并按需调用。
3）业务中台这类中台就是产品同学感知最强的中台类型了，业务中台的搭建需要产品同学深刻地理解不同业务线之间的共性及差异，从上至下地推动业务中台的搭建。
用业务的语言去描述我们期望搭建的组织能力，比如支付能力，直播能力，用户管理能力等等。
如果用造房子来类比三种中台之间的差异：“数据中台”是给你标准的砖块，水泥，钢筋，让你自己动手去建筑；“技术中台”是给你一块块复合板材，你要做的事情和搭积木一样，把他们按照标准装配到一起；“业务中台”则是给你一个个标准户型的房间，你只需要决定我要用到哪几个房间就可以了。
贝壳找房组织架构 -回复
贝壳找房组织架构-回复贝壳找房是中国领先的房产在线交易平台，为用户提供全面的房产信息搜索、交易服务，以及在线房屋租赁等解决方案。
作为一个快速发展的互联网公司，贝壳找房的组织架构是一个关键的组成部分，影响着公司的运营效率和发展方向。
下面将以中括号内的内容为主题，逐步探讨贝壳找房的组织架构。
1. 什么是组织架构？组织架构是一个企业或组织在人力资源管理方面的重要组成部分，它定义了不同层级的职责、权限和关系，并为组织提供了一个清晰的运作框架。
2. 贝壳找房的组织架构是什么样的？贝壳找房的组织架构分为多个部门和团队，以实现高效的业务运营和快速的决策执行。
下面是贝壳找房的主要组织架构：2.1 高层领导团队贝壳找房的高层领导团队由总裁和副总裁组成，他们负责制定公司的战略方向和业务规划，并监督公司的整体运营和发展。
2.2 业务部门贝壳找房的业务部门是公司的核心，它们负责不同的业务线，包括房产信息搜索、在线交易和房屋租赁等。
每个业务部门由一个部门经理领导，负责该部门的运作和目标实现。
2.3 技术团队作为一个互联网公司，技术团队在贝壳找房的组织架构中起着重要的作用。
技术团队负责开发和维护公司的核心技术平台，包括房屋信息数据库、交易系统和搜索引擎等。
技术团队由多个子团队组成，如产品开发、前端开发和后台开发等。
2.4 运营团队贝壳找房的运营团队负责市场营销、用户支持和客户关系管理等工作。
运营团队与业务部门和技术团队紧密合作，确保公司运作的顺利和用户满意度的提高。
2.5 市场部门贝壳找房的市场部门负责制定市场推广策略，提升公司的品牌知名度和市场份额。
市场部门负责营销活动、品牌建设和媒体关系等工作。
2.6 数据分析团队数据分析团队负责收集、分析和解读大数据，为公司的决策提供支持。
他们利用数据分析工具和技术，提取有价值的信息，帮助公司更好地了解客户需求和市场趋势。
3. 如何实现组织架构的有效管理和协调？为了实现组织架构的有效管理和协调，贝壳找房采取了以下措施：3.1 设立公司目标和绩效指标贝壳找房制定了明确的公司目标和绩效指标，将其分解到不同部门和团队，并通过定期评估和反馈机制确保各个部门和团队的工作与战略目标保持一致。
产品分析报告 贝壳找房App以及互联网房产服务行业
产品分析报告| 贝壳找房App以及互联网房产服务行业编辑导语：随着生活水平的不断进步以及互联网的持续发展，找房行业也与互联网相结合，冒出不少互联网房产服务的平台；本文是关于“贝壳找房”的深度剖析以及分析互联网房产服务行业的运转逻辑，我们一起来看一下。
贝壳找房是一款房产租赁与买卖交易服务平台，通过继承链家的线下房源数据，与三方公寓和中介合作，为广大用户提供海量且真实的房源，旨在解决用户租房、买房、卖房的难题。
自2018年创立以来，势如破竹，发展迅速；2019年成交额达到21277亿元，并已于2020年8月IPO上市。
本文以贝壳找房APP为切入点，深入剖析贝壳以及互联网房产服务行业的运转逻辑。
将从下列几个方面进行分析：1.行业分析2.竞品分析3.用户价值分析4.商业价值分析5.产品迭代分析6.产品结构分析7.运营分析8.总结一、行业分析房产服务是指房地产各个环节中为当事人提供服务的经营活动。
随着居民的收入增加，生活水平上升，进一步的城镇化发展，买房卖房租房依旧火热；在对线下中介信任不足的大环境下，线上的大型房产服务平台开始涌现，旨在为用户提供优质房源信息等综合服务。
自2014年以来，互联网房产服务行业突飞猛进，而房地产行业往往受宏观政策因素影响，接下来用PEST模型来分析一下。
1. 政策层面我国的城镇化率的进一步提升和货币信贷环境宽松，且地方楼市政策略有放宽，继续推动房产行业在疫情后的回暖复苏。
具体体现在，2019年全国城镇化仅60.6%，置业需求随人口迁移仍有上升空间；中央经济工作会议表明2020年全国货币信贷将比2019年增长提升，同时因城施策下更多城市的政策有一定的放宽，帮助房产行业稳定发展。
2. 经济层面据经济学家任泽平的测算，中国住房地产2018年总市值321万亿元，相当于美国的2.4倍；其中每年有6万多亿元价值的住宅换手、12-13万亿元的新房卖出，再加上租房，就是一年25万亿元成交额的大市场。
Python手拉手教你爬取贝壳房源数据的实战教程
Python⼿拉⼿教你爬取贝壳房源数据的实战教程⽬录⼀、爬⾍是什么？⼆、使⽤步骤1.引⼊库2.读⼊数据3.随机选择⼀个ip地址构建代理服务器4.运⾏代码总结⼀、爬⾍是什么？在进⾏⼤数据分析或者进⾏数据挖掘的时候，数据源可以从某些提供数据统计的⽹站获得，也可以从某些⽂献或内部资料中获得，但是这些获得数据的⽅式，有时很难满⾜我们对数据的需求，⽽⼿动从互联⽹中去寻找这些数据，则耗费的精⼒过⼤。
此时就可以利⽤爬⾍技术，⾃动地从互联⽹中获取我们感兴趣的数据内容，并将这些数据内容爬取回来，作为我们的数据源，从⽽进⾏更深层次的数据分析，并获得更多有价值的信息。
在使⽤爬⾍前⾸先要了解爬⾍所需的库（requests）或者( urllib.request )，该库是为了爬取数据任务⽽创建的。
⼆、使⽤步骤1.引⼊库代码如下（⽰例）：import osimport urllib.requestimport randomimport timeclass BeikeSpider:def __init__(self, save_path="./beike"):"""贝壳爬⾍构造函数:param save_path: ⽹页保存⽬录"""2.读⼊数据代码如下：# ⽹址模式self.url_mode = "http://{}/loupan/pg{}/"# 需爬取的城市self.cities = ["cd", "sh", "bj"]# 每个城市爬取的页数self.total_pages = 20# 让爬⾍程序随机休眠5-10秒self.sleep = (5, 10)# ⽹页下载保存根⽬录self.save_path = save_path# 设置⽤户代理，是爬⾍程序伪装成浏览器self.headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36"} # 代理IP的信息self.proxies = [{"https": "123.163.67.50:8118"},{"https": "58.56.149.198:53281"},{"https": "14.115.186.161:8118"}]# 创建保存⽬录if not os.path.exists(self.save_path):os.makedirs(self.save_path)def crawl(self):"""执⾏爬取任务:return: None"""该处使⽤的url⽹络请求的数据。
贝壳找房搜索架构演进
•业务垂直拆分 •引入入分布式事务 •代码量量拆分 •单个资源进行行行拆分
回顾&未来发展
1. ⻉贝壳找房 2. ⻉贝壳搜索的场景 3. 搜索架构的迭代 4. 架构的思考
Cost-Oriented Architecture Design 资源隔离、弹性服务
Thanks
elasticsearch 插件 索引备份 索引恢复
缓存层
DA SUG NLU 纠错
人人工工 干干预 相关召回 策略略 扩大大召回 召回
规则特征 个性化 LTR
DIG采集 北北极星 日日志采集 效果分析 A/B流量量 搜索回放 全局ID 人人工工评测
用用户画像 会话保持 实时画像
实时模型 离线模型
mysql mongo kafka zookeeper redis hadoop 数仓 指标平台 DataPipeline clickhouse
• 调用用混乱 – IP直连 – 谁在使用用这个服务？
• 扩展性差 – Lucene本地索引，机器器强依赖 – 搜索、索引服务在同一一机器器 – 索引数据不不一一致
管理理流程 技术架构
⻉贝壳找房-搜索V2(2016~2017)
Dig埋点
效果流
Log
采集
ETL
计算
输出
Kafka
Hive
数据模型
业务数据
2016
2017
2018
12,000,000,000 9,500,000,000 7,000,000,000 4,500,000,000 2,000,000,000
2016
月月hits
2017
2018
搜索服务-基本构成
DB 文文件
人人工工录入入
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
稳定性99.99%的挑战
ES引擎稳定性保障
27
稳定性99.99%的挑战
慢查询预测熔断
28
稳定性99.99%的挑战
网关自动降级
ü 1、手动 & 自动 ü 2、单业务 & 全分组 ü 3、默认连续3分钟报错比例超过10%，
自动打开网关降级
ü 4、时间、阈值动态调整 ü 5、一级缓存返回历史查询结果 ü 6、二级缓存返回默认结果 ü 7、C端用户基本无感知 ü 8、争取故障修复时间，影响降到最低
基于ES构建贝壳找房搜索中台
1
提纲
1 ES在贝壳的使用情况 2 贝壳搜索中台演化之路 3 稳定性99.99%的挑战 4 未来规划
2
3
ES在贝壳的使用情况
使用场景
• 贝壳、链家主搜 • C端、B端、内部 • 二手、新房、租赁 • 房源、客源、推荐 • 共支持350多个业务线 • 最核心服务之一
4
• 敬畏心，不犯低级错误 • 责任感，全面性
30
提纲
1 ES在贝壳的使用情况 2 贝壳搜索中台演化之路 3 稳定性99.99%的挑战 4 未来规划
31
未来规划 沉淀可定制的通用
搜索解决方案
32
29
稳定性99.99%的挑战
总结
监控报警
• 重视监控报警，专人专项 • 精准报警，提前预警
墨菲定律
• 任何可能出现的故障都 必然出现
蝴蝶效应
• 配置审核，流程规范 • 重大变更，回滚策略
未雨绸缪
• 最坏打算，最好准备 • 风险预案，故障演练
包产到户
• 每个系统，每个子系统， 每个模块，责任到人
技术修养
ห้องสมุดไป่ตู้
• 流量大小变化 • 业务查询模式变化 • 流量结构变化
23
服务过多
• 600+微服务 • 依赖复杂，牵一发而动全身 • 定位困难，运维成本高
稳定性99.99%的挑战
解决方案
举几个优化点：
1、平滑上线：
微服务下线先从Euraka摘除节点，上线等待预热成 功后再注册到Euraka。优化后高峰上下线0报错。
宕机时间/周 16.8小时 1.68小时 10.1分钟 1.01分钟 6.05秒
宕机时间/天 2.4小时 14.4分钟 1.44分钟 8.66秒 0.87秒
22
稳定性99.99%的挑战
难点
业务敏感
流量变化
• 100+ 一级核心业务 • 搜索故障超过5分钟即可能造
成B级故障（严重）
• 超过20分钟升级为A级（重 大）
2、配置刷新优化：
优化spring cloud配置刷新机制，预先初始化上下 文后替换。防止重新加载配置时的短暂停顿。
3、重试优化：
层层重试会造成流量翻倍。优化ribbon重试机制， 过滤读超时重试，优化连接断开重试。优化后高峰 任意kill进程0报错。
4、推拉写入限速：
防止业务高峰期刷数据影响查询。
ES在贝壳的使用情况
使用规模
21套集群
300ES节点
1100 index 20亿数据
350业务 10亿查询/天 1亿写入/天 峰值3W/QPS 稳定性99.99%
5
提纲
1 ES在贝壳的使用情况 2 贝壳搜索中台演化之路 3 稳定性99.99%的挑战 4 未来规划
6
贝壳搜索中台演化之路
搜索 服务
贝壳搜索中台演化之路
搜索中台—查询层
Spring Cloud
19
贝壳搜索中台演化之路
搜索中台—引擎层 • 整体架构 • SolrCloud -> ES • 单集群 -> 多集群 • 单机房 -> 双机房 • 混布 -> 分组隔离 • 物理机部署 -> k8s + docker
• 部署效率提升10倍，资源使用率提升3倍 • 云平台
20
提纲
1 ES在贝壳的使用情况 2 贝壳搜索中台演化之路 3 稳定性99.99%的挑战 4 未来规划
21
稳定性99.99%的挑战
SLA 90% 99% 99.9% 99.99% 99.999%
宕机时间/年 36.5天 3.65天
8.76小时 52.56分钟 5.26分钟
宕机时间/月 72小时 7.20小时 43.8分钟 4.38分钟 25.9秒
搜索云平台
3倍 6倍
60%
业务接入效率提升 3倍
之前：平均9天 之后：平均3天
搜索RD人效提升6倍
之前：3人/日 之后：0.5人/日
故障率降低60%
之前：人工改配置误 操作造成6起线上故障
之后：0
15
贝壳搜索中台演化之路
搜索中台
16
贝壳搜索中台
云平台
17
贝壳搜索中台演化之路
搜索中台—数据流
18
24
稳定性99.99%的挑战
监控报警
25
稳定性99.99%的挑战
ES引擎稳定性保障
ü 1、双集群双机房备份 ü 2、查询自动熔断降级 ü 3、主备集群一键分流 ü 4、故障节点自动迁移 ü 5、每天定时快照备份 ü 6、基础监控报警 ü 7、慢查询监控报警 ü 8、慢查询统计巡检 ü 9、慢查询预测熔断
搜索 平台
搜索 云平台
搜索 中台
7
贝壳搜索中台演化之路
搜索服务
8
贝壳搜索中台演化之路
搜索平台
9
贝壳搜索中台演化之路
搜索云平台
10
贝壳搜索中台演化之路
搜索云平台
11
贝壳搜索中台演化之路
搜索云平台
12
贝壳搜索中台演化之路
搜索云平台
13
贝壳搜索中台演化之路
搜索云平台
14
贝壳搜索中台演化之路