基于Neo4j的《红楼梦》知识图谱构建与可视化实战

简介：本资源是一套面向知识图谱初学者与Python数据处理爱好者的《红楼梦》结构化知识建模实践包，聚焦中文文本知识抽取、Neo4j图数据库构建与可视化展示全流程。资源共7个文件，涵盖Neo4j数据库备份（.zbak）、实体关系三元组数据（CSV）、核心构建脚本（Python）、知识图谱静态展示图（PNG）、项目说明文档（MD）及配套资源压缩包，总大小仅1.62MB，轻量易部署，适合教学演示、课程实验或个人知识工程入门实践。已有160人学习下载，用户可直接导入Neo4j查看完整人物关系网络，复现从原始文本到图谱落地的关键步骤；HLM.py脚本封装了基础导入逻辑，README.md清晰说明环境配置与操作路径，triples.csv提供可验证的结构化数据源，降低学习门槛并支持二次开发与关系扩展。

1. 项目概述：当古典名著遇见现代图数据库

如果你和我一样，既是个《红楼梦》的爱好者，又是个对数据技术着迷的开发者，那你肯定想过一个问题：这部人物关系错综复杂、情节千丝万缕的鸿篇巨著，能不能用一种更直观、更“现代”的方式来解读和探索？传统的阅读方式，让我们在脑海中构建关系网，但曹雪芹笔下那四百多号人物，谁是谁的亲戚，谁和谁有过节，谁又影响了谁的命运，光靠记忆和笔记，实在太容易混乱了。这正是我启动“红楼梦知识图谱展示”项目的初衷——用Neo4j图数据库，为这部古典名著构建一个数字化的“人物关系宇宙”。

简单来说，这个项目就是利用知识图谱技术，将《红楼梦》中的人物、地点、事件、物品等实体，以及它们之间复杂的关系（如亲属、仆从、敌对、爱慕、赠予等），结构化地存储进Neo4j数据库。然后，通过一个前端界面，我们可以像探索星空图一样，可视化地查询、浏览和分析这些关系。这不仅仅是把书数字化，而是将其内在的、隐性的知识网络显性化、结构化。对于红学研究，它可能是一种新的分析工具；对于文学爱好者，它是一个强大的互动阅读辅助；对于技术学习者，它则是一个绝佳的、有文化内涵的实战案例，涵盖了从数据建模、ETL处理到可视化展示的全链路。

最近“RAG（检索增强生成）”和“LLM（大语言模型）”火得一塌糊涂，知识图谱作为精准结构化知识的代表，正是提升大模型回答准确性、减少“幻觉”的关键技术之一。用《红楼梦》这种家喻户晓的IP来练手，理解实体、关系、属性的三元组建模思想，再亲手用Neo4j把它实现出来，其学习价值远超一个枯燥的“用户-商品”推荐demo。接下来，我就把自己从零搭建这个项目的完整思路、踩过的坑以及核心实现细节，毫无保留地分享给你。

2. 核心设计：如何为《红楼梦》构建知识图谱模型

为一部小说构建知识图谱，第一步也是最关键的一步，就是设计数据模型。模型设计得好，后续的查询和分析才能高效、直观。这不像处理业务数据表，有现成的范式可以套用，它更需要我们对领域（即《红楼梦》本身）有深入的理解，并进行一次创造性的抽象。

2.1 实体与关系定义：抽象出《红楼梦》的世界

我的核心设计原则是：“人”为核心，“事”为纽带，“物”为点缀。所有实体和关系都围绕人物展开，因为小说的灵魂就是人物及其互动。

1. 实体类型设计：我主要定义了以下几类实体节点，并为它们打上了相应的标签（Label）：

• 人物（Person）：这是绝对的核心。每个人物节点包含属性如：name（姓名，如“贾宝玉”）、alias（别名/字号，如“怡红公子”）、generation（辈分，如“玉”字辈）、gender（性别）、intro（简要介绍）。
• 家族（Family）：代表书中的几大家族，如“贾家”、“史家”、“王家”、“薛家”。属性包括family_name。
• 地点（Location）：包括具体居所（如“怡红院”、“潇湘馆”）、建筑（如“大观园”、“荣禧堂”）和地理概念（如“金陵”、“长安”）。
• 事件（Event）：重要的情节单元，如“宝玉挨打”、“元妃省亲”、“黛玉葬花”。属性包括title（事件名）、chapter（出自第几回）。
• 物品（Item）：具有象征意义或推动情节的关键物品，如“通灵宝玉”、“金锁”、“海棠诗社的帖子”。

