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的初始化；深度學習推理模型和顯式推理模型比較適合做同義詞、上下位、菜系等；最終是想通過多模態+結構化預訓練和推理來解決單模態信息不完整、屬性維度多、需要大量標注數據等問題，因此該方法被應用到幾乎所有的場景中。
今天的分享就到這里，謝謝大家。
分享嘉賓：