舌尖上的大數據,怎麼挑動你的味蕾?

民以食為天,在餐桌上我們讓各式各樣的美食舒張味蕾。餐飲產業是全世界最誘人、最龐大、也最生氣勃勃的產業,從生產者到運輸者,從廚師到服務生,從雜貨店、超市到各式餐廳,從選擇餐點、用餐到結帳,從上游到下游牽涉層層環節。
評論
評論

民以食為天,在餐桌上我們讓各式各樣的美食舒張味蕾。餐飲產業是全世界最誘人、最龐大、也最生氣勃勃的產業,從生產者到運輸者,從廚師到服務生,從雜貨店、超市到各式餐廳,從選擇餐點、用餐到結帳,從上游到下游牽涉層層環節。每個環節之間都累積了大量數據,平均消費、等候時間、餐廳溫度、會員卡使用率、社群網站互動狀況⋯⋯但是即使現在已是 2015 年,相較金融、科技或醫療業,餐飲業對於大數據的運用依然相當有限,但從另一方面來說,也表示它的成長空間依然很大。本文舉出幾個餐飲產業使用大數據的案例,從既有的餐飲業者自我革新,到新創公司發揮創意企圖重新形塑飲食產業,甚至顛覆人們吃食的習慣。

Photo credit: 電影《料理絕配》劇照

縮短排隊時間、選出黃金店址

科技改變一切,有些敏銳的餐飲業者已在內部開始自我改革,美國辛辛那提超市連鎖店 Kroger 就分析了幾百萬會員的資料,為他們形塑個人化的購物體驗,給予不同特質的人不同的促銷活動與獎勵。實驗歷經十年大獲成功,95% 的業績成長來自老顧客。此外,他們也利用數據適時在每個分店調整價格、監測、調整庫存,甚至也解決了結帳排隊的困擾。Kroger 在門上安裝紅外線感應器,並從歷史數據推測顧客平均購物時間,將結帳時間從 4 分鐘縮短到不到 30 秒。

photo credit: MIKI Yoshihito

走在科技尖端的星巴克,當然也沒放過大數據,利用會員卡追蹤數據客製服務體驗已是基本款。星巴克最為人津津樂道的是使用地理資訊系統(GIS)決定在哪開設新店,不少美國快餐店也用這種方式比對車流量、消費群體分佈、安全資訊、商業組成型態等其它相關訊息,在選店的過程中節省大量開支。同時,這個區位數據,還有一些特別的用途,比如星巴克就能根據氣象數據,預測是否有熱浪來襲,將星冰樂的促銷時間與之配合。另外,決定在哪間店的選單上加上紅酒時,靠著這些數據,也能立刻區辨出何處有最多高消費人群、高消費需求。

蒐集菜單,滿足挑剔的嘴

歐美的菜餚名稱經常落落長一大串,所有食材與醬料、配菜全部寫得明明白白,因其中譯之後產生濃厚的異國風情「高級感」,台灣網友也依樣畫葫蘆,把滷肉飯等街頭小吃惡搞成西洋超長版,用以取笑崇洋媚外的人。

不過,詳細的菜名,在大數據時代可是相當珍貴的資源。美國芝加哥新創公司 Food Genius 就靠著收集全美各地餐廳的菜單,協助餐飲產業確定價格、食品與行銷趨勢。根據 2014 年中的報導,已有 11 萬份獨立菜單、1630 萬道菜式掌握在他們手中,餐館老闆隨時都能了解與食物相關的關鍵詞與短語,某一菜式的平均價格,以及品項增減的狀況。

如此一來,如 Kraft 這樣的連鎖餐廳,就能準確在西南菜餚流行高峰前,迅速為消費者奉上印第安綠辣椒或凍雞翅前菜,而不是等到這股風潮過去才反應過來,那顯然只會變成菜單上的滯銷品。Food Genius 也從無以數計的菜單中,分析各種蔬菜與各種義大利麵彼此的速配程度,或者在不同的菜餚中雞肉該用哪些烹調方式,才會呈現最佳風味。

