现今，数据湖泊在IT行业掀起了波澜。数据湖泊是将数据存储与数据管理关联，提供关于数据的分析功能——这种功能通常是其他分析系统的独立功能，如数据仓库或数据集市，作为数据梳理流程的一部分。
例如，数据仓库的提取、转化与加载预处理器将消费日志，这些日志记录了某个系统到达或插入某“操作数据存储”的时间。
但现今产业中，数据湖泊似乎至少有两个定义。一是源于存储公司，认为数据湖泊是磁盘存储基础设施，用于源数据的存储。另一个，主要由市场驱动，混合许多通常未混合的数据。根据我的定义，没有产商在销售全扩展的数据湖泊——相反，人们利用Hadoop来混合数据并自主研发的工具来访问数据。
作为初始供应商向现实世界实验抛出的炒作课题，用户发现数据中心集市的最佳实践并不适用于数据湖泊。为避免早期用户的错误，需要专注于数据湖泊的温和实现，而不是超大规模。
以下是在数据湖泊工作中的最佳实践。
请记住数据湖泊适用于探索
数据湖泊实现应该是实现企业扩展某个已存在分析的探索方式。数据湖泊中增加的数据类型来大部分来自于实时数据——例如，用户事务日志——实时分析系统一般不会提供长周期的分析功能。大多数现有的分析工具不足以提供应用程序行为的真实画像。数据仓库，“纯”Hadoop和其他数据管理方案可能导致重要数据丢失。
大数据分析系统提供商Pentaho公司首席技术官James Dixon在自己的博客上举了个例子：数据仓库这样的系统无法获得用户在购买流程中的每一步操作，但事务日志里有。类似购买流程这样的设计对某些数据架构师来说看似简单，但每步骤都可能有数分钟甚至几小时的滞后。
通过发现流程中的滞后，用户可以开始部署数据湖泊来绘制用户画像、购买相关的事务。探索型的分析很重要，也会影响到企业整体的分析能力，因为目前还不清楚在更深入分析客户日志时间戳后，会不会有什么新发现。
数据集市、数据湖泊和数据仓库之间的区别?
数据集市是数据仓库的变体。数据仓库存储了跨越整个组织、周期较长的数据报告与分析。多个数据集市大致相当于数据仓库，通常服务于分公司的各自IT环境中。可以将多个数据集市并入一个数据仓库，也可以是松耦合的数据集市。
整合是数据湖泊实施的关键
完全整合数据湖泊与企业的其他数据架构十分重要，包括数据治理与主数据管理。了解哪些数据类型对数据仓库或数据集市重要，或者那些原始表单中的数据是正确与一致的。实施数据治理实践，避免分析有缺陷的数据。
数据湖泊要看长远
数据湖泊拥有潜力。但在找不到比这个更好的长期数据分析方案，无法获得更多有价值的信息之前，数据湖泊也可能只是个时髦用语。
Dixon关于时间序列与间距问题分析的数据仓库案例，只是在没有考虑“坏”数据的情况下，通过简单统计分析告诉我们一些信息。由于数据湖泊实施可能发现过去分析中隐藏的关键“指数”，任何企业都值得一试。从长远来看，还是需要实验与平衡数据湖泊与整体信息架构之间关系。
====================================分割线================================
本文转自d1net（转载）
