关于数据湖的建立

关于数据湖的建立

   

问题1：碎片化数据已经形成数据孤岛

数据小组的工作范围主要涵盖财务，供应链，业务运营三类部门。

财务要求精准的进出库数量，时间，金额。用于支持对账和结算。

    供应链要求物料和库存的周转，有一定的供应链预测需求，主要用于物控。

    业务要求看商品和客户维度的数据，用于发现异常和拓客。有爬虫需求。

    运营要求线上的用户的所有行为数据。

    微服务架构下，数据存储零散，每个库的设计的基本没有考虑到对未来数据工作的考虑。导致同一个库的数据口径不一致，不同库间更是如此。

起初数据同步方案用kettle，迭代到canal去解析binlog，然后到pymysq-replication。无数次因为数据孤岛的问题出故障。目前只能算勉强还能用。

问题2：无法在技术层面形成统一数据规范

单纯是scm的各种数据管理依然极不到位。例如物料录入规范，各种订单的业务状态缺失。测试数据的问题千奇百怪。已处理过30+种不同测试规范的测试数据。导致数据污染严重，如果引入计算模型，会造成偏差极大。亦无法要求改变业务线的数据录入规则和方式。

问题3：无法建立数据仓库，数据停滞

     数据仓库基于高度结构化的格式，存储结构化数据。是写入型设计思想的Schema模式。也就是在数据落地存储之前，必须先确认业务层面的访问/调用方式，确定schema后导入数据，这样的好处是业务和数据有良好的匹配性。但对尚未完全确定道路，业务尚处于探索阶段的企业来说，太过于笨重。例如iwo迁移到scm，其中数据基本全部损失。绝大部分数据也处于停滞状态，数据仓库会成为一个数据墓地。因为把每个来源的数据一一联调成一致口径，会付出巨大的时间和计算成本，无法快速响应业务需求。

问题4：降低沟通成本，建立一个包含全公司业务数据完整副本的存储库

     亦可要求所有业务的数据落地规范全部一致，但这样做有巨大的代价和沟通成本。结构化数据非常好处理，但对于一些单据，json，图片，xml，日志类型的半结构化或二进制类型的文件来说，缺乏一个统一管理，存储的空间。

     一旦业务逻辑发生改变，或业务出现新类型，又要重新和开发、产品沟通一次。这种紧耦合的方式只能是一个过渡性方案（现在的数据方案就是如此）

数据湖的本质上是一个面向对象的存储库，基于对象块（HDFS）或文件形式。保留任意规模所有不经处理的原始数据，不需要经过结构化处理。

核心思想在于读取式Schema设计，这种设计的理念是，认为业务存在巨大的可变性，业务对数据的需求也并没有确定，大多数业务人员目前也尚不具备数据思维。所以把这个schema过程往后延迟，这样更加灵活，所有数据都可以更快地贴合业务的需求。

这和我们公司的业务部门现状比较贴合。

既然无法预估业务需求，那索性把所有的数据保持原始状态。当业务提出一个明确需求后，我们可以通过sql、可视化工具、机器学习模型等各种方式对数据进行加工。计算中间结果和计算过程同时保存在数据湖，保证可以从最终结果对每一条数据溯源。

数据湖的架构一般采用kappa架构。

储存一般选择分布式存储S3和HDFS更为常用。