Food Genius 的客戶不乏美國知名連鎖超市或餐廳,除了前面提及的 Kraft,Safeway、可口可樂都使用他們出產的報告作為行銷與業務的重要參考來源。

用資料促成餐飲世界的「民主化」

若說 Food Genius 是蒐集菜單,那 Dinner Lab 就是蒐集你我的味覺。

Dinner Lab 在直升機停機坪、工廠廠房、廢棄教堂、碼頭等不同的地方舉辦晚宴。photo credit: Dinner Lab

Dinner Lab 在全美各地開設「快閃店」,每週平均開設 19 間,讓才華洋溢卻苦無機會發揮的廚師,為渴望嘗鮮的人們送上創意料理。在觥籌交錯之間,參與者還是得保持意識清醒,因為這畢竟是「實驗室」,每個人都需針對菜色發表意見、在意見卡上分別評比每道菜餚的創新度、口味、菜量、溫度、佐餐酒是否合宜等等,這只是一部分而已,你還得上網完成一些延伸的個人問題,例如,你的戀愛關係狀態、你偏好的飲酒模式、你怎麼判斷自己是不是一個專業的美食家⋯⋯

每次舉辦晚宴都會收穫 750-1000 個資料點(data point),有了大量數據之後,廚師便能按照所有人的意見,調整菜式,降低開店的風險。又或者,Dinner Lab 也承接如婚宴、團體聚會的活動,但不同於一般制式外燴,如果新人指定非要「鮮蝦玉米粥」不可,他們就能就能依據過往累積的大量評分,快速找到最擅長這道菜的廚師。

今年 Dinner Lab 計劃開設一間「由數據驅動的餐廳」,讓廚師可以在其中實驗 2-3 個月,平衡自己的思想與大眾的味蕾後,才自行開業。「權力集中在少數人手上,餐廳的命運不該被權威的美食家評論左右,我認為各式各樣不同的喜好都應該考慮,但是人才與機會在烹飪界終有很大的斷層,我們希望可以民主化這個過程。」Dinner Lab 創辦人 Brian Bordainick 這麼說道。

建造世界最大植物資料庫,準備顛覆整個食品產業

研製出植物蛋黃醬、因而受到李嘉誠、比爾蓋茲、Peter Thiel 等名人熱烈追捧的矽谷新創公司 Hampton Creek,去年從 Google 挖角資深數據分析師 Dan Zigmond,準備顛覆整個食品產業,就是這麼宏大的野心,說服他心動跳槽。

吐司上的 Just Mayo 蛋黃醬。photo credit: Hampton Creek

Hampton Creek 創辦人 Josh Tetrick 認為,人們既有的飲食習慣百害而無一利,不健康、不環保,還會製造剝削、污染、不公不義、龐大的醫療支出等延伸負面作用。作為改善食物的初步嘗試,他們研究了 287 種植物,從中做出 344 種雞蛋替代品,又分析了雞蛋的 22 種功能成分,及研究了近 1550 種植物的分子水平,最終自 12 種植物提煉蛋白質製造出人造雞蛋 Beyond Eggs 與蛋黃醬 Just Mayo。

這段過程可說是苦盡甘來,現在 Hampton Creek 則要更進一步,建立全世界最大的「植物圖書館」,依樣畫葫蘆,以健康的方式製造更多營養且美味的食物。但這何嘗容易,畢竟世界上已有 870 萬已知植物種類,遑論每種植物底下還有更多分類。

不過他們相信自己辦得到,如果這座植物圖書館能夠真正創建,就可以整理出植物各自的特性,進行分析解讀,尋找何種植物與植物之間的關聯性,農夫便能運用這些資料,種植有益地球的新形態經濟作物,之後交由科學家研製更多新的「植物性食物」,更健康、更便宜,且對動物與環境的影響更低。

參考資料來源:

Data Is the Secret to this $15 Million Supper Club's Success
Menu-data startup Food Genius finds there are no national food trends, only local ones
Food Genius Helps Food Industry Understand Trends with Big Data Tools
How the food industry is making sense of big data
Data-licious: How Dinner Lab Used Feedback to Improve Food and Conversation
The Impact of Big Data on the Food Industry

歡迎加入"Inside" Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!