离线和实时大数据开发实战 笔记一

这本书也算是二刷了，推荐可以看看。对大数据整体有一定的了解。

1.OLTP(Online Transaction processing)和OLAP (Online Analytical Processing)

从命名上就可以看出轻微的区别，一个是事物型，一个是分析型。2.

2.数据建模，最近刚好在做这方面的工作。以我司为例，用的是维度建模。维度建模客观世界分为度量和上下文。度量简单的说就是一些需要聚合或者是直接可以用的数值 如订单金额、库存数量等等，维建模中称它为事实。事实由大量文本形式的上下文包围着，而且这些上下文常被直观地分割成为多个独立的逻辑块，维度建模称之为维，维描述了度量的5个W(When,Where,What,Who,Why)信息，比如什么时候下单，何种方式下单，买的什么，客户是谁等等。在星形架构中间是事实表，事实表周围的则是各个角度的维度表。

第二点则是总线体系架构。我的理解就是不同主题公用的相同维度来保障所处数据的口径一致。从图中可以看出，不同主题之间的联系就是维度。另一种就不介绍了有兴趣可以看看这部书了解一下BillInmon建模方法论。

数仓分层:以我司为例，分为lz(原业务库数据)，ods(初步合并数据)，dw(维度和事实)，rpt(报表层) 本书分层:  只是名称叫法不同，其实含义是差不多的。

3.流计算平台的选择:

技术成熟度：即该流计算框架在工业界的实际应用情况；该技术有没有在生产环境和大数据量、大集群环境下得到验证；有无现成经验和解决方案可供参考；一旦出现问题，能否快速利用别人的经验快速解决.

性能：该技术是否能够抗住现有的业务数据量，预留空间是多少，实时延迟是否能够满足现有的业务要求。比如，基于微批处理的框架延迟至少在秒级，而原生的流处理框架可以到几十毫秒。

开发难度和速度：该技术是否提供高级的API，还是必须都从底层API构业务逻辑；底层API处理灵活，但是对开发人员的技能要求比较高，而且通常耗时较长，高级API（比如流计算SQL）的开发效率非常高，而且门槛低，但某些场景下SQL无法表述，实际项目中需要综合考虑.

可维护性：具体在流计算框架下主要体现在状态管理和容错性方面，比如任务失败了、需要调优或者业务逻辑更改升级了，需要暂停和重启任务，流计算框架应该支持从上一个状态中恢复。

可靠性：流计算的可靠性主要体现在流计算框架对atleastonce和exactlyonce的支持。atleastonce意味着每条消息会进行多次传输尝试，至少一次成功，即消息传输能重复但不会丢失；exactlyonce的消息传输机制是每条消息有且只有一次，即消传输既不会丢失也不会重复。

4.数据探查

       数据探查就是对数据的内容本身和关联关系等进行分析，包括但不限于需要的数据是否存在、都有哪些字段、字段含义是否规范明确已经字段的分布和质量如何等。数据探查常用的分析技术手段包括主外键、字段类型、字段长度、null值占比、枚举值分布，最大值，最小值，平均值等。

        数据探查分为战略性的和战术性的。战略性的数据探查是指在使用数据之前首先对数据进行轻量级数据分析，确定是否可用、数据稳定性如何，以决定是否可以纳入数据平台使用。战略性的数据探查是构建数据平台前首先要进行的任务，不合格的数据源头必须尽快剔除，如果到后期才发现数据源头不合格，将和对数据平台的构建造成重大影响。战术性的数据探查则指用技术手段对数据进行详尽的分析，发现尽可能多的数据质量问题反馈给业务员或通知源头系统进行改进。

  数据探查真的很重要，如果从源数据平台来的数据大量不合格不可用会对用到此数据的所有主题造成影响。