2. 关系类型设计：关系是知识图谱的“边”，它让静态的实体活起来。我定义了多种关系类型：

• 亲属关系：如:FATHER_OF（贾政-贾宝玉）、:MOTHER_OF（王夫人-贾宝玉）、:SPOUSE_OF（贾琏-王熙凤）、:SIBLING_OF（贾宝玉-贾环）。
• 社会关系：如:SERVES（袭人-贾宝玉，表示“服侍”）、:MASTER_OF（贾母-鸳鸯，表示“是...的主人”）、:FRIEND_WITH（贾宝玉-秦钟）。
• 情感关系：如:LOVES（贾宝玉-林黛玉）、:APPRECIATES（贾宝玉-晴雯）。
• 从属关系：如:BELONGS_TO（贾宝玉-贾家）、:LIVES_IN（林黛玉-潇湘馆）。
• 事件关联：如:PARTICIPATED_IN（贾宝玉-宝玉挨打）、:OCCURRED_AT（元妃省亲-大观园）。
• 物品关联：如:OWNS（贾宝玉-通灵宝玉）、:MENTIONED_IN（螃蟹宴-菊花诗）。

设计心得：关系类型的设计不必一开始就求全。我从最核心的亲属和社会关系入手，在后续的数据处理和查询过程中，发现新的需要再补充。例如，最初没有“敌对”关系，但在分析“赵姨娘与王熙凤”时，觉得有必要，就增加了:CONFLICT_WITH。

2.2 属性与图结构规划

属性附着在实体和关系上，用于描述其特征。对于“人物”节点，name是唯一标识，必须建立唯一性约束。对于关系，也可以有属性，比如:PARTICIPATED_IN关系可以有role（角色）属性，描述某人在该事件中是“主导者”、“受害者”还是“旁观者”。

图结构规划决定了数据如何连接。我采用的是“星型”与“链式”结合的混合结构。以一个人物节点为中心，可以放射出连接家族、地点、物品和其他人物的多条边，形成星型。而通过事件节点，可以将多个相关人物串联起来，形成链式或网状结构。这种混合结构能很好地平衡查询效率与建模灵活性。

2.3 工具选型：为什么是Neo4j？

市面上图数据库不止Neo4j，还有JanusGraph、Nebula Graph等。我选择Neo4j社区版作为核心存储和计算引擎，基于以下几点考量：

1. 成熟与生态：Neo4j是图数据库领域的开创者和领导者，文档、社区、客户端驱动都非常完善。遇到问题，很容易找到解决方案。
2. Cypher查询语言：这是Neo4j的灵魂，声明式的语法非常直观，用于表达图模式匹配就像用英语句子描述关系一样自然。例如，查找“贾宝玉的所有兄弟姐妹”可以写成MATCH (p:Person {name:'贾宝玉'})-[:SIBLING_OF]-(sib) RETURN sib，学习成本低，表达力强。
3. 全栈解决方案：Neo4j不仅提供数据库引擎，还有Neo4j Browser（一个内置的可视化查询工具）、Neo4j Bloom（更友好的业务人员探索工具）以及丰富的APOC（Awesome Procedures On Cypher）插件库，为数据导入、算法分析和可视化提供了极大便利。
4. 对《红楼梦》这类场景的契合度：我们处理的是高度连接、关系多变、需要频繁进行多跳查询的数据。例如，“找出与林黛玉在三跳关系内所有的人物，并按亲密度排序”，这类查询在关系型数据库中需要复杂的递归JOIN，而在Neo4j中则非常高效直观。

前端展示方面，我选择了ECharts的关系图（graph）组件，并结合Neo4j的官方JavaScript驱动。这样，后端可以用任何语言（我选用Python Flask）作为API层，从Neo4j中执行Cypher查询，将结果（节点和边列表）返回给前端，再由ECharts渲染成可交互的力导向图。这个组合轻量、灵活且可控性强。

3. 数据获取、清洗与导入：从文本到图谱的“炼金术”

