1.1. 解析建模

1.1.1. 实时访问可以解决批处理中的许多延迟问题

1.1.2. Apache Mahout是一个开源项目，旨在创建一个机器学习库

1.1.3. 解析模型与不同的分析深度相关联

1.1.3.1. 描述性建模以紧凑的方式汇总或表示数据结构

1.1.3.1.1. 这种方法并不总能验证因果假设或预测结果，但确实能够使用算法定义或改善变量之间的关系，从而为这种分析提供输入

1.1.3.2. 解释性建模是数据统计模型的应用，主要是验证关于理论构造的因果假设

1.1.3.2.1. 虽然它使用类似于数据挖掘和预测分析的技术，但其目的却不同

1.1.3.2.2. 它不能预测结果，只是将模型结果与现有数据相匹配

1.1.3.2.3. 预测分析的关键是通过训练模型来学习，学习方法的效果取决于它在测试集（与训练集相互独立）上的预测能力

1.1.3.2.4. 评估将指导学习算法的选择并度量所选模型的质量

1.1.3.2.5. 避免过度拟合——这种情况发生在用于训练模型的数据集不具有代表性，模型过于复杂，或者将少量噪声数据具有的特性当作大部分数据的共性时

1.1.3.2.6. 训练误差会随着模型复杂性的提高而持续降低，并且可以降至零

1.1.3.2.6.1. 它不是对测试误差的可用估量

1.1.3.2.6.2. 将数据集随机分为三个部分：训练集、测试集和校验集

1.1.3.2.6.3. 重复使用相同的测试集可能会低估真正的测试误差

1.2. 大数据建模

1.2.1. 大数据建模是一项技术挑战，对想要描述和管控数据的组织而言至关重要

1.2.2. 对数据仓库进行物理建模的主要驱动因素是为查询性能而启用数据填充

1.2.3. 应用经过验证的数据建模技术，需要同时考虑各种源，至少用概括的方式开发主题域模型，这样一来它就可与适当的上下文实体相关联，并被放入整体路线图中，就像任何其他类型的数据一样

1.2.4. 挑战在于只付出合理的代价就可以从这些大型数据集中获得可理解且有用的图景

1.2.5. 需要了解数据集之间的数据的链接方式

1.2.6. 对于不同粒度的数据，需要防止对数据元素或值进行多次计数的组合

2.1. 管理数据仓库数据的许多一般规则适用于管理大数据：确保数据源可靠、具有足够的元数据以支持数据使用、管理数据质量、确定如何整合来自不同源的数据，以及确保数据安全且受到保护

2.2. 数据速度可能会导致人们认为他们没有时间实施控制

2.2.1. 对于更大的数据集，管理摄取(ingestion)和库存数据对数据库是非常重要的，以防它成为数据沼泽

2.3. 对正用于研究的数据集来说，摄取可能并不总是需要组织的所有权或委托

2.3.1. 可以考虑租用大数据平台一段时间，以探索感兴趣的数据

2.3.2. 探索可以快速确定哪些区域具有潜在价值

2.3.3. 在提取到组织数据湖、数据存储或数据临时区域之前，执行数据探索；一旦提取，删除可能会比较困难

2.4. 战略一致性

2.4.1. 任何大数据/数据科学项目都应该与组织目标战略一致

2.4.2. 建立大数据战略可以推动与用户社区、数据安全、元数据管理、数据血缘和数据质量管理相关的活动

2.4.3. 要素

2.4.3.1. 信息生命周期

2.4.3.2. 元数据

2.4.3.3. 数据质量

2.4.3.4. 数据采集

2.4.3.5. 数据访问和安全性

2.4.3.6. 数据治理

2.4.3.7. 数据隐私

2.4.3.8. 学习和采用

2.4.3.9. 运营

2.5. 就绪评估/风险评估

2.5.1. 业务相关性

2.5.2. 业务准备情况

2.5.3. 经济可行性

2.5.4. 原型

2.5.5. 可能最具挑战性的决策将围绕数据采购、平台开发和资源配置进行

2.5.6. 数字资料存储有许多来源，并非所有来源都需要内部拥有和运营

2.5.7. 市场上有多种工具和技术，满足一般需求将是一个挑战

2.5.8. 及时保护具有专业技能的员工，并在实施过程中留住顶尖人才，可能需要考虑替代方案，包括专业服务、云采购或合作

2.5.9. 培养内部人才的时间可能会超过交付窗口的时间

2.6. 组织与文化变迁

2.6.1. 只有业务人员充分参与，才能从高级分析中获益，需要通过沟通和培训计划来影响这一点

2.6.2. 大数据平台架构师

2.6.2.1. 硬件、操作系统、文件系统和服务

2.6.3. 数据摄取架构师

2.6.3.1. 数据分析、系统记录、数据建模和数据映射

2.6.4. 元数据专家

2.6.4.1. 元数据接口、元数据架构和内容

2.6.5. 分析设计主管

2.6.5.1. 最终用户分析设计、最佳实践依靠相关工具集指导实施，以及最终用户结果集简化

