在过去 30 年中，我们看到生成数据以满足当前业务和用户需求的设备及软件的数量呈指数级增长。用户随时随地可以用各种智能设备相互链接，并生产和消费各种类型的数据，由此触发的协作 分析 决策又源源不断地生成新的数据。
而数据格式越来越丰富多才，包含且不限于文本、流、音频、视频和元数据。 同时数据除了传统关心型数据库中的结构化、也有大量的非结构化的或聚合的半结构化数据类型。
还好云平台为海量的，多种格式，不同结构的数据存储和处理提供了全面丰富的技术支撑，可以安全地存储、转换、处理、分析和可视化各种数据格式。
猫老师说过，问题从来不是问题，使用什么样的方法来解决问题，才是我们的问题。要利用好云平台出来数据，我们需要从问自己四个问题
- 一共有那些数据类型
- 数据如何流动
- 数据处理过程是怎样的
- 如何分析数据
当然了不同行业同时叠加不同应用场景，以上四个问题的答案显然需要具体情况具体分析无穷无尽。今天在这里猫老师使用一些云端处理数据的最佳实践，展现一下套路
数据的结构化类型
数据结构类型
结构化数据是完全符合表中的行和列架构（或者关系）的组织化数据。比如SQL里面的数据，这类数据量少，但是商业价值高
非结构化数据并不符合表结构，也没有架构。指的就是文本文件，日志文件，音视频文件等等，这类数据量特别大，产生速度极快，且价值低。
半结构化数据也具有组织性且有明确的属性和值，但数据存在多样性。比如JSON XML等等典型的互联网数据，虽然也存放在某个表里，但是他们并不能存放在适用于结构化数据的关系型数据库，因为关系型数据库的ACID特性在某一个或者某几个方面不适用这些数据类型
数据的流动过程
数据流动过程
如图所示，处理数据的过程就是给非结构化数据做结构化出来，最终转成结构化数据存放在关心型数据库的过程，那么数据库是数据的最终归宿吗，显然不是，无论原始数据是什么格式形态最终都要被转到 Excel 里，由表格表姐们一顿劈里啪啦的操作最终变成 PPT 各种曲线图 饼图，当然了数据库也可以接BI系统，直接生成各种各样的 dashboard 交付给高管。这是一种数据增值的过程，其实也是一种路径依赖。对于数据这种流动，或者增值，往往企业需要构建一条管道，也就是常说的 pipeline 来沟通各个不同环节所涉及的产品，自动化地运行。
数据的处理过程：ETL 和 ELT
首先名词解释 E Extraction，数据提取，T Transformation 数据转换，L 数据加载
ETL
传统的模式，是ETL，就是加载-转换-加载，因为在之前的传统商业环境中，数据量不大，不像后续的社交网络 IoT那么多汹涌澎湃的数据浪涌，且数据分析方式单一，所以可以四平八稳的，把数据按照后续处理的需求进行转换再加载到数据库当中。
ELT
但是到了互联网年代，尤其是移动互联网，只要企业亲自处理互联网的流量，就必须使用 ELT 了，ELT 以数据的原生格式提取和加载数据。 此更改减少了将数据加载到目标系统所需的时间。在转换阶段定义数据的结构，因此可以在多个下游系统中使用源数据 简单来说就是数据先上车，如何转换格式日后再曰。
数据的分析架构：Lambda 和 KAppa
Lambda
如果所面对的业务逻辑是设计一种稳健的机器学习模型来预测即将发生的事情，那么你应该优先考虑使用 Lambda 架构，因为它拥有批处理层和速度层来确保更少的错误。
Query = λ (Complete data) = λ (live streaming data) * λ (Stored data)
举个天气预报的例子，一方面我们有100多年来的气象脱机资料帮我们算某一日的降水概览，同时还要叠加气象卫星 各个地面气象站的实时信息才能实现较为精准的预报。
Kappa
如果所面对的业务逻辑是希望实时性比较高，而且客户端又是根据运行时发生的实时事件来做出回应的，那么就应该优先考虑使用 Kappa 架构。
Query = K (New Data) = K (Live streaming data)
这方面的例子就是防电信欺诈，预先使用机器学习对电信欺诈的特征固化成模型，在交易当中发现异常的转账操作立即进行关于，这必须要在毫秒级做出判断来不及再去比对历史积累，必须要快。
这就是个人总结的基于云平台进行数据处理和分析的一些基本套路，后续猫老师还会顺着这个思路介绍相关产品和机器学习 人工智能方面的一些业界进展和最佳实践，谢谢大家！