有了模型，下一步就是喂数据。这是个体力活，也是决定图谱质量的基石。原始数据主要来源于《红楼梦》原著文本以及一些整理好的研究资料。

3.1 数据来源与预处理

我的数据源主要有两个：

1. 结构化数据：从一些公开的红楼梦研究网站和GitHub项目中，找到了部分人物关系CSV文件。这些文件通常包含“人物A”、“关系”、“人物B”三列。这是最优质的数据源，但通常不完整，且关系定义可能与我的模型有出入。
2. 非结构化文本：即《红楼梦》120回原文的txt版本。这是最原始、最全面的数据源，但需要从中提取实体和关系，挑战最大。

预处理的关键步骤：

• 人名归一化：书中人物常有多个称呼（如“黛玉”、“颦儿”、“林妹妹”）。必须建立一个“标准名-别名”映射字典，将所有别名都归并到我们定义的实体节点上。这是保证数据一致性的生命线。
• 关系标准化：从不同来源获得的关系描述可能五花八门（如“父亲”、“爹爹”、“爸”）。需要制定一个关系词汇表，将这些描述映射到我们定义的关系类型（如:FATHER_OF）。
• 文本分句与标注：对于原著文本，我使用jieba分词并进行简单的人名实体识别（基于已知人物名列表）。然后按句号、感叹号等切分成单句，因为一个句子通常描述一个核心事件或关系。

3.2 基于规则与简单NLP的关系抽取

对于非结构化文本，完全手动标注不现实。我采用“规则为主，简单模型为辅”的半自动化策略：

1. 模式匹配：针对常见关系编写正则表达式或模式。例如：
   • 亲属关系：r”(.+?)是(.+?)的(.+?)”可以匹配 “贾政是贾宝玉的父亲”。
   • 居住关系：r”(.+?)住在(.+?)”可以匹配 “林黛玉住在潇湘馆”。
2. 依存句法分析：使用HanLP或LTP等工具对句子进行依存句法分析。通过分析“主谓宾”、“定中”等结构，可以更准确地提取“施事-关系-受事”三元组。例如，分析“贾宝玉疼爱林黛玉”这句话，可以识别出“贾宝玉”是核心主语（施事），“疼爱”是谓语（关系），“林黛玉”是宾语（受事）。
3. 人工校验与补充：自动化抽取的结果必然存在大量错误和遗漏。我专门花了时间，针对前二十回的重要情节进行人工阅读和标注，一方面修正错误，另一方面也为后续优化抽取规则提供样本。

踩坑实录：初期我过于依赖简单的字符串匹配，闹了不少笑话。比如，“薛宝钗的丫头莺儿”被错误地抽成了“薛宝钗”和“丫头莺儿”是两个人，并建立了:OWNS关系。实际上“丫头莺儿”应该作为一个整体“莺儿”，与薛宝钗建立:SERVES关系。这个坑告诉我，上下文理解和实体边界识别是关键，不能只看字面。

3.3 使用Cypher进行数据导入

数据整理成规范的CSV文件后，就可以使用Cypher的LOAD CSV命令导入Neo4j。这是非常高效的方式。

示例：导入人物节点首先，在Neo4j中创建约束和索引，提升查询效率和保证唯一性：

// 创建唯一性约束，确保人名不重复 CREATE CONSTRAINT unique_person_name IF NOT EXISTS FOR (p:Person) REQUIRE p.name IS UNIQUE; // 为其他常用查询字段创建索引 CREATE INDEX family_name_index IF NOT EXISTS FOR (f:Family) ON (f.family_name); CREATE INDEX location_name_index IF NOT EXISTS FOR (l:Location) ON (l.name);

然后，导入人物数据。假设有persons.csv文件，包含name,alias,generation等列。

LOAD CSV WITH HEADERS FROM 'file:///persons.csv' AS row MERGE (p:Person {name: row.name}) SET p.alias = row.alias, p.generation = row.generation, p.gender = row.gender, p.intro = row.intro;

这里使用MERGE（合并）操作，如果节点不存在则创建，存在则更新（通过SET）。这可以避免重复导入。

示例：导入关系假设有relationships.csv文件，包含person_a,relationship,person_b三列。

LOAD CSV WITH HEADERS FROM 'file:///relationships.csv' AS row MATCH (a:Person {name: row.person_a}) MATCH (b:Person {name: row.person_b}) CALL apoc.create.relationship(a, row.relationship, {}, b) YIELD rel RETURN count(rel);

