一家调味料公司，做出来的大数据治理带着怎样的“味道”？

欣和，一家创建于 1992 年的烟台企业，依靠做酱油起家，经过二十多年的发展产品足迹已经遍布全球 60 多个国家，形成了以高端调味品为核心产业，辐射农业种植、物流运输、出口商贸、电子商务等多产业链的大型零售企业。这样一家传统零售企业，他们的大数据体系带有怎样的风格和味道？  

作为国内老牌传统零售企业的代表，欣和敏锐的发现，无论企业原有的资金有多庞大，基础有多结实，在互联网、数字化的冲击下，传统的零售企业如果不做数字化转型，就将会面临流量池与用户池枯竭的情况。

欣和在 2014 年踏上了建立在公有云之上的数字化转型快车道。目前已经构建起一套完善的大数据支撑体系，支撑财务、仓储、销售和市场等读主题的在线复杂维度及时分析，打破了各业务与系统间的数据信息壁垒。

在整个数字化建设的过程中，围绕数据的处理，是贯穿始终的一条主线。伴随着业务的快速扩张，数据量呈现大规模增长，传统的数据架构遭遇性能瓶颈。零售业在转型过程中应该如何应对这些压力？关于这点，欣和信息部部长王相会有着自己的见解。

1 来自业务运营与技术的双重压力，最终结果就是数字颠覆

数据的价值以及后台架构的敏捷性正在越来越重要。

首先要谈的一个词是数字颠覆，这是几乎所有传统企业已经谈论了很多年的一个词。欣和作为国内领先的零售企业，同样面临被数字颠覆的风险。这种风险来自于社会与流量两个层面。社会层面，贸易战，消费升级变成消费分级，人口红利消失，城镇化红利变缓等等；在流量层面，线上流量都被 BATJ 和及各自媒体拿走了，获客成本一下增长到 200 一人。线下只能通过经销商做深度经销，无法直接触达到消费者。

来自于业务数据与技术实现所带来的双重压力。

• 业务数据层面，目前业务上所收集到的数据大多分散且标准不统一，系统之间极易形成信息壁垒；其次内部无法快速诊断出现有的业务经营情况，无法很好的支持运营与决策；同时也无法直观看到营销环节中各个指标情况；最后系统间所产生的众多中间层孤岛，使得信息不流通，导致企业对市场的感知力弱。

• 技术层面，分为三个方向，首先是数据平台，之前大部分企业的数据平台都是以数据仓库的结构为主，无法处理大批量的数据计算以及非结构化的计算；架构方面，资源的配置和变更缺乏弹性，不能够快速适应业务的发展和变化；人才方面，自建大数据平台的难度是很大的，因此需要把有限的人才和精力投入到业务中来。

2 欣和的数字化转型，需要统一的数据平台来驱动变革

数据湖 - 面向未来的大数据思想

欣和的数据转型是基于数据湖来进行的， 湖，即存储海量数据不要求统一的格式，且可供任意目的分析的数据承载体系。

数据湖基本上有三个核心，分别为海量存储且不限制扩展；结构化、图片、音频等非结构化的数据都能存储；可提供任意目的的分析。

因此数据湖更是大数据分析管道中重要组成部分，它存储了所有源数据，并且提供了一个可供有权限的用户访问并分析数据的空间。为了搭建数据湖，欣和从两个大的方向进行了技术统一与变革，分别是口径层面和平台层面。

统一口径

欣和的大数据治理，从下往上遵循着“底层基础到上层表现”的来逻辑进行。底层基础分为数据基础以及运作流程，上层表现则是分析决策功能。由最底层的数据基础来为上层数据的可视化、规则定义、数据分析甚至是业务决策来提供技术上的支撑。

现在大家可能都认为搭建底层的数据架构是最基础的内容，但是对于一家迫切转型互联网的传统企业来说，这“夯实数据基础，统一口径提供单一的事实依据”的第一步挑战却无比困难，因为要从以下这四个方面对数据基础进行变革：

1. 数据采集准确，原始信息录取必须被录入准确，从 loge 里面考核关键信息，确保被采集到数据的及时准确性；

2. 主数据规范一致，对每个主数据的可信源进行指定，其它系统如果需要则要从可信源处集成，而并非各自拥有独立的一套编码；

3. 口径统一，把每一个指标口径定义清晰化，将问题聚焦在数据处理上，与业务确认达成一致；

4. 架构优化，通过重新设计技术架构平台来满足数据处理的灵活性和性能问题。

统一平台，在公有云上部署大数据湖

统一平台，即将数据平台全部切换并部署在公有云上。为什么要这么做？

