架构之数据架构

数据平台进化

实际上世界都是围绕数据在转，只是计算机、网络的出现让数据虚拟化、可视化、持久化、通信化。以前写信，现在社交软件通信；以前各地同一样商品价格差，需要人去传播，现在各大电商平台已把此种情况规避；以前的有纸化办公，升级到现在的全面电子化办公；包括当前的AI、大数据，即将的5G、物联网等，纯软件领域、软硬结合领域，所有都离不开数据的支撑，而数据的重要不言而喻。所以构建数据平台，对数据进行集中处理，规避"数据孤岛"，让数据实际价值落地，价值最大化，也显得势在必行。以下对各层面数据平台做一次介绍。

1.传统数据架构

如图1，最简单的数据架构就是只有业务数据库，且所有业务表都在一个数据库中，或者按需分成多个数据库。没有专门的统计分析表，页面上显示的统计分析数据都是从业务数据中读取后计算出来的。一个数据库服务器承担所有增删改查操作，对逻辑删除的数据没有分化处理。

图1                                                       图2                                                                图3

数据量越来越大，历史业务数据增多，新业务数据激增，表结构越来越复杂，查询和写入频率升高，高频写和长时间读冲突越来越严重。而数据分析又要耗费大量计算资源，总不能眼睁睁看着单台数据服务器挂掉吧？引入备份数据库：

①解决了单点故障问题

②单数据库服务器性能问题

③实现简单的读写分离，分担数据库压力

④备份数据可做历史冷数据分化

图2面对简单查询还是可以的，但是在转换聚合等需要多表关联、以及大数据量等业务复杂度高的情况下，其处理性能就不容乐观了。

面图2无法解决的问题，图3这种T+n的预处理离线计算的架构就出现了，引入独立的任务调度和计算引擎：计算压力可以交给业务数据库处理，也可交给ETL处理，结果数据库中只保存已经处理好的数据，只负责读的操作，展现性能初步解决。

但这种情况还有缺点：数据库表结构实在太过复杂，每做一个分析，业务数据库就要理一次业务逻辑、写一段sql，还没法进行历史追溯，以及数据整理成果的复用。为了解决T+n计算架构的问题，才有以下的升级版的数据架构。

2.数据集市与数据仓库

把业务库数据整理成星型结构，保证了事实的积累和维度的追溯。自由选择需要的维度和相关事实进行筛选计算，再也不用担心每次写sql都要去看“蜘蛛网”了。还有索引、结果表、分区分表等等黑科技来保证每次查旬需扫描的数据量最小，解决数据库性能问题。当然这种架构方式的缺点也很明显，不是企业内一致的数据（多系统，多主题数据不一致），就会产生信息孤岛。当然，如果客户企业就是很小，就一个系统，不用整合，一个数据集市足以的情况下采用这种方式也可以。常见情况是会在各个独立的DW间建立一些对照表，可实现数据交换。如果多个DW间没有物理隔绝，也可以形成EDW。

为了实现各个业务系统取数分析，或者做更多操作，就实现中心数据仓库EDW从各个源系统收集数据，再将数据提供给各个数据集市和挖掘仓库使用。这也被称为企业信息工厂架构（CIF），一般情况下，大型企业会花费许多精力实现这类架构。

无论是以什么架构存在，数据展示的需求都必不可少。分析工具选择必不可少，要在以上阶段以一款工具涵盖，那必然需要一款既可以做敏捷数据集市建模，又可以做数据展示分析的工具来处理。这种工具可对业务数据进行简单、快速整合，实现敏捷建模节省时间，并且可以大幅度提升数据的展示速度，可对接前端的数据分析展示层，实现自由数据展示与OLAP分析，典型如各类BI分析工具。

数据分析也很考验分析工具数据读取、运算的性能，但拥有大数据量计算引擎的BI分析工具并不多。像FineBI与其高性能数据引擎在以上几个阶段均可在不同程度解决很多场景。

（1）业务数据库阶段，此阶段已经陈述过，重点问题就是计算性能影响大，以及数据孤岛问题。建立数仓的过程相对敏捷数据集市而言，时间还是久的。这个时候就看看建立个常规意义的数仓和数据展示需求谁更紧急啦，或者可能有的也没建数据平台的意识也说不准。此时快速的数据展示需求，就可以通过将数据放到FineBI的数据引擎中支撑实现。

（2）中间库与完善数仓阶段，此阶段其实主要就是计算性能问题了，用户的数据量级也一定挺大了。正好借助于FineBI的分布式引擎，完成数据加速计算工作。此引擎属hadoop生态，核心计算引擎利用的spark，借助了alluxio作为内存加速计算，处理了大数据计算问题，也很好阐释了“大数据”。这个在接下来的文章中也会说到，这里先埋个伏笔，暂不赘述。

此阶段呢，肯定有一些响应时间要求较高的展示需求，多次作业同步可能带来延迟影响。而FineBI的引擎扩展了kettle的插件，实现数据可以直接load到引擎中，倒是将麻烦的作业处理工作解决了。

