写在前面

数据已经成为企业和团体的核心资产，这些年来，数据世界充斥着新技术、方法和工具来处理不断增长的数据量以及复杂的数据结构，企业和团队基于此来提高商业竞争优势。

但是不管用什么样的大数据处理工具，采用合理的处理逻辑才是最重要的。

现代数据的复杂性

结构化数据和非结构化数据

最为常见的就是：结构化数据，一般都以二维表格的形式出现，MySQL、PostgreSQL等都是代表，数据的列和列的属性都被清晰定义。

还有诸如JSON，XML等形式的半结构化数据，以及视频、音频、文档数据、log记录等等，都需要在数据处理的时候考虑到。

实时、离线以及各种准实时数据

• 实时数据、流数据：实时数据，一般以事件驱动的为主，一旦对应的事件发生，数据流就会立即流动。例如，线上零售价格调整，广告的线上竞标，IoT实时数据展示等等。
• 离线批处理：这个操作是大数据处理的常规操作，是以预先确定的时间间隔处理累计数据的方法。
• 准实时处理：这个术语比较模糊，通常是以低延迟为基础的批数据处理来达成特定的商业BI场景或者组织要求，主要也是平衡研发投入成本的考量。一般的，有一个小时更新的场景，也有几个小时更新的场景，或者缩短到几分钟的间隔。

数据大小

并不是所有的数据需要按照大数据处理的方式进行的，如果你面对的数据量只有不到百万行量级，完全不用考虑大数据处理引擎，一个MySQL完全可以搞定。

一般的，我们所谓的大数据，是指收集的数据量大于用于数据库的磁盘容量，以至于无法存储数据分析所必须的数据量。

数据仓库和数据湖

数据仓库

数据仓库（DWH Data Warehouse）本质上还是数据库。有很多类型和品牌的数据库都可以作为数据仓库，诸如AWS的Redshift，阿里云的RDS，Azure的SQLServer、还有MySQL、Postgres等等。

数据仓库本质上是一个中心数据库，它从其他数据源，业务系统中获取数据。通过中心化的管理，进行数据分析以及洞察不同系统中数据的联系以及规律。

一般而言，数据仓库还是需要存储最新数据和历史数据的，用于生成数据分析报告，或者导入BI工具，赋能企业和团体内的数据用户。

数据湖

数据湖的概念是近几年由Pentaho的CTO James Dixon提出来的。本质上，数据库是一个巨大的数据存储，存储最原始的数据（不带任何处理的）或者只进行轻微处理的数据，在存储过程中保持数据原有的格式。

数据湖存储数据一般采用扁平式结构，一般以数据文件的形式。在“湖”中的数据都会关联一个唯一ID并为其标记元数据。常见的数据湖有AWS的S3，阿里云的数据湖PaaS，Azure的CosmosDB、OSS、HDFS等等都可以用来构建企业自己的数据湖。

数据湖一般不需要特别的规划和安排，它可能都没有schema或者ETL处理。通过数据湖存储数据可以大规模的削减数据存储成本（不管是本地搭建还是云端构建）。

由于数据湖中的数据包含了非常多的数据种类和数据结构，大量的数据，所以查询它们是个很难的任务。一般传统的数据BI都没有很好的支持数据湖，通常需要一定的数据处理代码才能实现数据洞察和构建数据报告。

最好的方式就是数据湖中的数据通过数据处理（ETL）过程，将处理后的数据存储回数据湖中或者存储进数据仓库中，以实现数据分析和数据洞察。

数据处理（ETL V.S. ELT）

近些年来，数据处理ETL（Extract、Transform、Load）并不能代表数据处理的全部了，还出现了ELT（Extract、Load、Transform），虽然只是三个单词顺序的转换，应用的场景完全不一样。

ETL（Extract、Transform、Load）

• 一般来说，ETL都会伴随着连续的，持续处理的，经过良好定义的工作流（workflow）；
• 在过程中，最开始从一个或者多个数据源中抽取数据，然后清洗数据，构建数据模型（扩充数据字段、改变数据结构），最终将数据存储进数据仓库中。

ELT（Extract、Load、Transform）

• ELT是ETL的变体，被抽取的数据首先会被存储到一个目标系统中；
• 转换的过程（Transform）会在数据在数据仓库中存储完成后进行；
• 目标存储系统需要功能强大，而且效率高，最终的数据结果能够支撑数据分析。

