1700432628
驾驭大数据 [:1700430586]
1700432629
5.1.7 系统负载管理和容量规划
1700432630
1700432631
当分析专家开始使用沙箱时，有很多内置的数据库组件帮助这项工作更顺利地进行。沙箱用户可以被分配到不同的用户组里，不同组可以拥有不同的系统权限来开发使用新的高级分析。例如，你可以限制在同一时间某一个沙箱用户能使用多少CPU资源。企业级系统拥有足够的灵活性来控制这一点。当某个用户提出资源要求时，也许系统只会提供10％的资源，到了半夜，如果没有其他活跃用户了，那么这名用户就可以获得100％的系统资源。
1700432632
1700432633
控制并发查询量，或者限制客户创建某些类型的查询，这都是完全可行的。例如，对某个用户来说，他只能同时提交5项查询任务。此外，系统还拥有一些工具来发现并终止执行那些效率很低的大型查询，如两张大表的交叉关联等。
1700432634
1700432635
另一件很重要的事情是通过数据存储策略来限制用户使用的数据存储空间。当分析沙箱中的某一个数据集已经几个月没有被查询过时，那么默认选项就是把这个数据集删除。沙箱不应该像传统环境那样不断地生成新的数据。
1700432636
1700432637
我曾经见过这种场景，企业总共拥有5TB数据，但分析环境里的数据达到了30TB～50TB。原因是每一个分析专家都会建立自己的一份备份数据，包含企业5TB数据中的大部分信息。分析专家甚至在不同的项目里建立了不同的备份数据。这带来了数据的大量重复与冗余。这种情况不应该在分析沙箱中出现。在分析沙箱里，除非有为特定目的保留数据的要求，否则数据都会被删除。
1700432638
1700432639
对于内部分析沙箱，当进行了越来越多的分析，沙箱和生产环境之间的资源分配与系统负载会发生变化，这是可以接受的。如果沙箱环境部署在独立的平台上，那些导致系统资源溢出的分析任务就可以被发现并承担相应的责任。容量规划需要在开始的时候进行讨论，但是分析沙箱的容量规划与其他系统一样，并没有什么特别。分析沙箱会给系统带来新的任务，而系统管理员们知道如何来管理这些任务。
1700432640
1700432641
颠覆你的常识！
1700432642
1700432643
分析沙箱可以在不增加投资的情况下，从现有的投资中获得额外的收益。建设沙箱并不一定就要购买新设备。沙箱也不一定会给其他工作任务带来麻烦。它能从现有的IT投资中获得更多的价值，而且可以没有任何负面影响！一旦你理解了分析沙箱，明白了它的工作原理，你就会发现，许多人都信以为真的事情，而事实却刚好相反！
1700432644
1700432645
对于沙箱还有一个常见的误解。人们常常认为，分析沙箱将“摧毁”系统，把现有系统的资源全部耗光，给系统带来一系列的破坏。这完全是错误的！事实上，大型分析任务通常只是在项目初期执行1次或2次，这些任务也不会重复性地执行。你可以轻易把这些大型任务调度到半夜执行，而半夜的系统资源通常很充足。仅仅因为分析沙箱偶尔可能耗光系统资源而反对使用沙箱，并把沙箱推向绝境，这往往会带来相反的效果。沙箱中的分析完全可以只使用那些闲置的系统资源。这意味着不增加任何成本就能从现有IT投资中获得更大的回报！这是一件多么美好的事情啊！
1700432646
1700432647
最后的一个观点是，在包含沙箱的环境中增加分析内容，系统容量并不一定要随之扩大。如果一个系统今天的使用率是95％或99％，那么在这个系统上增加分析沙箱，确实需要进行升级扩容，但这并不是分析沙箱造成的。事实上，这个系统的负载已经如此繁重，添加任何新应用和功能都不得不进行扩容。如果使用已有的旧设备来构建外部沙箱，不仅没有新增任何成本，还可以从这些被丢弃的无价值设备中获得新的价值。
1700432648
1700432649
驾驭大数据 [:1700430587]
1700432650
5.2 什么是分析数据集
1700432651
1700432652
分析数据集（Analytic Data Set，ADS）是为了支持某个分析或模型而汇集在一起的数据，且它的数据格式满足特定分析的要求。ADS可以通过数据的转换、聚合、合并等过程生成。它通常会按照一个逆规范化或者扁平文件的结构来设计。这种结构下，每一行数据都描述了一个分析实体，如客户、地域或产品。分析数据集有益于缓解数据的高效存储和方便使用间的矛盾。
1700432653
1700432654
关系型数据库的大部分数据都使用“第三范式”的模式进行存储。这种模式避免了数据冗余，同时使得数据查询更复杂。第三范式的表结构非常适合保存或恢复数据，但是这些表通常很难直接用于高级分析。对第三范式的深入解读不在本书范围中。重点是，分析工具通常要求数据是简单的、非规格化的、扁平文件的格式。高级分析的复杂精细体现在分析中数据所用的算法和方法上，而不是数据结构本身。这些数据集可以有多种形式，我们随后会进行讨论。
1700432655
1700432656
驾驭大数据 [:1700430588]
1700432657
5.2.1 两种分析数据集
1700432658
1700432659
目前主要有两种分析数据集，如图5-5所示。
1700432660
1700432661
1700432662
1700432663
1700432664
图5-5 开发分析数据集与生产分析数据集
1700432665
1700432666
开发分析数据集是支持分析任务的ADS。它拥有解决问题可能需要的全部变量，所以它会非常宽。开发分析数据集可能会拥有几百个甚至上千个的变量和指标。不过开发分析数据集通常比较浅，数据行不多，因为大部分的分析都会使用抽样数据，而不是全量数据。这使得开发分析数据集很宽，但不会很深。
1700432667
1700432668
生产分析数据集刚好相反。它通常用于各种评分与模型部署。它只包含最终解决方案必需的特定数据。通常，大部分解决方案只会使用开发分析数据集中的部分变量。最大的区别在于，评分过程一定是针对所有实体进行的，而不会只针对样本数据。每一个客户、每一个地域、每一个产品都必须得到评分。所以生产数据集不宽，但一定会很深。
1700432669
1700432670
例如，在开发一个客户模型时，分析专家可能要研究500个不同的属性，分析的是从整体客户中抽取的10万个客户。因此，开发分析数据集很宽但比较浅。在生产过程中对客户应用评分模型时，可能只需要使用其中12个属性，但需要对全部3000万个客户进行计算。所以，生产分析数据集很窄但比较深。
1700432671
1700432672
驾驭大数据 [:1700430589]
1700432673
5.2.2 传统的分析数据集
1700432674
1700432675
在一个传统环境下，所有的分析数据都在数据库外部创建，如图5-6所示。每一个分析专家都会独立地创建自己的分析数据集。更糟糕的是，这些工作是由每一个分析专家独立完成的，这意味着可能会有几百个人同时在创建不同的企业数据视图。更糟糕的事情是，一个ADS通常只服务于一个项目，每个分析专家都拥有一份生产数据的独立副本。更严重的问题是，分析专家还会创建新的数据集，导致每个项目最终都会产生大量的数据。
1700432676
1700432677
