【无标题】

数据仓库

        通常是业务发展到一定规模后，业务分析师、CIO、决策者们，希望从大量的应用系统、业务数据中，进行关联分析，最终整点“干货”出来。

        比如为啥利润会下滑？为啥库存周转变慢了？向数据要答案，整点报告、图表出来给老板汇报，辅助经营决策。

        数据仓库相当于一个集成化数据管理的平台，从多个数据源抽取有价值的数据，在仓库内转换和流动，并提供给BI等分析工具来输出干货。

 数据湖

        数据库负责干事务处理相关的事，数据仓库负责干业务分析相关的事，还有新兴的HTAP数据库既干事务又干分析，那为什么又提出数据湖的概念？

        说白了，还是企业在持续发展，企业的数据也不断堆积，虽然“含金量”最高的数据都存在数据库和数仓里，支撑着企业的运转。

         但是，企业希望把生产经营中的所有相关数据，历史的、实时的，在线的、离线的，内部的、外部的，结构化的、非结构化的，都能完整保存下来，方便“沙中淘金”。

        挖个大坑，修个湖，把各种数据一滚脑灌进去囤起来，而且要持续灌，持续囤。这就是数据湖。

         从数据含金量来比，数据仓库里的数据价值密度更高一些，数据的抽取和Schema的设计，都有非常强的针对性，便于业务分析师迅速获取洞察结果，用与决策支持。而数据湖更有一种“兜底”的感觉，甭管当下有用没有/或者暂时没想好怎么用，先保存着、沉淀着，将来想用的时候，尽管翻牌子就是了，反正都原汁原味的留存了下来。        

 湖仓一体

为什么要把“湖”和“仓”糅到一起？ 

        数据湖起步成本很低，但随着数据体量增大，TCO成本会加速飙升，数仓则恰恰相反，前期建设开支很大。总之，一个后期成本高，一个前期成本高，对于既想修湖、又想建仓的用户来说，仿佛玩了一个金钱游戏。

        于是，人们就想，既然都是拿数据为业务服务，数据湖和数仓作为两大“数据集散地”，能不能彼此整合一下，让数据流动起来，少点重复建设呢？

        比如，让“数仓”在进行数据分析的时候，可以直接访问数据湖里的数据（Amazon Redshift Spectrum是这么干的）。再比如，让数据湖在架构设计上，就“原生”支持数仓能力（DeltaLake是这么干）

Lake House

通常称之为“湖仓一体”，Lake House架构最重要的一点，是实现“湖里”和“仓里”的数据/元数据能够无缝打通，并且“自由”流动。

         湖里的“新鲜”数据可以流到仓里，甚至可以直接被数仓使用，而仓里的“不新鲜”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

        在实际业务场景下，数据的移动和访问，不仅限于数仓和数据湖之间，搜索引擎服务、机器学习服务、大数据分析服务……，都涉及到数据在本地（本系统）和数据湖之间的移动，以及数据在不同服务之间的移动。

       数据积累得越多，移动起来就越困难，这就是所谓的“数据重力”。所以，Lake House不仅要把湖、仓打通，还要克服“数据重力”，让数据在这些服务之间按需来回移动：入湖、出湖、环湖……

 智能湖仓

        智能湖仓并非单一产品，它描述的是一种架构。这套架构，以数据湖为中心，把数据湖作为中央存储库，再围绕数据湖建立专用“数据服务环”，环上的服务包括了数仓、机器学习、大数据处理、日志分析，甚至RDS和NOSQL服务等等。

        大家“环湖而饲”，既可以直接操纵湖内数据，也可以从湖中摄取数据，还可以向湖中回注数据，同时环湖的服务彼此之间也可以轻松交换数据。

        任何热门的数据处理服务，都在湖边建好了，任何对口的数据都能召之即来、挥之则去。依靠这种无缝集成和数据移动机制，用户就能从容地用对的工具从对的数据中，挖出干货！