这里使用了APOC库中的apoc.create.relationship过程，它可以动态地根据CSV中的关系类型字段创建关系。使用前需要确保APOC插件已正确安装并启用。

对于复杂的关系（如事件参与），可能需要先创建事件节点，再将人物与之关联。这通常需要多个CSV文件和按顺序执行的Cypher语句。

4. Cypher查询实战：探索红楼关系网络

数据入库后，最激动人心的部分就是使用Cypher进行探索性查询了。Neo4j Browser本身就是一个强大的交互式工具。下面分享几个典型查询场景，你可以直接复制到Neo4j Browser中运行。

4.1 基础查询：人物关系探查

查询1：查找特定人物的直接关系网

// 查找贾宝玉的直接亲属和仆人 MATCH (p:Person {name:'贾宝玉'})-[r]-(related) WHERE type(r) IN ['FATHER_OF', 'MOTHER_OF', 'SPOUSE_OF', 'SIBLING_OF', 'SERVES', 'MASTER_OF'] RETURN p, r, related;

这个查询会返回贾宝玉节点，所有与他有指定关系的节点，以及连接它们的关系。在Neo4j Browser的图形视图下，结果一目了然。

查询2：查找共同关联

// 找出林黛玉和薛宝钗共同认识的人（一度关系） MATCH (dl:Person {name:'林黛玉'})--(common)--(bc:Person {name:'薛宝钗'}) WHERE dl <> common AND bc <> common RETURN common.name AS common_friend, labels(common) AS type;

4.2 路径查询：挖掘隐藏的联系

图数据库最强大的能力之一就是查找路径。

查询3：查找两人之间的最短路径

// 贾母和刘姥姥之间最短的熟人关系路径是什么？ MATCH path = shortestPath((jm:Person {name:'贾母'})-[*..6]-(ll:Person {name:'刘姥姥'})) RETURN path;

[*..6]表示路径长度最多为6跳。这个查询能直观展示出两个看似不直接相关的人物是如何通过中间人联系起来的。

查询4：查找关系环或三角关系

// 找出存在“三角恋”或复杂情感关系的人物组（示例：A爱B，B爱C，C爱A或A也爱C） MATCH (a:Person)-[:LOVES]->(b:Person), (b)-[:LOVES]->(c:Person), (c)-[:LOVES]->(a) RETURN a.name, b.name, c.name;

这个查询能帮助发现小说中复杂的情感纠葛。

4.3 图算法应用：发现社区与关键人物

Neo4j通过GDS（Graph Data Science）库提供了丰富的图算法。社区版也包含一些基础算法。

查询5：使用度中心性（Degree Centrality）找出核心人物

// 计算每个人物的连接数（度），排序找出网络中最核心的人物 MATCH (p:Person) WITH p, size([(p)--() | 1]) AS degree RETURN p.name, degree ORDER BY degree DESC LIMIT 10;

这个简单的分析很可能显示贾宝玉、王熙凤、贾母是图中连接数最多的人物，这与他们在故事中的核心地位相符。

查询6：使用标签传播算法（Label Propagation）发现家族或派系

// 假设我们安装了APOC，可以使用其过程。先为每个节点设置一个初始唯一标签（ID） MATCH (p:Person) SET p.communityId = id(p); // 然后迭代执行标签传播（这是一个简化模拟，实际GDS库功能更强大） CALL apoc.algo.labelPropagation(['Person'], 'SERVES|FRIEND_WITH|SPOUSE_OF|SIBLING_OF', 'communityId') YIELD node, label SET node.community = label; // 查看社区分布 MATCH (p:Person) RETURN p.community, collect(p.name) AS members ORDER BY size(members) DESC;

这个算法可能会将荣国府、宁国府、贾府外围的亲戚朋友自然地划分到不同的社区中。

5. 前端可视化集成：让图谱“动”起来

一个只有后端查询的知识图谱是不完整的。我们需要一个前端界面，让用户能通过点击、搜索等方式直观地与图谱交互。

5.1 技术栈与架构设计

我采用了一个轻量级的架构：