2.6.6. 数据科学家

2.6.6.1. 提供基于统计和可计算性的理论知识，交付适当的工具和技术，应用到功能需求的架构和模型设计咨询

3.1. 寻源

3.1.1. 来源有哪些，什么时候接入源，什么是特定研究的最佳数据来源

3.2. 共享

3.2.1. 组织内部和外部要签订的数据共享协议和合同、条款和条件

3.3. 元数据

3.3.1. 数据在源端意味着什么，如何解释输出端的结果

3.4. 丰富

3.4.1. 是否丰富数据，如何丰富数据，以及丰富数据的好处

3.5. 访问

3.5.1. 发布什么，向谁发布，如何以及何时发布

3.6. 可视化渠道管理

3.6.1. 成功实现数据科学的方法因素，是为用户团体提供适当的可视化工具

3.7. 数据科学和可视化标准

3.7.1. 分析范例、用户团体、主题域的工具标准

3.7.2. 新数据的请求

3.7.3. 数据集流程标准

3.7.4. 采用中立的、专业的陈述过程，避免产生有偏见的结果，并确保所有要素都以公平一致的方式完成

3.7.4.1. 数据包含和排除

3.7.4.2. 模型中的假设

3.7.4.3. 结果统计有效性

3.7.4.4. 结果解释的有效性

3.7.4.5. 采用适当的方法

3.8. 数据安全

3.8.1. 拥有可靠的数据保护流程本身就是一项组织资产，应建立和监控处理和保护大数据的政策

3.8.2. 为授权人员安全地提供适当级别的数据，并根据议定的级别提供订阅数据

3.8.3. 通常，组织会创建用于访问而不侵犯隐私的信息策略

3.8.4. 为保护高度敏感的信息（如社会安全号码、信用卡号码等），将使用模糊信息的加密技术存储数据

3.8.5. 重组会衡量重建敏感数据或私人数据的能力，必须将此能力作为大数据安全实践的一部分进行管理

3.8.6. 理解元数据管理级别的结果，对于避免此类和其他潜在的安全违规行为至关重要

3.9. 元数据

3.9.1. 作为大数据计划的一部分，组织将汇集使用不同方法和标准创建的数据集

3.9.2. 元数据需要作为数据提取的一部分进行谨慎管理，否则数据湖将迅速成为数据沼泽

3.9.3. 用户社区必须具备工具，使他们能够使用元数据创建数据集的主列表，元数据特征化数据的结构、内容和质量，包括数据的来源、数据的血缘沿袭、数据的定义，以及实体和数据元素的预期用途

3.9.4. 技术元数据可以从各种大数据工具中获取，包括数据存储层、数据整合、MDM甚至源文件系统

3.9.5. 考虑实时数据、静态数据和计算性数据元素，就要明确源端的数据沿袭关系

3.10. 数据质量

3.10.1. 数据质量是与预期结果偏差的度量：差异越小，数据满足期望越好，质量就越高

3.10.2. 在大数据项目中，确定数据质量似乎非常困难，但需要努力评估质量，以便对分析充满信心

3.10.3. 大多数成熟的大数据组织，使用数据质量工具集扫描数据输入源，以了解其中包含的信息

3.10.4. 发现

3.10.4.1. 信息驻留在数据集中的位置

3.10.5. 分类

3.10.5.1. 基于标准化模式存在哪些类型的信息

3.10.6. 分析

3.10.6.1. 如何填充和构建数据

3.10.7. 映射

3.10.7.1. 可以将哪些其他数据集与这些值匹配

3.10.8. 将数据质量评估放在最后是很吸引人的

3.10.9. 代码和其他潜在的链接数据可能会因数据提供者而异

4.1. 技术使用指标

4.1.1. 许多大数据工具都提供了富有洞察力的管理员报告功能，可直接与用户社区查询的内容进行交互

4.1.2. 使用技术分析手段查找数据热点（最常访问的数据），以便管理数据分发和保持性能

4.1.3. 增长率也有助于产能规划

4.2. 加载和扫描指标

4.2.1. 加载和扫描指标定义了提取率以及与用户社区的交互

4.2.2. 在采集新数据源时，预期的加载指标会随着源被完全提取而达到峰值，然后趋于平稳

4.2.3. 应用层可能会从执行日志中提供最佳数据使用指标

4.2.4. 扫描指标应与查询处理相结合，这种处理可能发生在分析处理自身之外

4.3. 学习和故事场景

4.3.1. 为了显示价值，大数据/数据科学项目必须衡量有形成果，以证明开发解决方案和管理流程变更的成本是合理的

4.3.2. 已开发模型的数量和准确性

4.3.3. 已识别的机会中实现的收入

4.3.4. 避免已识别的威胁所降低的成本

4.3.5. 分析的结果会讲述一些故事，这些故事会导致组织重新定位、重新振兴和新的机会

4.3.6. 一个衡量标准可以是营销和高管发起新项目、新方案的数量