作者：关涛、李睿博、孙莉莉、张良模、贾扬清 （from 阿里云智能计算平台) 黄波、金玉梅、于茜、刘子正 （from 新浪微博机器学习研发部)
近几年，随着数据湖概念的兴起，业界对于数据仓库和数据湖的对比甚至争论始终不断。数据仓库和数据湖的区别到底是什么？本文作者来自阿里巴巴计算平台部门，在深度参与阿里巴巴大数据 / 数据中台领域建设之后，将对数据湖和数据仓库的来龙去脉进行深入剖析，阐述两者融合演进的新方向——湖仓一体。
大数据 20 年发展的变与不变
概述
大数据从本世纪初发展到现在，已经历 20 年。从宏观层面观察其中的发展规律，可以高度概括成如下五个方面：
图 1. 阿里巴巴双十一单日处理数据量增长
- 数据保持高速增长
- 大数据作为新的生产要素，得到广泛认可
- 数据管理能力成为新的关注点
- 引擎技术进入收敛期
- 平台技术演进出两个趋势，数据湖 VS 数据仓库。两者均关注数据存储和管理（平台技术），但方向不同。
从大数据技术发展看湖和仓
纵观大数据的发展历史，可以看出数据仓库和数据湖有着截然不同的发展脉络。大体上，计算机科学领域的数据处理技术的发展，主要分为四个阶段：
阶段一：数据库时代。数据库最早诞生于 20 世纪的 60 年代，今天人们所熟知的关系型数据库则出现在 20 世纪 70 年代，并在后续的 30 年左右时间里大放异彩，诞生了很多优秀的关系型数据库，如 Oracle、SQL Server、MySQL、PostgresSQL 等，成为当时主流计算机系统不可或缺的组成部分。到 20 世纪 90 年代，数据仓库的概念诞生。此时的数据仓库概念更多表达的是如何管理企业中多个数据库实例的方法论，但受限于单机数据库的处理能力以及多机数据库（分库分表）长期以来的高昂价格，此时的数据仓库距离普通企业和用户都还很遥远。人们甚至还在争论数据仓库（统一集中管理）和数据集市（按部门、领域的集中管理）哪个更具可行性。
阶段二：大数据技术的「探索期」。2000 年左右，随着互联网的爆发，动辄几十亿、上百亿的页面以及海量的用户点击行为，开启了全球的数据量急剧增加的新时代。传统的数据库方案再也无力以可接受的成本提供计算力，巨大的数据处理需求开始寻找突破口，大数据时代开始萌芽。Google 先后发表 3 篇经典论文（GFS、MapReduce、BigTable），奠基了这个大数据时代的基本技术框架，即分布式存储、分布式调度以及分布式计算模型。随后，几乎是在同一时期，诞生了包括 Google，微软 Cosmos 以及开源 Hadoop 为代表的优秀分布式技术体系，当然，这其中也包括阿里巴巴的飞天系统。此时人们兴奋于追求数据的处理规模，即『大』数据，没有闲暇争论是数据仓库还是数据湖。
阶段三：大数据技术的「发展期」。21 世纪第二个 10 年，随着越来越多的资源投入到大数据计算领域，大数据技术进入一个蓬勃发展的阶段，整体开始从能用转向好用。代替手写 MapReduce 作业，是如雨后春笋般出现的各种以 SQL 为表达的计算引擎，极大降低了大数据技术的使用成本，数据库时代人们梦想的大一统的数据仓库终于成为现实，各种数据库时代的方法论开始抬头。这个时期技术路线开始出现细分。云厂商主推的如 AWS Redshift、Google BigQuery，包括 MaxCompute 这样的集成系统称为大数据时代的数据仓库。而以开源 Hadoop 体系为代表的的开放式 HDFS 存储、开放的文件格式、开放的元数据服务以及多种引擎（Hive、Presto、Spark、Flink 等）协同工作的模式，则形成了数据湖的雏形。
阶段四：大数据技术「普及期」。当前，大数据技术早已不是什么火箭科技，而已经渗透到各行各业，大数据的普及期已经到来。市场对大数据产品的要求，除了规模、性能、简单易用，提出了成本、安全、稳定性等更加全面的企业级生产的要求。
开源 Hadoop 线，引擎、元数据、存储等基础部件的迭代更替进入相对稳态，大众对开源大数据技术的认知达到空前的水平。一方面，开放架构的便利带来了不错的市场份额，另一方面开放架构的松散则使开源方案在企业级能力构建上遇到瓶颈，尤其是数据安全、身份权限强管控、数据治理等方面，协同效率较差。同时引擎自身的发展也对已有的开放架构提出了更多挑战，Delta Lake、Hudi 这样自闭环设计的出现使得一套存储、一套元数据、多种引擎协作的基础出现了某种程度的裂痕。
真正将数据湖概念推而广之的是 AWS。AWS 构筑了一套以 S3 为中心化存储、Glue 为元数据服务，E-MapReduce、Athena 为引擎的开放协作式的产品解决方案。它的开放性和开源体系类似，并在 2019 年推出 Lake Formation 解决产品间的安全授信问题。这套架构对于开源技术体系的用户来说，架构相近理解容易，仍然相当有吸引力。AWS 之后，各个云厂商也纷纷跟进数据湖的概念，并在自己的云服务上提供类似的产品解决方案。
云厂商主推的数据仓库类产品则发展良好，数仓核心能力方面持续增强。性能、成本方面极大提升（如 MaxCompute 连续三年刷新 TPCx-BigBench 世界记录），数据管理能力空前增强（发展出数据中台建模理论和智能数仓），企业级安全能力大为繁荣（如细粒度数据安全控制、服务可用性 SLA 等），在联邦计算方面也普遍做了增强，一定程度上开始将非数仓自身存储的数据纳入管理，和数据湖的边界日益模糊。
综上所述，数据仓库和数据湖是伴随着大数据技术发展，进化而来的两种不同的大数据平台技术，有着各自的特点和应用场景，在企业数字化建设中均扮演着重要的角色。
图 2. 20 年大数据发展之路
数据湖的本质和技术架构演进
近几年数据湖的概念非常火热，各家对数据湖的定义不尽相同，但不论如何，数据湖的本质其实都包含如下四部分：
- 统一的存储系统
- 存储原始数据
- 丰富的计算模型 / 范式
- 数据湖与上云无关
从上述四个标准判断，开源大数据的 Hadoop HDFS 存储系统就是一个标准的数据湖架构，具备统一的原始数据存储架构。而近期被广泛谈到的数据湖，其实是一个狭义的概念，特指“基于云上托管存储系统的数据湖系统，架构上采用存储计算分离的体系”。例如基于 AWS S3 系统或者阿里云 OSS 系统构建的数据湖。
下图是数据湖技术架构的演进过程，整体上可分为三个阶段：
图 3. 数据湖技术架构演进
阶段一：自建开源 Hadoop 数据湖架构，原始数据统一存放在 HDFS 系统上，引擎以 Hadoop 和 Spark 开源生态为主，存储和计算一体。缺点是需要企业自己运维和管理整套集群，成本高且集群稳定性差。
阶段二：云上托管 Hadoop 数据湖架构（即 EMR 开源数据湖），底层物理服务器和开源软件版本由云厂商提供和管理，数据仍统一存放在 HDFS 系统上，引擎以 Hadoop 和 Spark 开源生态为主。这个架构通过云上 IaaS 层提升了机器层面的弹性和稳定性，使企业的整体运维成本有所下降，但企业仍然需要对 HDFS 系统以及服务运行状态进行管理和治理，即应用层的运维工作。同时因为存储和计算耦合在一起，两种资源无法独立扩展。
阶段三：云上数据湖架构，即云上纯托管的存储系统逐步取代 HDFS，成为数据湖的存储基础设施，并且引擎丰富度也不断扩展。除了 Hadoop 和 Spark 的生态引擎之外，各云厂商还发展出面向数据湖探查分析产品。这个架构仍然保持了一个存储和多个引擎的特性，相对于原生 HDFS 的数据湖架构的优势在于：
帮助用户摆脱原生 HDFS 系统运维困难的问题。分离后的存储系统可以独立扩展，不再需要与计算耦合，可降低整体成本当用户采用数据湖架构之后，客观上也帮助客户完成了存储统一化（解决多个 HDFS 数据孤岛的问题）。
图 4. 阿里云 EMR 数据湖架构
数据仓库的诞生及与数据中台的关系
数据仓库的概念最早来源于数据库领域，主要处理面向数据的复杂查询和分析场景。随着大数据技术发展，大量借鉴数据库的技术，例如 SQL 语言、查询优化器等，形成了大数据的数据仓库，因其强大的分析能力，成为主流。近几年，数据仓库和云原生技术相结合，又演生出了云数据仓库，解决了企业部署数据仓库的资源供给问题。云数据仓库作为大数据的高阶（企业级）平台能力，因其开箱即用、无限扩展、简易运维等能力，越来越受到人们的瞩目。
笔者认为，数据仓库的本质包含如下三部分：
- 内置的存储系统，数据通过抽象的方式提供（例如采用 Table 或者 View），不暴露文件系统；
- 数据需要清洗和转化，通常采用 ETL/ELT 方式；
- 强调建模和数据管理，供商业智能决策。
从上述的标准判断，无论传统数据仓库还是新兴的云数据仓库系统（AWS Redshift、Google BigQuery、阿里云 MaxCompute）均体现了数仓的设计本质，它们均没有对外暴露文件系统，而是提供了数据进出的服务接口。这个设计可以带来多个优势：
- 引擎深度理解数据，存储和计算可做深度优化
- 数据全生命周期管理，完善的血缘体系
- 细粒度的数据管理和治理
- 完善的元数据管理能力，易于构建企业级数据中台
正因为如此，阿里巴巴飞天大数据平台建设之初，在选型的时候就采用了数据仓库的架构，即 MaxCompute 大数据平台。MaxCompute（原 ODPS) 既是阿里巴巴经济体的大数据平台，又是阿里云上的在线大数据计算服务（百度搜索阿里云官网 - 左侧大数据与人工智能选择 MaxCompute）。
图 5. MaxCompute 云数仓产品架构
得益于 MaxCompute 数据仓库的架构，阿里巴巴上层逐步构建了“数据安全体系”、“数据质量”、“数据治理”、“数据标签”等管理能力，并最终形成了阿里巴巴的大数据中台。可以说，作为最早数据中台概念的提出者，阿里巴巴的数据中台得益于数据仓库的架构。
图 6. 阿里巴巴数据中台架构
数据湖 VS 数据仓库
综上，数据仓库和数据湖，是大数据架构的两种设计取向。两者在设计的根本分歧点是对包括存储系统访问、权限管理、建模要求等方面的把控。
数据湖优先的设计，通过开放底层文件存储，给数据入湖带来了最大的灵活性。进入数据湖的数据可以是结构化的，也可以是半结构化的，甚至可以是完全非结构化的原始日志。另外，开放存储给上层的引擎也带来了更多的灵活度，各种引擎可以根据自己针对的场景随意读写数据湖中存储的数据，而只需要遵循相当宽松的兼容性约定（这样的松散约定当然会有隐患，后文会提到）。但同时，文件系统直接访问使得很多更高阶的功能很难实现，例如，细粒度（小于文件粒度）的权限管理、统一化的文件管理和读写接口升级也十分困难（需要完成每一个访问文件的引擎升级，才算升级完毕）。
而数据仓库优先的设计，更加关注的是数据使用效率、大规模下的数据管理、安全 / 合规这样的企业级成长性需求。数据经过统一但开放的服务接口进入数据仓库，数据通常预先定义 schema，用户通过数据服务接口或者计算引擎访问分布式存储系统中的文件。数据仓库优先的设计通过抽象数据访问接口 / 权限管理 / 数据本身，来换取更高的性能（无论是存储还是计算）、闭环的安全体系、数据治理的能力等，这些能力对于企业长远的大数据使用都至关重要，我们称之为成长性。
下图是针对大数据技术栈，分别比较数据湖和数据仓库各自的取舍。
图 7. 数据湖和数据仓库在技术栈上的对比
灵活性和成长性，对于处于不同时期的企业来说，重要性不同。
当企业处于初创阶段，数据从产生到消费的生命周期还需要一个创新探索的阶段才能逐渐沉淀下来，那么用于支撑这类业务的大数据系统，灵活性就更加重要，数据湖的架构更适用。
当企业逐渐成熟起来，已经沉淀为一系列数据处理流程，问题开始转化为数据规模不断增长，处理数据的成本不断增加，参与数据流程的人员、部门不断增多，那么用于支撑这类业务的大数据系统，成长性的好坏就决定了业务能够发展多远。数据仓库的架构更适用。
很多企业（尤其是新兴的互联网行业）正在经历这样一个从探索创新到成熟建模的过程。在这个过程中，因为数据湖架构太过灵活而缺少对数据监管、控制和必要的治理手段，导致运维成本不断增加、数据治理效率降低，企业落入了“数据沼泽”的境地，即数据湖中汇聚了太多的数据，反而很难高效率地提炼真正有价值的那部分。最后只有迁移到数据仓库优先设计的大数据平台，才解决了业务成长到一定规模后所出现的运维、成本、数据治理等问题。
阿里巴巴的数据中台战略，正是在 2015 年前后阿里巴巴全集团完成 MaxCompute（数据仓库） 对多个 Hadoop（ 数据湖）的完全替换（登月项目）才逐步形成的。
图 8. 数据湖的灵活性 VS 数据仓库的成长性的示意图
下一代演进方向：湖仓一体
经过对数据湖和数据仓库的深入阐述和比较，本文认为数据湖和数据仓库作为大数据系统的两条不同演进路线，有各自特有的优势和局限性。数据湖和数据仓库一个面向初创用户友好，一个成长性更佳。对企业来说，数据湖和数据仓库是否必须是一个二选一的选择题？是否能有一种方案同时兼顾数据湖的灵活性和云数据仓库的成长性，将二者有效结合起来为用户实现更低的总体拥有成本？
将数仓和数据湖融合在一起也是业界近年的趋势，多个产品和项目都做过对应的尝试：
数仓支持数据湖访问
- 2017 年 Redshift 推出 Redshift Spectrum，支持 Redsift 数仓用户访问 S3 数据湖的数据。
- 2018 年阿里云 MaxCompute 推出外包能力，支持访问包括 OSS/OTS/RDS 数据库在内的多种外部存储。
但是无论是 Redshift Spectrum 还是 MaxCompute 的外部表，仍旧需要用户在数仓中通过创建外部表来将数据湖的开放存储路径纳入数仓的概念体系——由于一个单纯的开放式存储并不能自发描述其数据本身的变化，因此为这些数据创建外部表、添加分区（本质上是为数据湖中的数据建立 schema）无法完全自动化（需要人工或者定期触发 Alter table add partition 或 msck）。这对于低频临时查询尚能接受，对于生产使用来说，未免有些复杂。
数据湖支持数仓能力
2011 年，Hadoop 开源体系公司 Hortonworks 开始了 Apache Atlas 和 Ranger 两个开源项目的开发，分别对应数据血缘追踪和数据权限安全两个数仓核心能力。但两个项目发展并不算顺利，直到 2017 年才完成孵化，时至今日，在社区和工业界的部署都还远远不够活跃。核心原因是数据湖具备与生俱来的灵活性。例如 Ranger 作为数据权限安全统一管理的组件，天然要求所有引擎均适配它才能保证没有安全漏洞，但对于数据湖中强调灵活的引擎，尤其是新引擎来说，会优先实现功能、场景，而不是把对接 Ranger 作为第一优先级的目标，使得 Ranger 在数据湖上的位置一直很尴尬。
2018 年，Nexflix 开源了内部增强版本的元数据服务系统 Iceberg，提供包括 MVCC（多版本并发控制）在内的增强数仓能力，但因为开源 HMS 已经成为事实标准，开源版本的 Iceberg 作为插件方式兼容并配合 HMS，数仓管理能力大打折扣。
2018-2019 年，Uber 和 Databricks 相继推出了 Apache Hudi 和 DeltaLake，推出增量文件格式用以支持 Update/Insert、事务等数据仓库功能。新功能带来文件格式以及组织形式的改变，打破了数据湖原有多套引擎之间关于共用存储的简单约定。为此，Hudi 为了维持兼容性，不得不发明了诸如 Copy-On-Write、Merge-On-Read 两种表，Snapshot Query、Incremental Query、Read Optimized Query 三种查询类型，并给出了一个支持矩阵（如图 9），极大提升了使用的复杂度。
图 9. Hudi Support Matrix（来自网络）
而 DeltaLake 则选择了保证以 Spark 为主要支持引擎的体验，相对牺牲对其他主流引擎的兼容性。这对其他引擎访问数据湖中的 Delta 数据造成了诸多的限制和使用不便。例如 Presto 要使用 DeltaLake 表，需要先用 Spark 创建 manifest 文件，再根据 manifest 创建外部表，同时还要注意 manifest 文件的更新问题；而 Hive 要使用 DeltaLake 表限制更多，不仅会造成元数据层面的混乱，甚至不能写表。
上述在数据湖架构上建立数仓的若干尝试并不成功，这表明数仓和数据湖有本质的区别，在数据湖体系上很难建成完善的数仓。数据湖与数据仓库两者很难直接合并成一套系统，因此作者团队，开始基于融合两者的思路进行探索。提出下一代的大数据技术演进方向：湖仓一体，即打通数据仓库和数据湖两套体系，让数据和计算在湖和仓之间自由流动，从而构建一个完整的有机的大数据技术生态体系。
我们认为，构建湖仓一体需要解决三个关键问题：
- 湖和仓的数据 / 元数据无缝打通，且不需要用户人工干预；
- 湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发 / 管理平台操作；
- 数据湖与数据仓库的数据，系统负责自动 caching/moving，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化；我们将在下一章详细介绍阿里云湖仓一体方案如何解决这三个问题。
阿里云湖仓一体方案
整体架构
阿里云 MaxCompute 在原有的数据仓库架构上，融合了开源数据湖和云上数据湖，最终实现了湖仓一体化的整体架构（图 10）。在该架构中，尽管底层多套存储系统并存，但通过统一的存储访问层和统一的元数据管理，向上层引擎提供一体的封装接口，用户可以同时查询数据仓库和数据湖中的表。
图 10. 阿里云湖仓一体整体架构
针对上文提到的湖仓一体的三个关键问题，MaxCompute 实现了以下 4 个关键技术点。
快速接入
MaxCompute 全新自创 PrivateAccess 网络连通技术，在遵循云虚拟网络安全标准的前提下，实现多租户模式下特定用户作业定向与 IDC/ECS/EMR Hadoop 集群网络整体打通能力，具有低延迟、高独享带宽的特点。
经过快速简单的开通、安全配置步骤即可将数据湖和购买的 MaxCompute 数仓相连通。
统一数据 / 元数据管理
MaxCompute 实现湖仓一体化的元数据管理，通过 DB 元数据一键映射技术，实现数据湖和 MaxCompute 数仓的元数据无缝打通，无须联邦查询方式里的人工操作。MaxCompute 通过向用户开放创建 external project 的形式，将数据湖 HiveMetaStore 中的整个 database 直接映射为 MaxCompute 的 project，对 Hive Database 的改动会实时反应在这个 project 中。与此同时，阿里云 EMR 数据湖解决方案在今年云栖大会也推出了 Data Lake Formation，湖仓一体方案也会支持对该数据湖中的统一元数据服务的一键映射能力。
MaxCompute 实现湖仓一体化的存储访问层，不仅支持内置优化的存储系统，也无缝的支持外部存储系统。既支持 HDFS 数据湖，也支持 OSS 云存储数据湖，可读写各种开源文件格式。
统一开发体验
数据湖里的 Hive DataBase 映射为 MaxCompute external project，和普通 project 别无二致，同样享受 MaxCompute 数仓里的数据开发、追踪和管理功能。基于 DataWorks 强大的数据开发 / 管理 / 治理能力，提供统一的湖仓开发体验，降低两套系统的管理成本。
MaxCompute 高度兼容 Hive/Spark，支持一套任务可以在湖仓两套体系中灵活无缝的运行。
同时，MaxCompute 也提供高效的数据通道接口，可以让数据湖中的 Hadoop 生态引擎直接访问，提升了数仓的开放性。
自动数仓
构建湖仓一体化的数据中台
基于 MaxCompute 湖仓一体技术，DataWorks 进一步对湖仓两套系统进行封装，屏蔽湖和仓异构集群信息，构建一体化的大数据中台，实现一套数据、一套任务在湖和仓之上无缝调度和管理。
企业可以使用湖仓一体化的数据中台能力，优化数据管理架构，充分融合数据湖和数据仓库各自优势。使用数据湖做集中式的原始数据存储，发挥数据湖的灵活和开放优势。又通过湖仓一体技术将面向生产的高频数据和任务，无缝调度到数据仓库中，以得到更好的性能和成本，以及后续一系列面向生产的数据治理和优化，最终让企业在成本和效率之间找到最佳平衡。既适用于全新构建大数据平台的企业，也适合已有大数据平台的企业进行架构升级，可以保护现有投资和实现资产利旧。
图 11. DataWorks 湖仓一体化数据中台
新浪微博的”湖仓一体“应用
微博机器学习平台团队，主要做社交媒体领域里的推荐主要做社交媒体领域里的推荐 / 排序、文本 / 图像分类、反垃圾 / 反作弊等技术。技术架构上主要围绕开源 Hadoop 数据湖解决方案，一份 HDFS 存储 + 多种计算引擎（hive、spark、flink），以满足以 AI 为主的多计算场景需求。
但微博作为国内 Top 的社交媒体应用，当前的业务体量和复杂性已然进入到开源“无人区”，开源数据湖方案在性能和成本方面都无法满足微博的要求。微博借助阿里巴巴飞天大数据和 AI 平台能力（MaxCompute+PAI+DataWorks ），解决了超大规模下的特征工程、模型训练以及矩阵计算的性能瓶颈问题，进而形成了阿里巴巴 MaxCompute 平台（数仓）+ 开源平台（数据湖）共存的格局。
微博希望借助这两套异构的大数据平台，既保持面向 AI 的各类数据和计算的灵活性，又解决超大规模下的计算和算法的性能 / 成本问题。但因为这两套大数据平台在集群层面完全是割裂的，数据和计算无法在两个平台里自由流动，无形之中增加了大量的数据移动和计算开发等成本，进而制约了业务的发展。
主要的痛点是：
- 安排专人专项负责训练数据同步，工作量巨大；
- 训练数据体量大，导致耗时多，无法满足实时训练的要求；
- 新写 SQL 数据处理 query，无法复用 Hive SQL 原有 query。
图 12. 新浪微博业务痛点示意图
为了解决上述的痛点问题，阿里云产品团队和微博机器学习平台团队联合共建湖仓一体新技术，打通了阿里巴巴 MaxCompute 云数仓和 EMR Hadoop 数据湖，构建了一个跨湖和仓的 AI 计算中台。MaxCompute 产品全面升级网络基础设施，打通用户 VPC 私域，且依托 Hive 数据库一键映射和强大完善的 SQL/PAI 引擎能力，将 MaxCompute 云数仓和 EMR Hadoop 数据湖技术体系无缝对接，实现湖和仓的统一且智能化管理和调度。
图 13. 微博湖仓一体架构图
这套体系不仅融合了数据湖和数据仓库的优势，在灵活性和效率上找到最佳平衡，还快速构建了一套统一的 AI 计算中台，极大提升该机器学习平台团队的业务支撑能力。无须进行数据搬迁和作业迁移，即可将一套作业无缝灵活调度在 MaxCompute 集群和 EMR 集群中。
SQL 数据处理任务被广泛运行到 MaxCompute 集群，性能有明显提升。基于阿里巴巴 PAI 丰富且强大的算法能力，封装出多种贴近业务场景的算法服务，满足更多的业务需求。
MaxCompute 云原生的弹性资源和 EMR 集群资源形成互补，两套体系之间进行资源的削峰填谷，不仅减少作业排队，还能降低整体成本。
总 结
数据湖和数据仓库，是在今天大数据技术条件下构建分布式系统的两种数据架构设计取向，要看平衡的方向是更偏向灵活性还是成本、性能、安全、治理等企业级特性。但是数据湖和数据仓库的边界正在慢慢模糊，数据湖自身的治理能力、数据仓库延伸到外部存储的能力都在加强。
在这样的背景之下，MaxCompute 率先提出湖仓一体，为业界和用户展现了一种数据湖和数据仓湖互相补充，协同工作的架构。这样的架构同时为用户提供了数据湖的灵活性和数据仓库的诸多企业级特性，将用户使用大数据的总体拥有成本进一步降低，我们认为是下一代大数据平台的演进方向。
标签：架构,MaxCompute,数据仓库,开源,湖仓,数据 From： https://www.cnblogs.com/xieqisheng666/p/16963137.html