好消息：为规范分析准备好数据没什么特别之处。坏消息：您需要做所需的事情，以便为任何类型的分析准备好数据 - 这很难。Prescriptive analytics就是自动化您的业务。当我们在指南中探讨规范分析的复杂性时，这是一线希望。虽然很多复杂性是业务线和专家数据科学家必须处理的事情，但IT也不是不合时宜的。规范分析很难，并且没有银弹可以让你在没有经历进化分析链的情况下实现目标。您必须正确地获取数据收集和存储基础架构，正确的数据建模以及状态分类和预测权限。
这是规范性分析的底线，IT必须确保数据收集和存储基础架构部件适用于业务和数据科学部门。成功使用规范分析所需的数据清理和组织可以从两个方面考虑：将用于提供分析的数据的数量和质量。
首先，IT需要确保所有与组织相关的数据都被考虑和访问。这确实是任何分析工作的必要条件，但它可能比听起来更复杂。
考虑组织可能正在使用的所有应用程序：定制，现成，现场，云，遗留。每个都可能有自己的格式，存储和API。IT需要确保它们都可访问，而不会中断应用程序的运行。甲数据湖的方法可以是在这方面是有用的。
它变得更糟。数据也可以超越应用程序。例如，考虑所有内部文档和电子邮件。通常，大量数据以非结构化格式和未记录的来源存在。许多应用程序也没有文档记录，无法访问，缺少导出数据的API。对于那些人，你必须要么足智多谋，要么快速失败。
然而，即使你成功了，这也不是一次性的练习。应用程序不断发展，并与他们一起发展他们的数据。API更改，模式更改，添加新数据。新的应用程序会被混合使用，旧的应用程序会被弃用。掌握数据收集需要不断努力，这是您在开始规范分析之旅时需要考虑的成本。向数据湖添加语义可能会有所帮助。说到成本：当然，通常的IT供应话语也适用于此。您是否提前计划，将此项目作为具有预先确定的基础设施和人员成本预算的项目，并通过组织预算审批流程实现?或者你采取更灵活，按需付费的方式?
前者在理论上更安全，更符合组织流程。问题在于：除非您的数据来源相对有限且易于理解，并且您在跟踪和配置它们方面非常彻底，否则这种方法在实践中可能是不可能的。
后者更灵活，但也可能导致预算超支和影子IT问题。如果没有某种疯狂的方法，你最终可能无法控制，并且将数据存储在各处。虽然这不是100%严格的规则，但预算编制方法在使用本地存储时更有意义，而云存储和开发非常 适合按需付费方式。
最后，数据新鲜度是需要考虑的另一个考虑因素。如果您希望您的分析能够实时反映现实世界，那么提供它的数据也应该是实时的。这意味着您应该考虑流式数据基础架构。虽然采用流媒体有好处，但它是一种新的范例，伴随着自己的学习曲线和软件/硬件/人员投资。
特色
这本电子书基于最新的ZDNet / TechRepublic特色，探讨了如何设置一个可以看到角落的分析基础设施，并为您提供避免正面崩溃的选项。
垃圾输入，垃圾输出是使用数据获取分析洞察力的黄金法则。因此，虽然获取所有数据是绝对必要的，但如果您只是将其转储到数据湖中并考虑您的工作已经完成，那么它将无济于事。这正是数据湖泊名声不好的原因 - 数据沼泽，任何人?
要了解“数据进化”主题 - 这应该是您的首要任务。数据治理，即。是的，这听起来很抽象，但它与构建管道以将数据引导到数据湖一样重要。每个数据集都应包含其谱系上的元数据(数据来自何处)，其获取日期以及访问权限和处理历史记录。
后一方面在今天的GDPR世界中变得越来越重要。当然，并非所有组织都处理用户数据，即使对于那些用户数据，也不是所有数据都与用户相关。不过，大多数组织至少都会触及一些个人数据。对于那些，GDPR规定需要适用。
那么问题就变成：什么更有效 - 分裂和征服，或者为所有数据提供GDPR准备治疗?在许多情况下，如果无论如何应用全圆数据治理的基础设施，将其应用于所有数据都是有意义的。这可能使make数据集处理成为一个不那么轻量级的过程。但是下游应用程序的元数据的好处可以很好地弥补这一点。