1. 快速响应，这样可以满足大数据湖对于海量甚至无法预测的数据处理请求能力，从而能够快速响应和聚焦业务，这样可以随时根据业务需求调整数据分析与处理能力；

2. 灵活扩展，互联网的产品迭代速度非常快，因此保持敏捷性非常重要，在数据量急速增加时可随时生成服务器对数据平台进行扩展；

3. 贴近未来数据源，未来大部分数据的来源都会集中在互联网上，将平台部署在云端可以减少传输成本；

3 欣和大数据体系，带有“零售特色”的云端数据湖建设

基于 Lambda 架构的欣和数据湖建设

通过构建数据湖，打破了原有各个系统的壁垒，提供了统一的数据服务，让整个业务能够专注在问题本身，快速的洞察到市场，快速解决问题，而非把时间用在不同口径数据的对比上。

基于 Lambda 架构的欣和数据湖设计

上图是欣和的数据湖的架构图，根据欣和的业务特点选择了 Lambda 架构，采用批处理和流处理结合的方式搭建数据湖，整个架构分为以下五个部分：

1. 实时处理层，主要针对流数据的处理，通过 keniss 接入数据，借由 Spark 来进行数据处理；

2. 批量处理层，分为数据接入部分和数据处理部分。数据接入部分，通过不同的工具将数据库以及文本数据接入到数据湖内；数据处理部分，基于 Redshift 和分层设计理念来构建数据仓库，数据主要分三层来存储，从底层到上层依次为贴源层 - 模型层 - 结构层，以此确保应用层的改动不会影响到底层的数据结构。

3. 数据挖掘，主要为其它业务系统提供 AI 及机器学习算法的支持

4. 数据服务层，通过微服务的 API 方式来对外输出统一的数据服务，将批量数据和实时数据结合起来；通过数据服务层可以做到前后端分离，使前端可以无感知后端的结构调整，充分体现 Data As Service 的思想。此外也能够让前端团队专注在应用的业务支持上，后端团队专注在数据处理上，基本上形成了数据中台的格局。

5. 数据应用层，提供自定义分析的 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 on AWS

Kyligence 作为欣和数据湖的数据服务引擎，在数据湖和应用之间搭起了一个桥梁，或者是说数据加速层，起到了承上启下的作用。作为平台中多维前端数据服务，

Kyligence 的原理是与计算技术，主要是通过云计算的技术用空间换时间，从 hive 里获取数据，通过 EMR 提供计算，最后再把数据存储在 S3，通过标准的 SQL 访问来实现海量数据的秒级查询响应，90% 的查询都能在 4 秒之内响应，并很好的提供了高并发支持，相较之前的架构有了极大的提升。

如果说 Kyligence Enterprise 是数据湖和数据应用之间的桥梁，那么 Kyligence Cloud 就是大数据和云计算之间的桥梁。通过 Kyligence Cloud 将 Kylin 一键部署到云端，用 4 个小时就可以刷新 90 多个 Cube，保障了关键业务数据处理工作的实时性，且整个伸缩过程无需人为干预，避免了复杂的监控和运维管理，很好的节约了人力成本，完成敏捷交付。Kyligence enterprise 有很大的特点，除了集群管理之外还能够很好的利用公有云上的安全弹性计算和存储分离的特性，真正做到大数据和云计算的完美的结合。

4 大数据平台建设心得：大处着眼，小处着手

通过构建整个的数据湖，欣和打破了原有各个系统间的数据壁垒，提供了统一的数据服务，让业务专注在问题本身。因此在构建数据平台时，应该要有统一规划，从一个项目开始设计和迭代不断的优化，避免一开始就大而全的平台落地的时候会有一些问题。最后，欣和信息部部长王相会，为企业构建数据平台提出了以下四点建议：

1. 项目，从一个独立项目出发，例如将两个之前独立的生产信息数据合并到单一的分析工作流中；

2. 基础， 尝试从新的数据源着手并将其引入大数据平台，搭建起完整的数据清洗和转换过程，直到生成最终场景所需的数据；

3. 迁移，从本地遗留的数据平台逐步搬迁到云上，并不断优化旧有数据存储和处理流程；

4. 再造，基于新创建的云上大数据平台和已有的业务经验积累，提出创新的预测和决策算法

归根结底，传统企业拥抱互联网，很大程度上都是被数据“所逼”，因此最终还是要回归到数据本身上来，建立起高效、统一、敏捷的数据分析平台也就尤为重要。

（本文部分资料摘取自欣和信息部部长王相会在 Kylin Data Summit 上的演讲内容。）