4.数据湖

所谓的数据湖就是通过原始数据分类存储到不同的数据池，然后在各个数据池中将数据整合转化为容易分析的统一存储格式进行存储。这种方式极大的方便用户对数据进行分析和利用，从而产生经济效益。

数据池主要是用来存放数据的，一个数据池中主要包含这几种数据：

1、原始数据池

原始数据池是单一数据湖，它的作用就是存储大量的原始数据。不会对其进行任何处理，很难从中提取想要的数据并进行使用。

2、模拟数据池

模拟数据池专门负责存放模拟数据，它主要是由机械设备产生的数据，一般为测量的数据、温度、湿度等。一般情况下都存储在记录或者日志磁带当中。

3、应用数据池

应用数据主要是执行一个应用或者事务时产生的数据，比如销售数据、支付数据、制造过程控制数据等。这种数据池专门负责存放应用数据。

4、文本数据池

文本数据池顾名思义是负责存放文本数据的，原始数据可能是一些不同来源、形式的文本数据。比如录音、邮件，甚至是一些物理设备产生的数据。在此类数据池中，数据可以根据感情分类进行存储，在数据池中需要预先设定不同情感的类别，然后新文本进入数据池时就会根据上下文语境确定情感色彩，找到相对应的类别，进行存储。

5、文档数据池

文档数据池主要存储来自应用数据池、模拟数据池、文本数据池中将来使用较小概率的数据。

实现数据湖

数据湖实现的常用手段是Hadoop。

hadoop参照：

https://blog.csdn.net/qq_36632174/article/details/102461023

https://blog.csdn.net/qq_36632174/article/details/102461682

在经过进化之后，会将数据群与程序、运算规则、显示器和历史记录联系在一起，完成数据湖的目标。数据湖把原始数据按照类别进行存储，在各数据池中可将数据转化为统一的可直接提取的格式，这种方式具有极大的商业价值，对大数据分析做出了极大贡献。

数据湖存在问题：数据湖中很多数据永远不会删除，所需要的存储空间架构庞大。而且数据湖其中一个数据池遭到破坏，所有的数据都可能会被访问，具有较大安全隐患。
数据湖架构

解读数据湖架构：

ODS（operational data store, staging area）存储来自各业务系统（生产系统）的原始数据，即为数据湖。

CDM为经过整合、清洗的数据。其中的DWS汇总层，为面向主题的数据仓库（狭义），用于BI报表出数

简单来说，数据湖的定义就是原始数据保存区. 虽然这个概念国内谈的少，但绝大部分互联网公司都已经有了。国内一般把整个HDFS叫做数仓（广义），即存放所有数据的地方。

数据湖的意义、与数据仓库区别

数据湖和数仓，就是原始数据和数仓模型的区别。因为数仓（狭义）中的表，主要是事实表-维度表（下图），主要用于BI、出报表，和原始数据是不一样的。

为什么要强调数据湖呢？真正的原因在于，数据科学和机器学习进入主流了，需要用原始数据做分析，而数仓的维度模型则通常用于聚合。另一方面，机器学习用到的数据，也不止于结构化数据。用户的评论、图像这些非结构化数据，也都可以应用到机器学习中。

二者区别对比表：

除了以上区别外，还有以下几点区别：

传统数仓的工作方式是集中式的：业务人员给需求到数据团队，数据团队根据要求加工、开发成维度表，供业务团队通过BI报表工具查询。

数据湖是开放、自助式的（self-service）：开放数据给所有人使用，数据团队更多是提供工具、环境供各业务团队使用（不过集中式的维度表建设还是需要的），业务团队进行开发、分析。也就是组织架构和分工的差别 —— 传统企业的数据团队可能被当做IT，整天要求提数，而在新型的互联网/科技团队，数据团队负责提供简单易用的工具，业务部门直接进行数据的使用。人人具备数据分析能力。

数据湖的意义

数据湖最大的意义，在于帮团队做组织架构调整，鼓励所有人了解、分析数据，降低出数类等"IT"型工作。当然，对传统企业而言，也是引入机器学习、用户画像的必须基础设施，。

数据湖面临的挑战

从传统集中式的数仓转为开放式的数据湖，并不简单，会碰到许多问题：

1.数据发现：如何帮助用户发现数据、了解有哪些数据

2.数据安全：如果管理数据的权限和安全？因为一些数据是敏感的、或者不应直接开放给所有人的（比如电话号码、地址等）

3.数据管理：多个团队使用数据，如何共享数据成果（比如画像、特征、指标），避免重复开发

这也是目前各大互联网公司都在改进的方向，比如，对于数据发现，目前的解决方案就是Data catalog, 典型的比如IBM Watson catalog （算是对传统元数据管理的改进）. 对于机器学习方面的数据管理，可以看Airbnb的机器学习平台Bighead中的实践。