datalake解决了什么？是否会持续温而不火
概述
自2014年开始，data lake（数据湖）这个概念就出现了，一直持续发展，虽然各大云商也相继推出了自己的产品，如Amazon AWS、Google Cloud、Microsoft Azure等，但数据湖的发展可以用“不温不火”来形容。
这篇文章，带大家一探data lake为何物，为何有机会发展，而又鹅行鸭步背后有何逻辑！
Data lake到底是什么？面对如此简单的一问，江湖各家大厂家却是各执一词，扑朔迷离。各家的思路基本上就是把已有的基础产品再包装，形成非面向业务场景的松散解决方案。
如Amazon AWS把data lake包装为: S3存储、数据目录、数据冷备；并辅之以数据移动工具、数据分析工具、机器学习工具。
而部分厂商更愿意把它定义为hadoop本身...
既然没有明确的功能定义，从理论层面探索data lake就变的没什么实际意义了，这也是市场在这上面踟蹰不前的一个原因，这玩意到底是啥都说不清，凭什么给你钱？
那咱们就转换下思路，追本溯源，从大数据的发展历程来看下data lake的产生的必要性、以及有无壮大的原动力。
回首传统数据仓库（data warehouse）
从业务流程上，传统data Warehouse是从数据需求（问题）角度出发，甄选业务场景数据源、按照数仓范式清洗与建模、并按照主题还原为可信的业务过程后，给业务方重复使用，也就是所谓的数据集市（data Mart）。
总结下来传统数仓的理念还是管控：管控数仓架构、管控数据流向、管控业务场景。
从data Warehouse数据流动角度看，整个流程如下：
data Warehouse系统架构
传统数据仓库面临的挑战
随着公司快速发展，面临的几个矛盾
-
data mart模式导致的烟囱式建设与数据需跨业务线广泛连接之间的矛盾
-
数据ETL、数据建模工作的响应速度与数据反哺业务迭代创新之间的矛盾
-
数据赋能与业务场景探索的脱节
通过上面的阐述，稍作抽象，即可发现一个有趣的现象：
-
工作职责上， 更多数据工作正在从IT向DS（数据科学家，下同）过渡，IT倾向于与DS解耦
-
工作方式上，在 数据从辅助决策向驱动决策升级的过程中，工作模式从"提出问题（DS）-解决问题（IT）"逐步向"场景化的泛问题-分析数据提出具体问题-分析数据-解决具体问题"的工作方式转换
在这个背景下，为了解决这些问题，业界发起了对data lake使命和架构的的探讨...
什么是data lake
注：为了维持定义的精确性，下面几段简单的英文就不做翻译了，敬请谅解 :)
从Amazon AWS得到的解释
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
从维基百科得到的解释
A data lake is a system or repository of data stored in its natural format,usually object blobs or files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, analytics and machine learning.
A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video).
受到的质疑与挑战
One criticism about the data lake is that the concept is fuzzy and arbitrary. It refers to any tool or data management practice that does not fit into the traditional data warehouse architecture.
简单而言，data lake就是有一个中心化的存储，所有的数据以它本来的形式（来自RMDB的结构化数据、CSV/JSON/XML等半结构化数据、documents等非结构化数据、甚至image/audio等二进制数据）都放到这个存储里， 进而为后续的报表、可视化分析、实时分析、以至于机器学习提供数据支撑。
data lake架构
为了应对传统数据仓库面临的问题，业界给出了不同的解决方案，下面的轴辐式（Hub and Spoke）架构也是其中之一：
数据湖hub and spoke模式架构
HUB（轴）要解决的问题：
-
统一存储：Centralized, singular, schema-less data store with raw (as-is) data as well as massaged data
-
索引与检索数据：Ability to map data across sources and provide visibility and security to users， Catalog to find and retrieve data
-
数据安全：Ability to manage security, permissions and data masking
-
自助服务：Supports self-provisioning of data management, and analytic tools without IT intervention
SPOKE（辐）需要解决的问题：
-
支持业务团队以自助服务的形式处理数据的可视化、数据探索、数据协作等业务问题
-
IT团队提供相应工具链、安全沙箱、标准化数据服务等基础设施
数据架构的演进趋势
大数据为了赋能业务，从数据基础建设、业务快速迭代两个角度来看，数据和组织架构正以下面的方式演进：
现代化数据与组织架构变迁趋势
特别说明：上图并非说IT/ETL的需求变少了，而是为了说明DS的业务需求和能力需求变的更多和更强了。
一道鸿沟
这么一弄，问题就来了，即使一个良好定义的数据仓库，在数据检索、理解上都存在相当的难度，这种原汁原味存放原始（非结构化）数据的地方，用户如何检索数据呢？怎么理解这些原始数据的业务含义呢？随着数据量的膨胀，这个问题会愈演愈烈，直到变成数据沼泽。
data lake绝不是一个简单的把原始数据以它原有的样子放到一起，用户就可以happy的进行可视化、洞察和分析的，因为这和他们需要的这些服务之间，有一道不可逾越的鸿沟。这道鸿沟需要良好定义的data lake架构来解决。
这个良好定义的data lake架构，目前来看就是“数据治理”，我们需要把重心从系统建设提升到数据建设，在“数据治理”的基础上，为上层业务提供自助化的服务。因此我们还有如下的几点收获：
-
data lake与data warehouse的理念不同，相对于data Warehouse的注重数据管控，data lake更倾向于数据服务
-
data lake对数据从业人员的素质要求更高； 对数据系统的要求更高，要防止数据湖变 数据沼泽 ,此时就需要借助现代化的数据治理能力
-
data lake与data warehouse不是互斥的。当前条件下，data lake并不能完全替代warehouse。尤其是对于已经使用data warehouse的公司，这种情况下warehouse可以作为data lake的一个数据来源
总结
传统的数据仓库模式，确实在快速发展的企业面前显的力不从心。
data lake以数据治理为基础、一套自助服务为抓手的工具链来赋能业务发展，这套理论是否是最适合现代企业（尤其是快速创新的企业）的，在一定程度上可以，但还需要持续验证。但是有一点值得注意，业界在data lake的尝试上一般都会忽视数据治理的重要性，这是很危险的，由它导致的数据沼泽也是企业对data lake持续观望的愿意之一。
另外，现在崛起的数据中台，它完全以数据治理、数据服务为核心理念而建，并比data lake更贴近业务场景，这也是数据中台方兴未艾的一个原因。
如对大数据和系统架构感兴趣，欢迎关注 微信公众号 持续关注更新文章和更新：）
扫一扫关注微信公众号
