欣和，一家創建於 1992 年的煙臺企業，依靠做醬油起家，經過二十多年的發展產品足跡已經遍佈全球 60 多個國家，形成了以高端調味品爲核心產業，輻射農業種植、物流運輸、出口商貿、電子商務等多產業鏈的大型零售企業。這樣一家傳統零售企業，他們的大數據體系帶有怎樣的風格和味道？
作爲國內老牌傳統零售企業的代表，欣和敏銳的發現，無論企業原有的資金有多龐大，基礎有多結實，在互聯網、數字化的衝擊下，傳統的零售企業如果不做數字化轉型，就將會面臨流量池與用戶池枯竭的情況。
欣和在 2014 年踏上了建立在公有云之上的數字化轉型快車道。目前已經構建起一套完善的大數據支撐體系，支撐財務、倉儲、銷售和市場等讀主題的在線複雜維度及時分析，打破了各業務與系統間的數據信息壁壘。
在整個數字化建設的過程中，圍繞數據的處理，是貫穿始終的一條主線。伴隨着業務的快速擴張，數據量呈現大規模增長，傳統的數據架構遭遇性能瓶頸。零售業在轉型過程中應該如何應對這些壓力？關於這點，欣和信息部部長王相會有着自己的見解。
來自業務運營與技術的雙重壓力，最終結果就是數字顛覆
數據的價值以及後臺架構的敏捷性正在越來越重要。
首先要談的一個詞是數字顛覆，這是幾乎所有傳統企業已經談論了很多年的一個詞。欣和作爲國內領先的零售企業，同樣面臨被數字顛覆的風險。這種風險來自於社會與流量兩個層面。社會層面，貿易戰，消費升級變成消費分級，人口紅利消失，城鎮化紅利變緩等等；在流量層面，線上流量都被 BATJ 和及各自媒體拿走了，獲客成本一下增長到 200 一人。線下只能通過經銷商做深度經銷，無法直接觸達到消費者。
來自於業務數據與技術實現所帶來的雙重壓力。
- 業務數據層面，目前業務上所收集到的數據大多分散且標準不統一，系統之間極易形成信息壁壘；其次內部無法快速診斷出現有的業務經營情況，無法很好的支持運營與決策；同時也無法直觀看到營銷環節中各個指標情況；最後系統間所產生的衆多中間層孤島，使得信息不流通，導致企業對市場的感知力弱。
- 技術層面，分爲三個方向，首先是數據平臺，之前大部分企業的數據平臺都是以數據倉庫的結構爲主，無法處理大批量的數據計算以及非結構化的計算；架構方面，資源的配置和變更缺乏彈性，不能夠快速適應業務的發展和變化；人才方面，自建大數據平臺的難度是很大的，因此需要把有限的人才和精力投入到業務中來。
欣和的數字化轉型，需要統一的數據平臺來驅動變革
欣和的數據轉型是基於數據湖來進行的， 湖，即存儲海量數據不要求統一的格式，且可供任意目的分析的數據承載體系。
數據湖基本上有三個核心，分別爲海量存儲且不限制擴展；結構化、圖片、音頻等非結構化的數據都能存儲；可提供任意目的的分析。
因此數據湖更是大數據分析管道中重要組成部分，它存儲了所有源數據，並且提供了一個可供有權限的用戶訪問並分析數據的空間。爲了搭建數據湖，欣和從兩個大的方向進行了技術統一與變革，分別是口徑層面和平臺層面。
統一口徑
欣和的大數據治理，從下往上遵循着“底層基礎到上層表現”的來邏輯進行。底層基礎分爲數據基礎以及運作流程，上層表現則是分析決策功能。由最底層的數據基礎來爲上層數據的可視化、規則定義、數據分析甚至是業務決策來提供技術上的支撐。
現在大家可能都認爲搭建底層的數據架構是最基礎的內容，但是對於一家迫切轉型互聯網的傳統企業來說，這“夯實數據基礎，統一口徑提供單一的事實依據”的第一步挑戰卻無比困難，因爲要從以下這四個方面對數據基礎進行變革：
- 數據採集準確，原始信息錄取必須被錄入準確，從loge裏面考覈關鍵信息，確保被採集到數據的及時準確性；
- 主數據規範一致，對每個主數據的可信源進行指定，其它系統如果需要則要從可信源處集成，而並非各自擁有獨立的一套編碼；
- 口徑統一，把每一個指標口徑定義清晰化，將問題聚焦在數據處理上，與業務確認達成一致；
- 架構優化，通過重新設計技術架構平臺來滿足數據處理的靈活性和性能問題。
統一平臺，在公有云上部署大數據湖
統一平臺，即將數據平臺全部切換並部署在公有云上。爲什麼要這麼做？
- 快速響應，這樣可以滿足大數據湖對於海量甚至無法預測的數據處理請求能力，從而能夠快速響應和聚焦業務，這樣可以隨時根據業務需求調整數據分析與處理能力；
- 靈活擴展，互聯網的產品迭代速度非常快，因此保持敏捷性非常重要，在數據量急速增加時可隨時生成服務器對數據平臺進行擴展；
- 貼近未來數據源，未來大部分數據的來源都會集中在互聯網上，將平臺部署在雲端可以減少傳輸成本；
欣和大數據體系，帶有“零售特色”的雲端數據湖建設
基於Lambda架構的欣和數據湖建設
通過構建數據湖，打破了原有各個系統的壁壘，提供了統一的數據服務，讓整個業務能夠專注在問題本身，快速的洞察到市場，快速解決問題，而非把時間用在不同口徑數據的對比上。
上圖是欣和的數據湖的架構圖，根據欣和的業務特點選擇了 Lambda 架構，採用批處理和流處理結合的方式搭建數據湖，整個架構分爲以下五個部分：
- 實時處理層，主要針對流數據的處理，通過keniss接入數據，藉由 Spark 來進行數據處理；
- 批量處理層，分爲數據接入部分和數據處理部分。數據接入部分，通過不同的工具將數據庫以及文本數據接入到數據湖內；數據處理部分，基於Redshift和分層設計理念來構建數據倉庫，數據主要分三層來存儲，從底層到上層依次爲貼源層-模型層-結構層，以此確保應用層的改動不會影響到底層的數據結構。
- 數據挖掘，主要爲其它業務系統提供AI及機器學習算法的支持
- 數據服務層，通過微服務的 API 方式來對外輸出統一的數據服務，將批量數據和實時數據結合起來；通過數據服務層可以做到前後端分離，使前端可以無感知後端的結構調整，充分體現Data As Service的思想。此外也能夠讓前端團隊專注在應用的業務支持上，後端團隊專注在數據處理上，基本上形成了數據中臺的格局。
- 數據應用層，提供自定義分析的tableau等敏捷和固定報表，以及一些自研的數據產品。
欣和的數據湖是建立在 AWS 上的，整個數據湖，從數據源開始，藉助 Talend 將數據源數據抽取的S3上，在由 Redshift 本身將 S3 數據 copy 到 Redshift 裏做分層計算，再將結果數據卸載到 S3 上，然後通過在 EMR hive 裏建 S3 的外部表映射，作爲Kylin的數據源，然後在 Kylin 裏構建 cube，最後通過 Kylin 的 restapi 接口將各個指標服務註冊在 API 網關上，從而提供標準的服務。Glacier在這裏作爲歸檔服務，將歷史的數據備份，元數據備份放到Glacier裏做歸檔。
從控制流上來看，基本是用 Talend 來進行調度，包括數據上雲、ETL工作調度以及 Cube 的構建任務等。
雲上提升大數據分析性能
Kyligence 優秀的計算性能、與雲平臺的無縫集成、一鍵部署、自動伸縮和智能運維等功能，讓大數據能與雲計算能夠更好的結合。
Kyligence作爲欣和數據湖的數據服務引擎，在數據湖和應用之間搭起了一個橋樑，或者是說數據加速層，起到了承上啓下的作用。作爲平臺中多維前端數據服務，
Kyligence的原理是與計算技術，主要是通過雲計算的技術用空間換時間，從 hive 裏獲取數據，通過 EMR 提供計算，最後再把數據存儲在 S3，通過標準的 SQL 訪問來實現海量數據的秒級查詢響應，90%的查詢都能在4秒之內響應，並很好的提供了高併發支持，相較之前的架構有了極大的提升。
如果說Kyligence Enterprise是數據湖和數據應用之間的橋樑，那麼Kyligence Cloud就是大數據和雲計算之間的橋樑。通過 Kyligence Cloud 將 Kylin 一鍵部署到雲端，用4個小時就可以刷新90多個Cube，保障了關鍵業務數據處理工作的實時性，且整個伸縮過程無需人爲干預，避免了複雜的監控和運維管理，很好的節約了人力成本，完成敏捷交付。Kyligence enterprise有很大的特點，除了集羣管理之外還能夠很好的利用公有云上的安全彈性計算和存儲分離的特性，真正做到大數據和雲計算的完美的結合。
大數據平臺建設心得：大處着眼，小處着手
通過構建整個的數據湖，欣和打破了原有各個系統間的數據壁壘，提供了統一的數據服務，讓業務專注在問題本身。因此在構建數據平臺時，應該要有統一規劃，從一個項目開始設計和迭代不斷的優化，避免一開始就大而全的平臺落地的時候會有一些問題。最後，欣和信息部部長王相會，爲企業構建數據平臺提出了以下四點建議：
- 項目，從一個獨立項目出發，例如將兩個之前獨立的生產信息數據合併到單一的分析工作流中；
- 基礎，嘗試從新的數據源着手並將其引入大數據平臺，搭建起完整的數據清洗和轉換過程，直到生成最終場景所需的數據；
- 遷移，從本地遺留的數據平臺逐步搬遷到雲上，並不斷優化舊有數據存儲和處理流程；
- 再造，基於新創建的雲上大數據平臺和已有的業務經驗積累，提出創新的預測和決策算法
歸根結底，傳統企業擁抱互聯網，很大程度上都是被數據“所逼”，因此最終還是要回歸到數據本身上來，建立起高效、統一、敏捷的數據分析平臺也就尤爲重要。
（本文部分資料摘取自欣和信息部部長王相會在Kylin Data Summit上的演講內容。）