• 后端：Python Flask。轻便灵活，负责提供RESTful API。
• 数据库：Neo4j Community Edition。使用官方neo4jPython驱动进行连接。
• 前端：HTML + JavaScript + ECharts。简单直接，ECharts的Graph组件非常适合力导向图展示。

工作流程是：用户在前端输入搜索（如“贾宝玉”），前端发送AJAX请求到Flask后端；Flask后端根据请求，组装对应的Cypher查询语句，通过驱动发送给Neo4j；Neo4j返回结果（节点和边列表）后，Flask将其整理成ECharts需要的格式（通常是一个包含nodes和links数组的JSON）返回给前端；前端ECharts接收数据并重新渲染图谱。

5.2 核心API与ECharts配置示例

Flask后端核心API端点：

from flask import Flask, request, jsonify from neo4j import GraphDatabase app = Flask(__name__) driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "your_password")) @app.route('/api/graph', methods=['GET']) def get_graph(): name = request.args.get('name', '贾宝玉') depth = int(request.args.get('depth', 2)) # 默认查询2度关系 def _get_graph(tx, person_name, depth): # 查询目标人物及其在指定深度内的关系和人物 query = """ MATCH path = (p:Person {name: $name})-[*1..%d]-(related) WITH p, collect(DISTINCT related) as related_nodes, [r in relationships(path) | {source: startNode(r).name, target: endNode(r).name, type: type(r)}] as rels RETURN p, related_nodes, rels """ % depth result = tx.run(query, name=person_name) record = result.single() return record with driver.session() as session: record = session.execute_read(_get_graph, name, depth) if record: # 构建ECharts数据格式 nodes = [] links = [] node_names = set() # 添加中心节点 center_node = record["p"] nodes.append({"id": center_node["name"], "name": center_node["name"], "category": "中心"}) node_names.add(center_node["name"]) # 添加相关节点 for node in record["related_nodes"]: if node["name"] not in node_names: nodes.append({"id": node["name"], "name": node["name"], "category": "相关"}) node_names.add(node["name"]) # 添加关系边 for rel in record["rels"]: links.append({"source": rel["source"], "target": rel["target"], "name": rel["type"]}) graph_data = {"nodes": nodes, "links": links} return jsonify(graph_data) else: return jsonify({"nodes": [], "links": []}) if __name__ == '__main__': app.run(debug=True)

前端ECharts初始化核心配置（JavaScript）：

