A. 产品经理要理解的架构图（结构图）
产品经理在工作过程中会遇到各种结构图（结构图），这些名词很容易混淆。一般情况下，3-5年经验，善于总结归纳的产品经理才能逐步理解这些概念的含义，并且相对灵活的运用到工作中。下面针对这些概念来系统地梳理一下，同时也是加深自己的理解和认知，希望能有所启发。
功能结构图就是按照功能的从属关系画成的图表，在该图表中的每一个框都称为一个功能模块。功能模块可以根据具体情况分得大一点或小一点，分解得最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。（网络定义）
用通俗的话来说，功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图表。功能结构图一般不涉及具体的字段信息，只强调功能的逻辑关系。
以微信为例，我们可以看到整个微信分为4个大的模块：微信、通讯录、发现、我的。发现模块里面有各种功能，比如朋友圈、小程序等等。这里插一句题外话，一般人很少注意到微信底栏第一个菜单是“微信”，往往以为是“消息”“聊天”之类的。网上各种各样的解释都有，我则更愿意理解为微信对自身的自信和坚持，正如微信自己描述的定位一样，它本身就是一种生活方式。
信息结构图是将产品的数据信息抽象出来，直观进行展示的图表。它可以帮助产品经理理解复杂元素的构成，帮助开发进行进行表结构设计。
信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。
同样是以微信为例，下图列出了微信公众号文章涉及的一些核心字段。这些能帮助产品经理和技术来理解整个产品方案的设计过程。
产品结构图是综合展示产品信息和功能逻辑的图表，也就是说看到产品结构图能快速了解产品的功能和信息结构。某种程度上来说，产品结构图绘制出来，原型图上的信息和功能基本就已经确定了。
当然这个理解目前在业内没有形成一致的共识，只是一部分人这么理解而已。很多时候产品经理在进行整理的时候，不自觉地将这两者融合在一起，因为功能是在页面里面的，围绕信息展开的，所以有时候并不需要分那么清，只要能把事情说清楚，不需要纠结。
在产品设计的过程中，一般是从产品功能结构图出发，直到最后完成产品结构图。 完成产品结构图之前最好不要开始画原型，做产品设计，因为这个时候对整体框架，流程还没有完整的认知，过早开始往往是做无用功。
软件架构的核心价值是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦。架构一般可为分业务架构、应用架构、技术架构。其中业务架构是战略，应用架构是战术，技术架构是装备。
架构的目的通俗来说就是把复杂的东西简单化，标准化，流程化，自动化。下面来分别解释一下。
产品架构图有时候也叫做业务架构图，是对于产品底层的设计，涉及到整个产品的业务流程，比较复杂。
产品架构图是不断演进的，其改变往往意味着产品维度进行大的调整，无论是功能还是信息都会有大的变动。
产品架构图面向公司层面，偏战略；考虑的是如何为用户提供价值，以及企业可以通过什么方式来实现盈利的问题。
还有一种划分是把产品架构图和业务架构图分开，先有业务再有产品。举一个简单的例子，美团的业务包括外卖，到店和酒旅业务等。用一个词概括就是“吃喝玩乐”，围绕优惠折扣，服务这些关键词展开，这个就是美团的业务架构。在外卖业务中，分为C端、商家、骑手等终端，如何让用户更快捷找到优惠，让骑手更快速的送出外卖，这些就是产品架构层面的事情。骑手送餐可能会出现部分骑手绕路耽误时间的情况，但是从整个平台的角度来看，基本是公平，高效的。
应用架构起到承上启下的作用：一方面承接业务架构的落地，另外一方面影响技术选型。
比较常用的划分是应用架构类型：单体式、分布式、SOA架构。
分布式应用架构中，不同应用是独立的，应用内部高内聚，应用之间松耦合，可以灵活的进行分布式部署。同时缺点也比较明显，那就是不同应用之间通信连接都需要额外的工作量，同时整个架构设计变得复杂维护起来成本必然增加。
到技术这一层整个系统的设计已经比较清晰了，尽管技术架构图涉及的技术模型一般都比较多。但经过拆解，分组，已经非常直观了，我们可以把技术架构图简单理解为具体的装修设计图，剩下的就是靠技术人员分批分模块来慢慢实现了。
下面引用一张美团的系统架构图，这只是美团业务体系的一个缩影。从图里面我们可以了解到美团的业务极其复杂，使用的技术也非常多。
组织架构是企业的流程运转、部门设置及职能规划等最基本的结构依据，常见的组织架构形式包括中央集权制、分权制、直线式以及矩阵式等。（网络定义）不同公司的组织结构差别很大，在不同时期往往也不一样。组织结构是在不断进化的，其目地就是为了使工作职责明确，工作目标性强 ，提高生产力。
下面引用一张腾讯公司的的组织架构图，从这里可以看出很多信息。比如微信产品的重要性，任宇昕的重要性，腾讯对于内容产品的重视等等。
以上理解是本人参考了大量的资料，结合自己的工作经历总结出来的。由于自己的水平有限，难免有描述不准确、不正确的地方，恳请各位读者海涵，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。
B. 目前各大互联网公司如阿里，腾讯，滴滴，美团，今日头条这些公司的大数据分析的框架是怎样的求解答！
在互联网时代，什么是第一生产力呢？毫无疑问，一定是研发人员。没有研发人员码代码，即使有产品经理提很多好的idea、设计出很好的设计稿、运维人员把机房网络服务器全搞定，那也没用。没有代码就等于没有操作系统，没有手机电脑平板等硬件设备，没有数据库消息队列等中间件，没有淘宝抖音支付宝美团滴滴等软件。
所以在互联网时代中，研发人员是最重要的人员，他是可以实现从0到1的创造一个产品，如果研发人员不给力，那么就会出现经常性加班、频繁出现事故、重复低效工作等情况。因此提高研发人员的生产效率，建设研发效能对于大型互联网公司来说非常重要，统计数据显示，亚马逊、阿里每年在研发的投入成本占整个公司成本预算15%。那么研发效能是什么呢？又如何建设？如何考量呢？
软件从开发到上线的流程大概是需求评审》开发〉提测》测试〉预发》发布〉运维，在整个过程中，研发人员从需求评审阶段就参与了整个过程，直到上线，重度参与的阶段包含开发代码、写单元测试用例、写自动化测试用例、打包、部署测试环境、测试、部署生产环境、上线，在这个过程中要使用到的工具包含需求管理工具、代码仓库工具、打包工具、部署工具、测试工具、上线工具，如果每个工具都是分散在不同的地方，由不同的团队开发实现，对于研发人员来说，需要去不同的平台找到这些工具，需要把这些工具都学会使用，需要在开发的过程中把这些工具都串联起来，精力很分散，导致于研发人员不能聚焦于业务开发。所以建设研发效能就是建设持续交付能力。
现在已经进入到了互联网的下半场，市面上能有的想法都差不多被实现了，然而用户就这么多，流量就这么多，开源不行就只能节流了，通过研发效能能力的建设，将研发团队生产效率提高，降低整个企业的成本，这也是新的思路啊。现在你明白了为什么滴滴头条、阿里美团都在纷纷投入做研发效能了吧。
研发效能的建设宜早不宜迟，从早期开始尽可能的打好技术底子，培养好的研发团队合作规范，避免后期用户规模扩大时，再来弥补早期的技术债。现在赶紧行动起来吧～
C. 数据库结构
新一轮油气资源评价数据库是建立在国家层面上的数据库，数据库设计首先立足于国家能源政策和战略制定的宏观要求，还要结合油气资源评价的工作特征和各个评价项目及资源的具体情况。使用当前最流行和最成熟的数据库技术进行数据库的总体结构设计。
数据库的设计以《石油工业数据库设计规范》为指导标准，以《石油勘探开发数据》为设计基础，借鉴前人的优秀设计理念和思路，参考国内外优秀的资源评价数据库和油气资源数据库的设计技术优势，结合本轮资源评价的具体特点，按照面向对象的设计和面向过程的设计相结合的设计方法，进行数据库的数据划分设计。
油气资源评价数据库要满足新一轮全国油气资源评价工作的常规油气资源评价、煤层气资源评价、油砂资源评价、油页岩资源评价四个油气资源评价的数据需求。进行数据库具体数据内容设计。
并且，数据库的设计要为油气资源评价的快速、动态评价和远程评价工作的需求保留足够数据扩展接口，数据库具有良好开放性、兼容性和可扩充性。
（一）数据划分
数据库内存放的数据将支持资源评价的整个过程。为了能更好地管理库中数据，需要对整个过程中将用到的数据进行分类管理。具体分类方式如下（图4-11）：
图4-11 数据分类示意图
1.按照应用类型划分
按照数据在资源评价过程中的应用类型划分，可以划分为基础数据、参数数据和评价结果数据。
基础数据是指从勘探生产活动及认识中直接获取的原始数据，这些数据一般没有经过复杂的处理和计算过程。如分析化验数据、钻井地质数据、盆地基础数据等。这些数据是整个评价工作的基础。
参数数据是指在评价过程中各种评价方法和软件直接使用的参数数据。
评价结果数据是指资源评价中产生的各种评价结果数据，如资源量结果数据、地质评价结果数据等。
2.按照评价对象划分
本次评价共分为大区、评价单元、计算单元三个层次，在研究中又使用了盆地、一级构造单元，在评价对象总体考虑中按照评价对象将数据划分为大区、评价单元、计算单元等类型。
3.按照获取方式划分
按照获取方式可以将数据分为直接获取、研究获取、间接获取几类。
4.按照存储类型划分
按照存储类型可以将数据划分为结构化数据和非结构化数据。
结构化数据是指能够用现有的关系数据库系统直接管理的数据，进一步又可以分为定量数据和定性数据两类。
非结构化数据是指不能用现有的关系数据库系统直接管理和操作的数据，它必须借助于另外的工具管理和操作。如图件数据、文档数据等。
库中数据类型的划分共分六个层次逐次划分，包括：数据存储类型→资源类型→评价对象→应用→获取方式→数据特征。
对于结构化存储的数据在应用层分为三类：基础数据、中间数据和结果数据，基础数据中包含用于类比的基础数据、用于统计分析的基础数据和直接用于公式运算的基础数据；结构化存储的数据在获取方式上可以继续划分，其中，用于公式运算的数据可以细化为专家直接录入、由地质类比获取、通过生产过程获取、通过地质研究过程获取及其他方式。中间数据可以从以下方式获取：标准、统计、类比、参数的关联。结果数据的获取有两种方式：公式运算结果和通过钻井、地质、综合研究等提交的文字报告。
对于非结构化存储的数据在应用层分为两类：图形数据和文档数据。
图形数据在获取方式上可以继续划分成四种方式：通过工程测量数据获取（如地理图件、井位坐标数据等）、通过地质研究过程获取（如沉积相图、构造区划图等）、由综合研究获取（如综合评价图等）、其他方式。
图形数据在表现方式上又可以进一步分为有坐标意义的图形（如构造单元划分图、地理图、井位图等）、数值图（如产烃率曲线图、酐洛根热降解图等）和无坐标含义图（如剖面图）等。
文档数据是指评价过程中产生的各种报告、项目运行记录等。
（二）数据库结构
从业务需求上，根据数据用途、数据类型和数据来源，可将本次的油气资源评价数据库分为三级：基础库、参数库、成果库（图4-12）。其结构如下：
图4-12 数据库结构示意图
1.基础库
基础库是油气资源评价工作的最基础的原始数据，有实测数据（物探数据、测井数据、钻井数据、开发数据等）、实验数据和经验数据等。
确定基础数据实际上是一项涉及油田勘探、开发等领域的多学科的复杂工作，是油气资源评价工作的研究过程和研究成果在数据库中的具体表现方式。在设计数据库的过程中，需要与参数研究专家经过多次反复，才能最终确定基础数据库，确保基础数据库能满足目前所有评价工作中计算的需要。
2.参数库
参数库用于存储油气资源评价工作所用到的参数数据，评价软件，直接从参数库中提取参数数据，用于计算。参数数据由基础数据汇总而来，也可以由专家根据经验直接得到。
本次评价中所涉及的参数大致可以分为以下几类：①直接应用的参数；②通过标准或类比借用的参数；③通过研究过程或复杂的预处理得到的参数。
3.成果库
成果库用于存储资源评价结果，包括各种计算结果、各种文档、电子表格、图片、图册等数据。
数据库的体系结构采用分布式多层数据库结构，包括三个组成部分：应用服务层、应用逻辑层和数据服务层。
数据库体系结构如图4-13所示。
图4-13 体系结构结构图
（1）应用服务层：应用服务层包含复杂的事务处理逻辑，应用服务层主要由中间件组件构成。中间件是位于上层应用和下层服务之间的一个软件层，提供更简单、可靠和增值服务。并且能够实现跨库检索的关键技术。它能够使应用软件相对独立于计算机硬件和操作系统平台，把分散的数据库系统有机地组合在一起，为应用软件系统的集成提供技术基础，中间件具有标准程序接口和协议，可以实现不同硬件和操作系统平台上的数据共享和应用互操作。而在具体实现上，中间件是一个用API定义的分布式软件管理框架，具有潜在的通信能力和良好的可扩展性能。中间件包含系统功能处理逻辑，位于应用服务器端。它的任务是接受用户的请求，以特定的方式向应用服务器提出数据处理申请，通过执行相应的扩展应用程序与应用服务层进行连接，当得到应用服务器返回的处理结果后提交给应用服务器，再由应用服务器传送回客户端。根据国内各大石油公司具体的需求开发相应的地质、油藏、生产等应用软件功能程序模块和各种算法模块。
（2）应用逻辑层：逻辑数据层是扩展数据服务层逻辑处理层，针对当前的底层数据库的数据结构，根据具体的需求，应用各种数据库技术，包括临时表、视图、存储过程、游标、复制和快照等技术手段从底层数据库中提取相关的数据，构建面向具体应用的逻辑数据库或者形成一个虚拟的数据库平台。逻辑数据层包含底层数据库的部分或全部数据处理逻辑，并处理来自应用服务层的数据请求和访问，将处理结果返回给逻辑数据层。
形成一个虚拟的数据库平台我们可以应用数据库系统中的多个技术来实现。如果系统中的一个节点中的场地或分片数据能够满足当前虚拟数据库，可以在应用服务层中使用大量的查询，生成一个以数据集结果为主的虚拟数据库平台，并且由数据集附带部分数据库的管理应用策略。或者对节点上的数据库进行复制方法进行虚拟数据库的建立。对与需要对多个节点上的数据库进行综合筛选，则要对各个节点上的数据库进行复制，合并各个复制形成一个应用逻辑层，从而建立一个虚拟数据平台。
（3）数据服务层：即数据库服务器层，其中包含系统的数据处理逻辑，位于不同的操作系统平台上，不同数据库平台（异构数据库），具体完成数据的存储、数据的完整性约束。也可以直接处理来自应用服务层的数据请求和访问，将处理结果返回给逻辑数据层或根据逻辑数据层通过提交的请求，返回数据信息和数据处理逻辑方法。
（三）数据建设标准
1.评价数据标准
系统数据库中的数据格式、大小、类型遵从国家及行业标准，参考的标准如表4-23。
表4-23 数据库设计参考标准
续表
系统中数据的格式及单位参考《常规油气资源评价实施方案》、《煤层气资源评价实施方案》、《油砂资源评价实施方案》、《油页岩资源评价实施方案》及数据字典。
2.图形图件标准
对于地质研究来说，地质类图件是比较重要的。各种地质评价图形遵循以下标准（表4-24）。
表4-24 系统图形遵循的相关标准
系统对图形的要求为必须为带有地理坐标意义的、满足上述标准体系要求的矢量图形，且采用统一的地理底图。图形格式采用：MapGIS图形交换格式、GeoInfo图形格式、ArcInfo图形交换格式、MapInfo图形交换格式和GeoMap图形交换格式。
图件的比例尺要求：
全国性图件：1∶400万或1:600万
大区图件：1:200万
盆地图件：1:40万或1:50万
评价单元图件：1:10万或1:20万
图件的内容要求符合《常规油气资源评价实施方案》、《煤层气资源评价实施方案》、《油砂资源评价实施方案》和《油页岩资源评价实施方案》的规定。
（四）数据内容
数据库中存储的数据包括常规油气相关数据、煤层气相关数据、油砂相关数据和油页岩相关数据；还有可采系数研究涉及的数据，包括研究所需基础数据和研究成果数据；以及趋势预测相关数据。
D. 数据库管理系统结构由哪五部分构成,分别是什么,并阐述
数据库系统一般由4个部分组成：
(1)数据库（database，DB）是指长期存储在计算机内的，有组织，可共享的数据的集合。数据库中的数据按一定的数学模型组织、描述和存储，具有较小的冗余，较高的数据独立性和易扩展性，并可为各种用户共享。
（2）硬件：构成计算机系统的各种物理设备，包括存储所需的外部设备。硬件的配置应满足整个数据库系统的需要。
（3）软件：包括操作系统、数据库管理系统及应用程序。数据库管理系统（database management system，DBMS）是数据库系统的核心软件，是在操作系统的支持下工作，解决如何科学地组织和存储数据，如何高效获取和维护数据的系统软件。其主要功能包括：数据定义功能、数据操纵功能、数据库的运行管理和数据库的建立与维护。
（4）人员：主要有4类。第一类为系统分析员和数据库设计人员：系统分析员负责应用系统的需求分析和规范说明，他们和用户及数据库管理员一起确定系统的硬件配置，并参与数据库系统的概要设计。数据库设计人员负责数据库中数据的确定、数据库各级模式的设计。第二类为应用程序员，负责编写使用数据库的应用程序。这些应用程序可对数据进行检索、建立、删除或修改。第三类为最终用户，他们利用系统的接口或查询语言访问数据库。第四类用户是数据库管理员（data base administrator，DBA），负责数据库的总体信息控制。DBA的具体职责包括：具体数据库中的信息内容和结构，决定数据库的存储结构和存取策略，定义数据库的安全性要求和完整性约束条件，监控数据库的使用和运行，负责数据库的性能改进、数据库的重组和重构，以提高系统的性能。
其中应用程序包含在软件范围内，是指数据库应用系统，比如开发工具、人才管理系统、信息管理系统等。
层次关系可参见如下图：
E. 美团外卖产品分析报告：二 产品设计
> 点击查看原图
上图使用思维导图的方式，完整展示了美团外卖 App 的功能菜单，按照主菜单可划分为四类。
首页： 以分类、优惠等多种形式展示商家，用户可进行搜索、挑选。
闪购： 单独展示生鲜超市类商品，区别于首页的餐饮，主推基于周边生活圈的闪购业务。
订单： 查看所有已被创建的订单，用户可进行评价、售后、再来一单等操作。
我的： 集中管理用户资料及资产，包括地址、收藏、钱包、优惠券等，以及客服中心等入口。
> 点此查看原图
上图使用泳道图的方式，分别从消费者、商家、骑手三者的用户角度，模拟展示了美团外卖产品的业务流程。
从中可看出，消费者与商家、骑手之间的流程关系是密不可分的。消费者是触发整个流程的主导者，而商家与骑手则作为服务消费者的角色，三者形成一个完整的业务闭环过程。
从流程图可看出，美团外卖的登录、注册方式，基本以手机号码为主。即使使用第三方社交账号登录，也必须先绑定手机。
主要原因在于，美团外卖的用户是以手机号码为基准，一个号码对应一个用户，这样既能保证用户的真实性，也可减少刷单、刷评论等现象。而且，同一个账号是允许在多台终端同时登录的，用户资料及购物车等是支持实时同步的。
因为手机号码是点单取餐的必备条件，所以无论从用户或产品角度，使用手机号码都是十分合理且自然的选择。
美团外卖 App 界面以橘黄色为主色调，并贯穿整个产品设计。除了底色、图标、文字，还配合可爱的袋鼠形象、骑手服饰等，整套色系已深入人心，可以说是非常成功的 VI 设计案例。
作为一款外卖产品，设计核心围绕在如何更优的展示商家，并引导用户进行点餐下单。页面中部位置用于显示商家与餐品，搜索、设置、消息中心等功能置于顶部，而底部则为固定的菜单导航栏。操作方式以上下划动、单点选择为主，偶尔配合左右滑动作为辅助展示。
> 点此查看原图
上图使用 Axure 软件，以倒推的方式，绘制了美团外卖 App 的中保真原型图，以便展示产品界面的设计细节。
原型图以灰度为主，并以彩色线条表示不同页面之间的流程关系，以蓝色注释讲解其中的交互设计关键点。
前文已经提到，美团外卖的登录与注册方式，均以手机号码为主，从界面设计也可以明显看出这一点。
账号的退出方式，则放在二级入口“我的-我的账号”中，因为一般用户不需要频繁切换账号，较少用到。
在美团外卖 App 中，新用户在未登录的游客状态下，仍然可以使用大部分操作，比如浏览商家、点选商品等，地址默认使用系统匹配的附近地址。直到超过限定范围，触发了必须登录才能使用的功能，那么界面则会提醒用户登录或注册。
上图展示了美团外卖中会触发登录提醒的操作，比如消息中心、购物车、个人信息、地址管理、订单结算等功能。这样的设计，对新用户更加友好，便于初次使用时的探索了解，直到产生下单需求时再引导注册登录。
作为一款在线外卖产品，功能核心自然是点餐下单，所以对于商家的展示、点餐过程的引导，则至关重要。
从上图可看出，美团外卖对于如何引导用户做了非常多的功课，几乎所有操作都成为了商家页的入口。
内容上不乏带有诱导作用的优惠信息，用来增强用户下单的欲望。同时，还提供了很多便于用户搜索、筛选的工具，以便提高下单的效率。
用户进入商家页后，可进行挑选、下单、付款等操作，示意图完整演示了用户从进入商家到完成支付的全过程。从中可发现，美团外面界面的设计逻辑非常清晰直观，即使是新用户的学习成本也相对较低。
用户在商家页挑选商品时，可以随意加减数量，并实时看到经过计算的实际总金额。而且，会贴心的提醒用户是否满足当前商家的满减优惠，还提供了“满减神器”帮助用户快速下单。挑选完商品，可以通过下方购物车进行二次确认，直观的展示已选商品及总价，确认无误后再结算。提交订单后，会再次具体的显示商品的价格公式，包括包装费、配送费、优惠红包等加减细节，详尽而不显罗嗦。在订单页，用户可以进行选择红包代金券、填写备注、选择餐具、开具发票等操作。最后完成付款，并跳转至订单详情页。
本小节中提及的便捷功能，是美团外卖产品设计中的亮点。在贴合产品核心功能的同时，既提高了用户的点餐效率，满意度提升，又促进了消费。
在商家页的左下角，有一个“满减神器”的功能，供用户快速选择符合满减要求的餐品，与“凑单提醒”相辅相成，相较更加直接有效。
满减神器会自动列出，当前商家中符合满减优惠的最优餐品组合。实现逻辑也非常简单，主要是通过商家历史订单，排列出被购买次数较多的组合。
由于满减优惠在外卖平台中已成常规活动，几乎所有商家都有力度不同的优惠，点餐时相当考验用户的数学能力。而美团外卖推出该功能，正是想用户之所想，为用户省去了凑单的时间，极大的提升了点餐效率。
订单页面的顶部，用户已消费过的商家按次数从高到低排列，形成最近常买的商家列表。便于让用户快速找到，减少查找时间。
从用户角度来看，消费次数居高的商家，通常是比较喜欢、经常会关顾的商家。
在订单列表中，已完成的历史订单，可通过“相似商家”查看与该商家相似的其他商家，主要是通过位置、品类、价位等因素综合筛选。
通常是用户喜欢该商家的餐品口味，但由于某些原因希望更换其他商家，就需要用到该功能，特别是对于重度用户来说尤其重要。
在订单列表及订单详情中，均有“再来一单”按钮，其功能类似于重新购买。
用户点击后会跳转至该商家页面，并自动将历史订单中的相同餐品放入购物车。如有其中有缺失的餐品，会加以提示。当用户想要重复点选之前的餐品，或只是进行细微调整，就可以通过简单的操作快速完成点餐。
除了适合用户再次重复点单，以及没有时间挑选餐品的场景。同时，当用户点错单并取消后，也可以使用“再来一单”重新添加，再到购物车中调整修改。
美团外卖的商家展示，是以用户当前地址为判断基准的，必须在配送范围内才会展示，同时用户地址也是骑手送餐配送的关键信息。因此，如何引导用户填写地址信息，并确保选择正确的地址，是较为重要的核心功能之一。
如上图所示，美团外卖主要提供了三个入口供用户对地址进行选择、编辑，分布在首页、提交订单、我的地址三个页面中，分别对应了下单前、下单时、下单后三个流程。
作为一款贴近民生的在线外卖产品，用户对于商家、骑手等服务的评价显然是非常重要的数据，上图展示了美团外卖中的多个评价入口。从示意图可看出，当前订单完成后，同时会有三个入口在提醒用户进行评价。如果在订单完成时，用户没有及时评价，之后再回到订单页仍会看到评价按钮，并且还单独设有“待评价”的分类。
评分机制可以促使商家、骑手提升自身的服务质量，商家一般会根据评价内容对餐品加以改进，而骑手为了收到好评也会更加主动服务态度。同时，平台还可以利用用户评价作为产品优化的数据支撑，从而共同作用于整个产品质量及使用体验的提升。
在积极引导用户评价的同时，还需要保证用户评价的真实有效性。除了前文提到的，以手机号码注册的方式加强用户的真实性，还限制仅能在订单完成的 7 天内评价，且评价后超过 7 天也无法再追评。因为间隔一段时间之后，用户对于外卖口感及服务体验可能产生偏差，或者受到其他因素干扰，最直接的评价应该在一周内。而这些评价内容，也会统一归入“我的评价”中，方便用户再次查看管理。
如图所示，用户可以在大多数页面的右上角找到“消息中心”的入口。里面集合了所有的通知类及沟通类内容，包括商家代金券、系统通知、客服消息、好友消息等。
根据实际场景可发现，用户在沟通的过程中经常需要返回进行其他操作，而“消息中心”的多入口设计，正是方便了用户的来回切换。
当用户在使用产品的过程中碰到问题，首要选择自然是在线客服，上图展示了美团外卖 App 中多个客服入口及界面设计，主要入口位于“订单”及“我的”页面。
由于外卖产品的异常问题大多与订单相关，所以“订单详情”的页面入口更为常用。对此，根据订单或状态的不同，用户进入在线客服的页面内容是有所差异的。结合示意图举例，同一个订单在“配送中”与“已完成”两个状态下显示的内容是不同的。
这样处理的目的，一是为了简化用户的操作，利用大数据预测当前需求；二是将用户引导至正确的解决渠道，比如直接联系商家或骑手，从而减轻人工客服的成本压力。
美团外卖 App 中，只要在用户已登录的情况下，已勾选的商品都会一直保留在“购物车”中，可以随时轻松找回，我将其称之为“购物车保留原则”。
用户点选过的商品必然是经过各种因素考虑的，即使当下不会立即下单，但随时能找回来是很关键的，给予用户一种“永远呆在购物车等着”的安心感。对于一款在线外卖产品来说，这是用户体验中至关重要的一点。
用户在任何商家挑选过的商品，都会在“购物车”内集中展示，并非常直观的将价格、配送费、满减优惠写明。如果出现商家休息、商品缺货等异常情况，还会加以提醒（如图中）。用户可随时在购物车内二次挑选、比较，再进行下单结算。结算后的商品自然会清除，但仍可在历史订单中看到购买过的商品。
同时经过实测发现，即使在断网、闪退、没电的极端情况，购物车内的商品也不会丢失。但如果是游客状态，购物车则不会永久保留，因为用户数据是跟随账号在线存储的，并支持实时同步于多个终端。
如图所示，用户若当前有订单处于进行时，在页面右下方会出现一个置顶的悬浮窗，用以显示订单的实时状态。
在“首页”、“订单”、“我的”三个主页页面中，都能看到该悬浮窗。用户点击后会直接进入该订单的详情页，方便随时了解当前的动态，比如骑手送到哪了。
结合图示可看到，根据订单状态的不同，悬浮窗的提示也会随之变化。悬浮窗会在用户提交订单后出现，而一旦订单完成（配送完成）即消失。
如上图所示的交互动作，当用户选择“待评价（或退款）”时，页面会在切换的同时全屏展开并置顶菜单。这是比较符合用户直觉的交互设计，实际操作令人感觉一气呵成。
在这个状态下，用户的“点击”行为代表了“切换并查看内容”的意图，所以全屏展开更利于用户的浏览，避免其他无关内容扰乱视觉。同样的交互设计，还出现在了首页的筛选功能、活动页面的分类菜单等。
美团外卖 App 中最常见的悬浮控件，主要是首页（或闪购）的“购物车”，以及订单详情页中的“红包”。
两个悬浮控件虽然性质类似，但在操作上略有不同。结合上示示意图，针对两者分别作简单分析。
购物车：当打开首页（或闪购）时，“购物车”控件的初始状态是完全显示的，以突出其功能位置。当用户划动页面的时候则呈透明状并收入边栏，避免阻挡内容。而如果停止划动，则会恢复完全显示的初始状态。
红包：初始状态同样为完全显示，划动时也是呈透明状并收入边栏。与购物车的区别在于，当停止划动时控件为隐藏状态，且可自由拖动。
“红包”控件是可以自由拖动的，且在停止划动后不会再次完整显示。如此设计可以尝试理解为，假设用户在订单完成后初始没有分享红包的意图，则之后再分享的可能性极低，所以控件只需保持“乖乖呆在角落且需要时也能找到”的状态即可。控件允许自由拖动，则避免了悬浮控件容易遮挡住页面关键信息的情况，比如当订单详情页需要截屏（分享、投诉）的时候。
在适时的时刻给出适当的提醒，告知用户关键的必要信息，可避免因信息不对称而影响用户的使用体验。并且，提醒的时机及方式也相当重要，一旦过于突兀或频繁，提醒就会变成骚扰。
以下配合示意图，讲述美团外卖 App 中数个较为典型的例子。
当用户使用“再来一单”功能，但该商家中的部分商品缺失而无法加入购物车，则页面会明显提示“ XX 商品已售完，并重新选择。”。
便于用户及时了解后，检查购物车并重新选购。避免了用户在不知情的情况下直接下单，造成下错单、订单纠纷等情况。
当用户进入商家页，但当前未在该商家的配送时间内，则页面顶部会出现“现在预定，**:** 起送”的配送时间提醒。
明确告知用户，现在如果下单属于预定，以及开始配送的时间。避免用户挑选完商品后才发现无法即时配送，甚至直接下单后商家却没有配送。
另外，如果当前未在商家的营业时间内，页面则会直接提示“本店打烊”，且用户是无法点选任何商品的。
当用户提交订单时，若系统判断收货地址所在位置有雨天、雪天等恶劣天气，则页面会在配送时间下方给出“恶劣天气下配送可能延迟，请耐心等待。”的提醒。
便于用户提前了解，该订单的配送时间可能较长，若继续下单就意味着默认接受。从而在一定程度上，可以减轻用户等待的焦虑感，并减少投诉、催单等事件。
当用户在任意页面进行屏幕截图时，则页面右侧会出现两个便捷选项，分别为“反馈问题”与“分享页面”。
选择“反馈问题”，会先进入包含马赛克及标记功能的编辑界面，方便用户先行除去截图中的敏感信息，或者标注需要反馈的问题所在。选择“分享页面”，则是微信、QQ 等社交分享按钮。另外，如果是在商家页进行屏幕截图，还会增加“好友拼单”的选项，点击后进入微信拼单界面。
当用户手机所在的网络出现异常时，则页面会出现“网络不太给力，请稍候重试”的提示。
从上图可看到，网络异常下的提示非常简单直接，页面会因为无法加载内容而完全空白，并提醒用户重新加载（如左图）。在网络恢复正常后，重新加载即可显示正常页面。
如果是在使用过程中间歇性出现网络不稳定的情况，则当前页面已加载的内容仍可继续浏览，但继续点击就会因为无法加载而弹出提示（如右图）。
作为对于社会舆论的回应，美团外卖经常会推出一些加分的选项。同时配合公关宣传，对于品牌形象的提升有着直接的影响。
美团外卖于 2017 年 9 月份推出“青山计划”，正式将环保工作提上议程。同时鼓励商家与用户一同参与，减少一次性餐具的使用。
用户可在提交订单时自行选择餐具数量，或者不需要餐具。同时，页面会有明显标识“一起为环保助力”鼓励用户参与，而商家参与活动后则可以点亮环保标识。
此举在一定程度上抵消了外界关于外卖污染的负面舆论，同时也有助于提升美团外卖的绿色环保形象。
美团外卖于 2017 年 8 月份推出号码保护功能，提高对用户的隐私保护。
用户可在提交订单时勾选“号码保护”，开启后商家及骑手只能看到隐藏四位数的手机号码，联络用户时需要通过第三方号码平台进行中转，并在订单完成一定时间后失效。
号码保护给用户带来的好处是十分明显的，再也不用担心外卖单随意丢弃会泄露地址、手机，或者与商家、骑手出现纠纷时可以避免被通过手机号码骚扰。
美团外卖免费向所有用户提供号码保护服务，让用户使用产品时更加放心，有助于提升对该品牌的信任感。
美团外卖于 2014 年左右上线初期就已支持匿名评价功能，主要是为了让用户提供更加真实的评分、内容。
用户对已完成的订单进行评价时，骑手评价是始终匿名的，而商家评价则可以选择是否匿名。而更加贴心的是，如果用户对商家给出两星以下的差评，则匿名评价会自动勾选。
该功能与号码保护相似，主要在于保护用户的隐私，并在一定程度上提高了用户评价的真实性。
美团外卖于2018年6月份推出骑手拉黑功能，用户可将服务体验较差的骑手拉黑，之后该骑手将不会接到该用户的订单。
此举可提升用户的使用体验，避免重复碰到态度恶劣、道路不熟的骑手。同时也可反推骑手提高服务质量，避免被多人拉黑而少接单。
F. 像美团之类带有地区选择的数据库是如何设计的呢
三级联动吧，（先得到省表数据，前端选择了某省，把省id带到市表，就得到该省下的城市，然后区也是）
最后发挥你网络的技能，搜索省市区的资源了哦。
G. 美团大脑百亿级知识图谱的构建及应用进展
分享嘉宾：张鸿志博士 美团 算法专家
编辑整理：廖媛媛 美的集团
出品平台：DataFunTalk
导读： 美团作为中国最大的在线本地生活服务平台，连接着数亿用户和数千万商户，其背后蕴含着丰富的与日常生活相关的知识。美团知识图谱团队从2018年开始着力于图谱构建和利用知识图谱赋能业务，改善用户体验。具体来说，“美团大脑”是通过对美团业务中千万数量级的商家、十亿级别的商品和菜品、数十亿的用户评论和百万级别的场景进行深入的理解来构建用户、商户、商品和场景之间的知识关联，进而形成的生活服务领域的知识大脑。目前，“美团大脑”已经覆盖了数十亿实体、数百亿的三元组，在餐饮、外卖、酒店、到综等领域验证了知识图谱的有效性。今天我们介绍美团大脑中生活服务知识图谱的构建及应用，主要围绕以下3个方面展开：
--
“美团大脑”是什么？
以下是“美团大脑”构建的整体RoadMap，最先是2018年开始餐饮知识图谱构建，对美团丰富的结构化数据和用户行为数据进行初步挖掘，并在一些重要的数据维度上进行深入挖掘，比如说对到餐的用户评论进行情感分析。2019年，以标签图谱为代表，重点对非结构化的用户评论进行深入挖掘。2020年以后，开始结合各领域特点，逐个领域展开深度数据挖掘和建设，包括商品、美食、酒旅和到综和cross图谱等。
--
在搜索中，通常用户需要将其意图抽象为搜索引擎能够支持的一系列精搜关键词。标签知识图谱则是通过“标签”来承载用户需求，从而提升用户搜索体验。例如，通过标签知识图谱，用户可直接搜索“带孩子”或者“情侣约会”，就可返回合适的商户/内容供给。从信息增益角度来说，用户评论这种非结构化文本蕴含了大量的知识（比如某个商户适合的场景、人群、环境等），通过对非结构化数据的挖掘实现信息增益。该团队以生活服务领域的海量评论数据作为主要知识来源，通过标签挖掘、标签间关系挖掘以及标签-商户关联等关键技术，自下而上梳理用户需求，场景及主要关注点完成图谱构建。
标签知识图谱构建分为以下四个部分：知识抽取、关系挖掘、图谱打标和图谱应用。
① 知识抽取
标签挖掘采用简单的序列标注架构，包括Single span标签挖掘和跳字标签挖掘，此外还会结合语义判别或者上下文判别，采用远监督学习+结果投票方式获取更精准的标签。
② 关系挖掘
同义词挖掘：同义词挖掘被定义为给定包含N个词的池子，M个业务标签词，查找M中每个词在N中的同义词。现有的同义词挖掘方法包括搜索日志挖掘、网络数据抽取、基于规则的相似度计算等，缺乏一定的通用性。当前我们的目标是寻找通用性强，可广泛应用到大规模数据集的标签同义词挖掘方法。
以下是作者给出的同义词挖掘的具体方案，首先将离线标签池或者线上查询标签进行向量表示获取向量索引，再进行向量哈希召回，进一步生成该标签的TopN的同义词对候选，最后使用同义词判别模型。该方案的优势在于降低了计算复杂度，提升了运算效率；对比倒排索引候选生成，可召回字面无overlap的同义词，准确率高，参数控制简单。
对于有标注数据，主流的标签词嵌入表示方法有word2vec、BERT等。word2vec方法实现较为简单，词向量取均值，忽略了词的顺序；BERT通过预训练过程中能捕捉到更为丰富的语义表示，但是直接取[CLS]标志位向量，其效果与word2vec相当。Sentence-Bert对于Bert模型做了相应的改进，通过双塔的预训练模型分别获取标签tagA和tagB表征向量，然后通过余弦相似性度量这两个向量的相似性，由此获取两个标签的语义相似性。
对于无标注数据来说，可以通过对比学习的方法获取句子的表示。如图所示，Bert原始模型对于不同相似度的句子的向量相似度都很高，经过对比学习的调整之后，向量的相似度能够较好地体现出文本相似度。
对比学习模型设计：首先给定一个sentence，对这个样本做扰动产生样本pair，常规来说，在embedding层加上Adversarial Attack、在词汇级别做Shuffling或者丢掉一些词等构成pair；在训练的过程中，最大化batch内同一样本的相似度，最小化batch内其他样本的相似度。最终结果显示，无监督学习在一定程度上能达到监督学习的效果，同时无监督学习+监督学习相对于监督学习效果有显着提升。
同义词判别模型设计：将两个标签词拼接到Bert模型中，通过多层语义交互获取标签。
标签上下位挖掘：词汇包含关系是最重要的上下位关系挖掘来源，此外也可通过结合语义或统计的挖掘方法。但当前的难点是上下位的标准较难统一，通常需要结合领域需求，对算法挖掘结果进行修正。
③ 图谱打标：如何构建标签和商户供给的关联关系？
给定一个标签集合，通过标签及其同义词在商户UGC/团单里出现的频率，卡一个阈值从而获取候选tag-POI。这样会出现一个问题是，即使是频率很高但不一定有关联，因此需要通过一个商户打标判别模块去过滤bad case。
商户打标考虑标签与商户、用户评论、商户Taxonomy等三个层次的信息。具体来讲，标签-商户粒度，将标签与商户信息（商户名、商户三级类目、商户top标签）做拼接输入到Bert模型中做判别。
微观的用户评论粒度，判断每一个标签与提到该标签的评论（称为evidence）之间是正面、负面、不相关还是不确定的关系，因此可当作四分类的判别模型。我们有两种方案可选择，第一种是基于多任务学习的方法， 该方法的缺点在于新增标签成本较高，比如新增一个标签，必须为该标签新增一些训练数据。笔者最终采用的是基于语义交互的判别模型，将标签作为参数输入，使该模型能够基于语义判别，从而支持动态新增标签。
基于语义交互的判别模型，首先做向量表示，然后是交互，最终聚合比较结果，该方法的计算速度较快，而基于BERT的方法，计算量大但准确率较高。我们在准确率和速度上取balance，例如当POI有30多条的evidence，倾向于使用轻量级的方式；如果POI只有几条evidence，可以采用准确率较高的方式进行判别。
从宏观角度，主要看标签和类目是否匹配，主要有三种关系：一定不会，可能会，一定会。一般通过商户层关联结果进行投票结果，同时会增加一些规则，对于准确率要求较高时，可进行人工review。
④ 图谱应用：所挖掘数据的直接应用或者知识向量表示应用
在商户知识问答相关的场景，我们基于商户打标结果以及标签对应的evidence回答用户问题。
首先识别用户query中的标签并映射为id，然后通过搜索召回或者排序层透传给索引层，从而召回出有打标结果的商户，并展示给C端用户。A/B实验表明，用户的长尾需求搜索体验得到显着提升。此外，也在酒店搜索领域做了一些上线实验，通过同义词映射等补充召回手段，搜索结果有明显改善。
主要采用GNN模型实现，在构图中构建了两种边，Query-POI点击行为和Tag-POI关联信息；采用Graph Sage进行图学习，学习的目标是判断Tag和POI是否有关联关系或者Query和POI是否点击关系，进一步依据关联强度进行采样。上线后结果显示，在仅利用Query-POI信息构图时，线上无收益，在引入Tag-POI关联信息后线上效果得到显着提升。这可能是因为排序模型依赖于Query-POI点击行为信息去学习，引入Graph Sage学习相当于换了一种学习的方式，信息增益相对较少；引入Tag-POI信息相当于引入了新的知识信息，所以会带来显着提升。
此外，仅接入Query-POI向量相似度线上效果提升不佳，将Query和POI向量接入后效果得到显着提升。这可能是因为搜索的特征维度较高，容易忽略掉向量相似度特征，因此将Query和POI向量拼接进去后提升了特征维度。
该任务通过当前已知的Item去预测用户点击的Masked Item。比如说获取Item的上下文表征的时候，将相关的Attribute信息也进行向量表征，从而去判断Item是否有Attribute信息。
此外，还可以做Masked Item Attribute 预测，从而将标签的知识图谱信息融入到序列推荐任务中去。实验结果表明，引入知识信息后的准确率在不同的数据集上均有数量级的提升。同时，我们也做了线上转化的工作，将Item表征做向量召回；具体来说，基于用户历史上点击过的Item去召回topN相似的Item，从而补充线上推荐结果，在美食列表推荐页有显着提升。
--
菜品知识图谱的构建目标，一方面是构建对菜品的系统理解能力，另一方面是构建较为完备的菜品知识图谱，这里从不同的层次来说明菜品知识图谱的构建策略。
** * 菜名理解**
菜名中蕴含着最精准、获取成本最低的菜品信息，同时对菜名的理解也是后续显式知识推理泛化能力的前提。首先是抽取菜名的本质词/主体菜，然后序列标注去识别菜名中的每个成分。针对两种场景设计了不同的模型，对于有分词情况，将分词符号作为特殊符号添加到模型中，第一个模型是识别每个token对应的类型；对于无分词情况，需要先做Span-Trans的任务，然后再复用有分词情况的模块。
菜名理解是一个较为重要的信息来源，但是所蕴含的知识相对有限，从而提出了基于深度学习模型进行初步字符推断，可实现对不同字面表述的泛化处理。但是对需要专业知识的case表现欠佳，偶尔在字面极其匹配时出现case。
从知识内容丰富的文本中挖掘某些菜谱的基础知识，来构建源知识库；然后通过泛化推理去映射到具体SKU中。在食材推理中，比如菜品种有多道红烧肉，统计10道五花肉中有4道是指五花肉，6道是指带皮五花肉，因此肉就转化为带皮五花肉。对应地，佛跳墙有多道菜谱，先通过统计每种食材出现的概率，可以卡一个阈值，然后表明该菜谱的食谱是什么。
多源数据挖掘，基于菜名理解结果构建solid knowledge triple，同时也依赖菜名理解结果泛化规则。该策略主要适用于处理食材、功效、人群等标签。该方法准确率OK，有一定泛化能力，但覆盖率偏低。
业务内有一些比较好用的训练数据，例如1000万商户编辑自洽的店内分类树。基于该数据可产生5亿的 positive pairs 和 30G corpus。在模型训练中，会随机替换掉菜谱分类的 tab/shop，模型判断 tab/shop 是否被替换；50%的概率drop shop name，使得模型仅输入菜名时表现鲁棒。同时，对模型做了实体化改进，将分类标签作为bert的词进行训练，将该方法应用到下游模型中，在10w标注数据下，菜谱上下位/同义词模型准确率提升了1.8%。
首先使用ReseNet对菜谱图片进行编，使用Bert模型对菜谱文本信息做编码，通过对比学习loss去学习文本和店菜的匹配信息。这里采用双塔模型，一方面是下游应用较为方便，单塔模型可独立使用，也可inference出菜品图片的表示并缓存下来；另一方面是图片内容单纯，暂无交互式建模的必要。训练目标分别是图片与店菜匹配、图片与菜名对齐，图片与Tab对齐。
可基于多模态信息做菜品品类预测或者菜谱信息补全。比如，预测“猪肉白菜”加上了图片信息将更加直观和准确。基于文本和视图模态信息进行多视图半监督的菜谱属性抽取，以烹饪方式抽取为例，首先通过产生烹饪方法训练样本（红烧肉-红烧）；然后采用CNN模型去训练预测菜谱烹饪方法，指导Bert模型Finetune文本模型或者多模态模型，基于商户/tab/菜品及评论信息预测菜品烹饪方法；最终对两个模型进行投票或者将两个特征拼接做预测。
综上，我们对菜品知识图谱构建进行相应的总结。菜品理解比较适合SKU的初始化；深度学习推理模型和显式推理模型比较适合做同义词、上下位、菜系等；最终是想通过多模态+结构化预训练和推理来解决单模态信息不完整、属性维度多、需要大量标注数据等问题，因此该方法被应用到几乎所有的场景中。
今天的分享就到这里，谢谢大家。
分享嘉宾：