基于场景选择合适的技术方案

什么时候应该用数据湖？

数据需要马上收集起来，还没有时间计划或者安排去处理数据的情况，可以将数据倾倒入数据湖。

• 数据源和数据格式是高度动态变化的；
• 处于成本考虑，数据量太大不能存储于单一数据库中；
• 还不太清晰如何分析性查询，数据变化频率高的情况；
• 数据专家需要一个playground去寻找和开发新的数据洞察；
• 组织内的数据分析人员都需要对数据进行处理和分析。

以上的情况可以考虑数据湖的方式存储数据，可以选择HDFS（Hadoop Distributed File System）、Hbase、Kudu、文件存储（例如OSS），或者各大云厂商的数据湖PaaS。

什么时候可以选用数据仓库？

• 数据源是相对稳定不变的；
• 已经很清楚需要进行何种数据查询；
• 数据模型已经构建并且已经应用于企业场景中；
• 非常高的精确度的要求，例如财务数据；
• 需要严密的数据访问控制以及更高的数据安全等级。

以上的情况就是选用数据仓库的场景。我们熟知的数据库都可以用作数据仓库，MySQL、Postgres、SQLserver、Oracle、Doris，还有各种商用数据库和云厂商的数据库产品。

实时OR离线？

数据需要实时反应给予企业机型决策，在这种场景下，我们需要将离线数据处理转变为实时数据流处理。一般可以通过Flink CDC、Spark Streaming、AWS的Kinesis Firehose等等进行实时数据处理并以规定的格式存储进数据仓库或者数据湖中。

主要开始看是什么场景，以及需要投入的研发费用考虑，越实时当然成本越高。

结构化数据OR非结构化数据？

结构化数据被需要，一般都是由于一下原因：

• 可靠性：数据需要被信任。基于此，我们首先需要了解数据结构，构建数据模型的过程就是定义数据应该表现为什么样子，让数据能够让人理解；
• 成本：结构化的数据一般只会存储需要的部分。以网站的URL为例，完整的原始URL不是必要的，一般都会被打散为域名、页面路径、应用参数。这些参数还可以被进一步打标签并且编号。对于大数据量而言，存储数字要比存储字符串更节省成本。
• 建模：结构化的数据对于在业务问题与数据操作之间加起桥梁。没有结构化的数据，数据产品或者数据分析报告的盲点要么被隐藏，要么会太晚才能被发现。

不管是用什么技术（数据仓库、数据湖）进行数据处理，数据转换（T，Transform）的过程才是整个数据处理过程的中枢，能让数据有意义，并易于数据分析。

如何应对频繁变化的数据？

一些应用场景下，由于数据的高波动性，数据很难被结构化。例如，实时监控的IoT数据、舆情数据、广告数据，还没有成型的系统的数据等等。

对于以上场景，建议使用动态转换的数据湖解决方案。然而，在大多数情况下，包括上面描述的情况，仍然有一些核心业务问题可以定义并建模为结构化数据。所以，在应用数据湖方案的同事，一定要注意抽离已经形成的数据模型到效率更好的数据仓库中用于进一步的数据分析。

一些数据湖和数据仓库的思考：

• 数据湖对所有数据处理方式以及数据解释方式保持开放；数据仓库只提供了数据的单一版本；
• 尽管提取非结构化数据的价值非常难（视频、音频、图像），数据湖还是会存储它们，数据湖存储的数据类型和维度更为广泛；数据仓库只会存储结构化数据和已经建模好了的数据，以备后续的数据分析，数据展示使用；
• 数据湖很容易就能成为企业和团队的数据底座；数据仓库有时很僵化而不能处理时序变化的数据。

基于此，一个整体的数据方案如下

数据方案架构

总结

• 数据工具、技术以及架构的采用一定要根据当前的应用场景，舍弃场景单独谈技术都是闭门造车；
• ETL/ELT，关键的步骤是T（Transform）数据转换的过程，要根据实际的应用场景确定该进行T的步骤；
• 数据处理最重要的是数据思维，单纯拼大数据技术没有任何意义，赋能业务才是最终目标。

推荐阅读：

• 数字化产品，你做对了吗？
• 数字化项目的架构决策
• “碳中和，碳达峰”，一个数字化的赚钱生意

更多数字化原创好文，请关注微信公众号“汇智研习院”