function initChart(graphData) { const chartDom = document.getElementById('graph-container'); const myChart = echarts.init(chartDom); const option = { tooltip: {}, legend: { data: ['中心', '相关'] }, series: [{ type: 'graph', layout: 'force', // 力导向布局 data: graphData.nodes.map(node => ({ ...node, symbolSize: node.category === '中心' ? 40 : 20, // 中心节点更大 itemStyle: { color: node.category === '中心' ? '#ff6b6b' : '#4ecdc4' } })), links: graphData.links, categories: [{name: '中心'}, {name: '相关'}], roam: true, // 允许拖拽缩放 label: { show: true, position: 'right' }, force: { repulsion: 200, // 节点间斥力 edgeLength: 100, // 边的理想长度 gravity: 0.1 // 向心力，防止节点飞散 }, lineStyle: { color: 'source', curveness: 0.3 // 边带点弧度，更美观 }, emphasis: { // 高亮样式 focus: 'adjacency', lineStyle: { width: 3 } } }] }; myChart.setOption(option); // 监听图表点击事件，实现点击节点后查询该节点的新关系 myChart.on('click', function(params) { if (params.dataType === 'node') { fetchNewGraphData(params.data.name); } }); }

这样，一个支持点击交互、力导向布局的《红楼梦》知识图谱可视化界面就搭建起来了。用户可以通过搜索框查找人物，点击图中的任意节点，图谱会动态展开，显示该节点的新关系网络。

6. 部署、优化与常见问题排查

项目开发完成后，要让它持续稳定运行，还需要考虑部署和优化。

6.1 系统部署方案

对于个人学习或小范围演示，最简单的部署方式是：

1. 服务器：选择一台云服务器（如1核2G配置的Linux主机即可）。
2. 安装Neo4j：

   # 添加Neo4j官方仓库并安装 wget -O - https://debian.neo4j.com/neotechnology.gpg.key | sudo apt-key add - echo 'deb https://debian.neo4j.com stable latest' | sudo tee /etc/apt/sources.list.d/neo4j.list sudo apt-get update sudo apt-get install neo4j

3. 配置Neo4j：编辑配置文件/etc/neo4j/neo4j.conf，主要修改：

   # 允许远程Bolt连接（默认只允许本地） dbms.connector.bolt.listen_address=0.0.0.0:7687 # 允许远程HTTP连接（用于Browser） dbms.connector.http.listen_address=0.0.0.0:7474 # 设置初始密码 dbms.security.auth_enabled=true

   启动服务：sudo systemctl start neo4j。记得在云服务器安全组开放7474和7687端口。
4. 部署后端：将Flask应用部署到服务器，可以使用Gunicorn + Nginx。确保Flask应用的连接地址改为服务器的Neo4j地址。
5. 部署前端：将前端静态文件（HTML, JS, CSS）放到Nginx的静态文件目录下，或与Flask后端集成（使用render_template）。

6.2 性能优化与数据维护

随着数据量增长（比如加入所有章回情节、诗词、物品），查询可能会变慢。

• 索引优化：确保所有常用的查询条件（如Person.name,Event.title）都建立了索引或唯一约束。
• 查询优化：
  • 限制路径深度：在可变长度关系查询[*..n]中，n不要设置过大，3-5通常足够。
  • 尽早过滤：在MATCH语句中尽早使用属性过滤，减少中间结果集。例如MATCH (p:Person {name:'...'})比MATCH (p:Person) WHERE p.name='...'有时更优（因为利用了索引）。
  • 使用PROFILE：在Neo4j Browser中，在查询前加上PROFILE关键字（如PROFILE MATCH ...），可以查看查询执行计划，找到性能瓶颈（如全节点扫描）。
• 数据更新：建立定期或触发式更新机制。例如，当有新的研究数据（CSV）时，可以写一个Python脚本，自动执行一系列LOAD CSV和MERGE语句来增量更新图谱，而不是清空重导。

6.3 常见问题与排查实录

问题1：前端图表节点和边过多，重叠严重，看不清。

• 排查：这是力导向图布局的常见问题。查询返回的节点数过多（比如超过100个）。
• 解决：
  1. 限制查询深度：在API中，默认和最大查询深度不要超过3。
  2. 前端布局参数调优：调整ECharts中force.repulsion（斥力）和force.gravity（重力）参数。增大斥力让节点分散，适当增加重力让图更紧凑。
  3. 聚合显示：对于大型查询，可以先只显示主要人物（如度中心性高的），提供“展开更多”的交互。

问题2：Cypher查询返回很慢，尤其是涉及多跳关系的查询。

• 排查：使用PROFILE查看执行计划。常见问题是缺少索引，导致需要遍历所有节点。
• 解决：
  1. 确认相关标签的属性已创建索引。CREATE INDEX index_name IF NOT EXISTS FOR (p:Person) ON (p.generation)。
  2. 检查查询语句，避免在WHERE子句中对未索引的属性进行函数操作（如WHERE toLower(p.name) = 'jia baoyu'），这会使得索引失效。
  3. 考虑对非常深且固定的关系路径（如家族谱系），是否可以用更直接的父子关系属性来优化，而非全部用边表示。

问题3：数据导入时，LOAD CSV报错“无法打开文件”。

• 排查：Neo4j的LOAD CSV默认从服务器的特定导入目录（通常是<neo4j-home>/import/）读取文件。
• 解决：将CSV文件放入Neo4j服务器上的import目录，并在Cypher中使用file:///路径。例如，文件放在/var/lib/neo4j/import/persons.csv，则Cypher中路径为LOAD CSV FROM 'file:///persons.csv' ...。确保Neo4j进程有该文件的读取权限。

问题4：前端点击查询后，图表闪烁或重新布局体验不佳。

• 排查：每次查询都返回全新数据，ECharts实例完全重新渲染。
• 解决：采用“增量合并”策略。新的查询结果返回后，不是替换整个graphData，而是将新节点和边与现有数据合并。对于已存在的节点，保留其位置信息（可以存储在节点的x,y属性中）。ECharts的setOption方法支持传入merge参数，可以实现平滑过渡。这需要前后端配合，后端在返回数据时，可以标记哪些是新增节点。

本文还有配套的精品资源，点击获取