编辑导语：什么是数据湖？企业可以利用数据湖尽可能保持业务数据的可还原性，解决存储全域原始数据的问题；而数据中台的存在则可以帮助帮助企业提升业务处理效率。不过并非所有的企业都需要设立数据中台。本篇文章里，作者对数据湖与数据中台进行了详细的解释，一起来看一下。
引言：文接上回，没有阅读第一部分的小伙伴请点击《10分钟带你了解数据库、数据仓库、数据湖、数据中台的区别与联系（一）》查看，那我们就开始第二部分的内容吧，如有不准确的地方，还请希望大家进行指正。
一、数据湖
上文通过有序性与开放性分别对数据仓库与数据湖进行描述并对比，现在我们来详细地了解一下数据湖。
1. 数据湖的起源
数据湖主要是为了解决存储全域原始数据，其名称中的“湖”字将数据湖的含义表现得淋漓尽致。像企业的生产数据（非结构化数据与结构化数据）、业务历史数据、临时数据，诸如IOT设备，移动应用程序以及传统的设备中返回的第三方数据都可以通过ETL工具形成的“水管”存储进数据湖中。
例如笔者之前在工作过程中接触的手机信令数据、GPS返回的定位数据等，这些数据实际上并没有预先定义好相应的数据结构，这就意味着可以先将数据存储起来而无需对数据进行结构化处理，也无需明确要进行什么分析，由数据从业人员在后续工作中进行探索和尝试。
上文中提到的结构化数据和非结构化数据，那什么是结构化/非结构化数据呢？下面我们就解释下两者的区别与联系。
2. 何为结构化/非结构化数据
举个例子。
我们收集到了这样一堆文字信息：
- 有个学生叫小赵，男的，97年的，土木工程系的，北京的；
- 有个学生叫小李，98年的，女的，外语系的，江苏苏州的；
- ·····
诸如此类的文字信息有几万行，我们存在word中，亦或是纸质版文件经由我们扫描成图片格式的，这类就可以称为非结构化数据。假设有需求将这些文字信息中按照性别、籍贯、专业等等统计出来，我们在第一篇文章中提到了关系型数据库，用相关的技术和工具将这些文字信息进行处理，处理后的数据就是结构化数据。
所以结构化数据的定义：是由二维表结构来逻辑表达和实现的数据，严格地遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。
非结构化数据：不适于由数据库二维表来表现的非结构化数据，包括所有格式的办公文档、 XML 、 HTML 、各类报表、图片和音频、视频信息等。
3. 数据湖的作用
回归正题，企业为什么要建立数据湖呢，首先数据湖中存在一个重要的组成部分ODS（Operating Data Store，操作数据存储），大家是否记得上一篇文章讲过OLTP（On-Line Transaction Processing），OLTP侧重于基本的、日常的事务处理，而我们现在提到的ODS就是OLTP数据的快照与历史。
我们在上文的数据库一节描述时提到业务数据库与数据仓库的结构不同，业务数据库是为OLTP设计的，是系统的实时状态的数据，而数据仓库的数据是为OLAP的需求建设的，是为了深度的多维度分析。所以这样就会造成基于数据仓库的数据分析会产生以下的限制：
- 由于数据仓库的架构设计事先订好的，很难能做到全面覆盖，因此基于数据仓库的分析是收到事先定义的分析目标及数据库的框架限制。
- 从OLTP的实时状态到OLAP的分析数据的转换会有不少信息损失，举个例子来说，某个用户在某个应用程序中钱包的余额，在OLTP系统中仅仅只会按照业务发生情况对钱包中的余额进行实时更新，然而在OLAP系统中也是仅仅会记录对该钱包操作的交易，如果想要去查询并分析该用户的历史余额就会比较麻烦。
而从根本上来讲，数据湖的最主要作用是尽可能保持业务数据的可还原性。数据湖的定位和搜索引擎类似，我们可以像在搜索引擎中检索数据一样，实现按需检索，即取即用，它存取这原始的未经改变的全量数据，可以存取、处理、分析。
4. 数据湖的发展
数据湖最早是2011年由Pentaho的首席技术官James Dixon提出的一个概念，他认为诸如数据集市，数据仓库由于其有序性的特点，势必会带来数据孤岛效应，而数据湖可以由于其开放性的特点可以解决数据孤岛问题。
但随着数据湖在各类企业的应用，大家都觉得：嗯，这个数据有用，我要放进去；那个数据也有用，我也要放进去；于是把所有的数据不假思索地扔进基于数据湖的相关技术或工具中，没有规则不成方圆，当我们认为所有数据都有用时，那么所有的数据都是垃圾，数据湖也变成了造成企业成本高企的数据沼泽。
所以这也是为什么“数据湖”叫“湖”，而不叫数据河，数据池亦或是数据海。
首先数据要能“存”，数据要够“存”，数据要有边界地“存”。企业级的数据是需要长期积淀的，所以是“数据湖”。
同时湖水天然会进行分层，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的。热数据在上层方便流通应用，温数据、冷数据位于数据中心的不同存储介质之中，达到数据存储容量与成本的平衡。
二、数据中台
我们终于迎来了最近几年很火的数据中台。网上有很多文章关于数据中台的介绍，什么Hive、Spark、Hadoop、Kalfa等等很多技术名词，听上去非常的高大上而且云里雾里的，会使初涉产品的我们望而却步。
所以接下来我们从何为中台、何为数据中台、数据中台可以做什么三个方面来讲讲数据中台。
1. 何为中台
首先抛开数据，中台这一概念这两年在国内大火。说起来源，网上文章都会提到这种组织是2015年马云参观Supercell的游戏公司借鉴过来的，并且后来“阿里巴巴”CEO逍遥子提出的组建的“大中台，小前台”的组织和业务体制。那么我们能用一个比较浅显的例子来理解“中台”一词么?
当然可以，有一家连锁且超级便宜的意大利西餐连锁店“萨莉亚”，相信大部分同学都光顾过，9元的意面，24的披萨，上菜速度超快，虽然比不上传统西餐，但相比于这个价位，属实很良心了，而且目前萨莉亚在中国已经开设了将近400家（截止2019年）分店。
那么萨莉亚保持价格低廉同时上菜效率高效的原因是什么？答案很简单，就是中央厨房进行粗加工，然后门店的厨师仅需要简单地烹饪即可端上餐桌。相比于传统餐厅采购（买菜）→配菜→做菜的环节，既减少门店厨师的数量，降低人工成本的同时又加快上菜速度。
回到我们研发流程来看，采购（买菜）→配菜环节就是我们研发的后台，他们帮助我们解决“有什么”；而配菜→做菜环节就是我们的业务前台团队，他们要做的就是根据客户的“口味”来“做什么”。
而配菜，蔬菜整理这个环节，也就是萨莉亚的“中央厨房”就相当于我们的中台，仅仅需要门店的需求，中央厨房就可以快速提供对应的材料，提高业务开发效率，减少重复开发成本。
2. 何为数据中台
介绍完了“中台”这一概念，数据中台相信大家也能举一反三。没错，对于采购来的“菜”就相当于数据，做出来的“菜”就相当于业务部门所以需要的数据应用。
那么配菜环节就相当于IT部门的各种数据算法，每道菜单独配菜效率慢且冗余度较高，于是“中央厨房”就对数据算法进行规范化，系统化。针对于业务部门所需要的各道菜提供粗加工的半成品，这就是“数据产品”。
这种“中央厨房”配菜的过程就相当于我们所说的“数据中台”。那么是不是每个企业都必须搭建数据中台么？数据中台在业务上能解决什么问题呢？
3. 数据中台能做什么
所有企业是否都需要搭建数据中台？首先我们知道企业引进一项技术或产品，不在于是否“时髦”，不在于是否“高科技”，而在于是否适合该公司目前的发展，是否能提高公司的利润，降低公司的成本。
首先数据中台的作用通过对中台及数据中台的描述，总结以下2点：
- 提供数据产品及数据服务，包括但不限于决策支持类工具（例如业务报表、大屏数据可视化展示）；数据分析类（BI商业智能、机器学习模型、数据挖掘）；数据检索（日志分析）等；
- 提升企业各部门的数据连通性，避免数据孤岛的产生。
根据以上提到数据中台的两个优势，针对一个企业是否搭建数据中台，亦或是说一个企业在一开始从零到一就要构建数据中台？笔者在此有几点自己的总结：
首先针对于不同的行业，尽管传统企业数字化改革正在路上且已经有很多行业已经改革成功，但是针对于大部分传统企业，别说数据中台，公司连数据仓库的时代都没有到来，“罗马不是一天建成的”抛去建设数据中台的财力，时间成本高昂不提，就是对于传统企业的业务流转模式，企业员工接受程度来说都是一条难以逾越的鸿沟，数据中台不可操之过急。
对于一些处于数据仓库时代的传统企业或互联网企业，由于各个部门不停无限地进行满足其业务支撑点取数要求、业务统计、看数需求，就可以尝试转型数据中台。
对初创企业，业务线单一且业务模式还经常不断变化，不断试错时，没有能力去进行数据中台的搭建，换言之就是“先活下去最重要”。
三、小结
本篇文章分两部分介绍了数据库、数据仓库、数据湖、数据中台的区别与联系。
关于数据有人说数据是新的石油资源，国家也将数据作为一种新型生产要素，与传统生产要素并列。
笔者曾经在泛互联网以及传统企业的业务部门都工作一段时间，由于各类原因，相比于泛互联网行业的数据化相比，传统企业的数据化之路并不一帆风顺。2020年8月，国务院国资委引发《关于加快推进国有企业数字化转型工作的通知》表现出各国有企业未来数字化转型将成为必然，如何协助传统企业进行数字化转型，利用数据驱动传统行业迸发新的活力对于数据产品经理，尤其是对ToB的数据产品经理将会是挑战与机遇。
笔者会继续努力与大家分享交流其他数据产品相关的文章与内容。
本文由 @快乐的给予 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议