一:本文要点
1.从来自微软、IBM、亚马逊网络服务的领域专家们那里学习大数据系统
2.在大数据中，高速、大量、真实性、多样性等不同属性对应用产生的技术挑战
3.创建专用的微服务来解决特定的大数据需求
4.改变我们与数据交互的方式，进而帮助我们更高效地获取并组织信息
5.大数据系统的伸缩性、灵活性及自动恢复
二:处理大数据中的多个缩写V
“大数据”是一个令人着迷的单词。人们使用它来描述一系列现象，常使用多个以V开头的特性来描述它，首先是传统的高速(velocity)、大量(volume)、多样(variety)。之后又新增了其他的属性，例如真实性(veracity)，即数据层面的真实和准确。从本质上来说，大数据就是这些属性高标准的集合体。数据频繁地被收集起来，同时伴随着巨大的数据量，且拥有越来越多的表现形式，还需要面对用户对质量极高的预期。
构建一个完全满足这些要求的系统并不是那么有必要。相反，你需要缩小关注的目标，并思考需要构建的系统到底是要解决什么问题。例如，我们在Azure云上开发的一个平台服务，Azure流式分析，就专注于速度，由于它需要就时间操作支持流式处理，且其中涉及到复杂的事件，每个流式任务每秒最高可能需要处理1G的数据。状态的形式和存在内存中的引用数据集的容量也很大，但是它们与大规模存储或批处理系统有极大的不同。伴随着亚秒级端到端的最大延时预期和为容错而进行的内部重启功能，真实性就显得尤为重要。例如，如今输出需要满足至少一次的标准，当然最好能达到恰好一次，这样就给支持多样(variety)的输出目的地带来不小的挑战，其中多样性又是前面提到的一个V开头的属性。再来说说多样性：除了多样的数据源和数据目的地，长时间运行的流式处理任务还需要灵活处理演化的数据结构和多种数据类型。
开发由高速、大量、真实、多样等需求组合而成的技术挑战十分吸引人。然而，在此之上，这个组合需要解决特定的客户需求。由于无法达到所有属性性能上的最高要求，相比任何其他以前遇到的工程类型，大数据需要面对一个极度碎片化的受众。包含从传统的骨干分布式系统开发人员到数据开发师、数据架构师、数据科学家、分析师、再到物联网等领域开发大规模端到端解决方案的工程师，当然还涉及诸多其他人员。
想要所有性能都达到最佳表现是不可能的，在单个产品或一小组的产品中平等地满足所有受众的需求也是不可能的。例如，我们在设计Azure流式分析时将其置于高层，它具备一个公共的语言作为其主要交互接口，并可以服务广大的非分布式系统开发用户。一个高层且能够与其他服务组合(这点是任何其他平台服务必备的)的服务不应该暴露其内部的技术细节，如其中的容错技术。这就引出了至少一次或更理想的恰好一次发送、可重复及确定性的需求。这些需求不仅限于大数据，但是当它们结合大数据的各个属性时就极难解决了。
所以大数据工程的一大挑战，也是值得我们坚持不懈研究的重点，是构建更大的大数据解决方案(例如通过服务)，而无需组合各类元素来减少构建这些方案的高额成本。首先就是要确定资源管理的结构，其趋势是云，大量的容器从(虚拟)机器向进程级抽象进行转移。就算到了这个程度，在单个云上取代在多租户上匹配任务运行还面临许多挑战，当然容器集群将是你的数据湖理想的去处！在这个架构的顶层，我们需要解决一个核心的挑战，即适当地分配主要的资源使用。这些资源可能被存放在存储层级或网络中，它们会需要为负载均衡而进行大范围分布或者为了高效访问而进行阵列部署。
有了这样的结构，我们接下来需要系统地构建高度定制化的微服务，通过解决特定一组需求来联结各个”点”。正如我们之前希望定义一系列组件，想用它们来组合生成任何应用一样，我们也会希望构建一个闭包或者几乎闭包的微服务集合，并利用它们来组合成一个大数据解决方案。这不太可能实现，正如之前这样的尝试在组件上没有实现一样。
在复杂的大环境中，我们需要研究更好的方法来管理资源，用以解决需要满足的排列、一致、分布之间的矛盾。抽象化地将同质的部分划分成容器，再分配到硬件和软件及网络设备上，这远非理想的方案来切换各个应用场景。如果这划分得不够完善，就会需要深层次的安全和隐私隔离机制来获取灵活的资源分配并防止内部资源层碎片化(这是一个主要的影响资源性能的原因)，而不会受到潜在的恶意租户的影响。其中提到的碎片化常发生在你依赖于虚拟机栈隔离或硬件集群层时。
当下，所述的这些研究正在进行当中，通过构建注重于单独特性集合的平台服务，并将它们相互组合，就可以满足不同需求。然而，这些服务包含多个相互竞争的产品，导致相互间有功能的覆盖，这常常限制了互相的组合，并让构建解决方案的开发人员感到迷惑。单单在流式技术领域，我们就有大量的开源技术，例如Apache Storm和Apache Spark Streaming。同时在公有云上还有各种专用技术，Azure流式分析就属于其中之一。这样多样的选择在很长时间内会持续伴随着我们，并给系统的用户带来选择的困难。
三:改变与数据的交互方式
在大数据工程中有许多技术，但是没有适用于所有需求的技术。基于一个特定数据集重复进行调优系统和在不同的数据集或查询语句上让一个系统自行按需实时调优之间是有明显不同的。随着数据增长的容量、速度、多样性上的变化，我们的目标就不单单是处理更多数据，还要找到方法来减少得到所需的数据过程中进行的人工干涉。如ETL(抽取、转换、加载)等基于规则的方式，并不是可持续的。我们必须改变我们和数据交互的方式。
随着数据数量的增长，其中潜在的信息量也在增长。所有潜在的信息对每个人的价值是不同的，它们的价值还会随着时间而改变。有时当下不重要的数据，未来可能变得重要，同时，另一些如安全漏洞等数据，就一直很重要。我们要在正确的时间获得正确的数据。
目前，我们通过结合不同的技术来为不同的需求解决这些挑战，例如，将传统的关系型数据库和新兴的大数据技术相结合。同时，对这些系统的开发、调优、维护也变得越来越复杂，这也增加了技术层面的挑战。
在数据处理的各个阶段引入认知系统可以减少人为的干预。同时可以将数据和用户的任务及目标进行关联，还可以一起定义用户目前对数据的兴趣点或用户在系统中的上下文。
一个可以理解这些任务、目标及时间相关内容的系统可以更高效地服务用户，满足他们获得数据、信息、客观事实的日常需求。这样的系统不会为用户带来额外负担来处理无关或不重要的数据。例如，一个每天早晨都会生成的当周需要了解的生产目标变化汇总报告。其中包含了根本原因分析及各决策的实施建议，还详细包含了对各种影响的分析信息，描述每个行为所会产生的后果。
这样的系统可以让每个人理解数据，而用户自己不用成为数据科学家或IT技术人员。这简化了复杂的任务，如将结构化和非结构化的销售数据结合，并将销售数据和用户意见进行比较，并列出它们之间随时间变化的关系。
另一个任务是半自动化的数据清理，在特定的时刻对特定的数据进行一系列相关操作。这优于让IT技术人员准备大量数据，最后却可能由于用户在得到结果前变化了需求而弃用所准备的数据。另外，数据清洗不能以黑盒的形式进行，数据处理过程十分重要，这样才能让用户了解哪些步骤已经完成，其中的转换为什么以及是怎样影响到数据的。
这些观点不是要替代数据科学家的工作，而是把他们从基础操作中解放出来，让他们专注于对组织有更高价值的工作中。例如，他们可以构建更准确的模型，将气候变化的信息加入保险索赔率的计算公式中，之后大家都可以使用这个模型来进行预测。
由于可用数据的不断增长，隐私会成为这个数据分析功能的一个较大挑战。例如，攻击者可以间接改造数据，就算隐私在各个访问点被保护起来。攻击者还可以利用地理和时间数据来关联其他数据，并从中识别一些个人信息等实际信息。
社区的研究应该关注于简化数据的处理过程，使得前后关系更清晰且按需进行，而不需要IT人员介入整个过程的每个阶段。社区同时需要确定如何使得认知系统能够在一个数据的容量、速度、多样性持续增长的环境中增强各类用户的使用。重要的研究领域包括用户和数据的交互、数据处理过程、自动化、可视化、结构和非结构数据、数据操控和转换、向用户传授研究成果、以及扩展并调试再进一步扩展系统的能力。
当下，大家似乎主要关注于大数据的性能，但是使用户能快速获得信息才是使组织更高效的方式。
四:应对伸缩边界
大数据和可伸缩性是当下快速发展的数据分析市场中两个最热门也是最重要的话题。不仅我们收集数据的速度在不断加快，数据源的多样性也在不停增多。数据源现在包罗万象，从无所不在的用于创建博客、帖子、tweets、社交网络交互以及照片等内容的移动设备，到不断记录运行内容的应用和服务器日志消息，再到新兴的物联网。
大数据系统必须能够快速且弹性地伸缩，无论何时何地，甚至还可能需要跨越多个数据中心。但是可伸缩性究竟是怎么定义的呢？对一个系统而言，在增加可用资源的情况下，可以按增加的资源，成比例地提升性能，这样的系统就可以认为是可伸缩的。其中提升性能通常指能服务更多单位的工作量，同时也可能是指处理更大型的任务，例如应对数据的增长。
你可以通过向现存的服务器中增加更多资源来扩展，或者在整个系统中增加新的独立机器。但每台机器加资源是有限的，最终继续增加资源也将不会再提升系统的性能，这时你就到达了伸缩边界(scaling cliff)。这种情况在大数据系统中是不可避免的。
实现伸缩性的一个主要的挑战和避开伸缩边界的方法是高效的资源管理。你可以将你的数据分片、运用NoSQL数据库并使用MapReduce进行数据处理。但能确保高效资源管理的唯一方式是一个良好的设计。高效的设计可以为你的系统增加比添加硬件所能得到的更多的可伸缩性。这不限于任何系统的特定层级或元素，你需要在每一层都考虑资源的管理，从负载均衡到用户界面，再到控制面板，直到后端数据存储。下面介绍了一些有助于设计出高伸缩性资源管理的设计原则。
五:异步与同步
在大数据系统中，时间是最宝贵的资源，而每次将一个线程或进程进行切分又会占用有限的资源，其他进程或线程就无法使用。进行异步操作可以最小化一个服务器处理请求的时间。服务器可以将需要长时间运行的操作放入队列中，之后通过其他进程或线程池来完成它们。
有时系统的一个操作必须同步运行，例如验证一个操作的成功来确保其原子性。你需要谨慎地区分必须同步运行的系统调用和可以被写入意向日志并异步运行的调用。这个原则也可以解决大数据系统的”热点”问题，因为这使得空闲的服务器可以从意向日志中”窃取”高负载服务器上的任务。
六:应对资源竞争
所有系统都拥有有限的物理资源，对这些资源的占用是可伸缩性问题的根本原因。系统由于没有足够内存、垃圾回收、文件句柄、CPU周期或网络带宽而对操作进行限流，这也是将要到达伸缩边界的预兆。
一个设计原则是若非必要就不要使用抢占式资源，但是在一定要使用它的情况下，就尽量减少占用的时间。进程占用资源的时间越少，那么其他进程就能越快使用到这个资源。同时可以通过复查代码来确保抢占式资源在一定时间内被放回到资源池中。可以首先在负载均衡层使用快速中断SSL(安全套接层)。如果使用带有加密卡的硬件负载均衡，可以用其高效地在硬件层中断SSL，从而减少前端服务器40%的负载。快速中断SSL还能提升客户端的性能。你可以将这个原则应用到系统的各个层面。
七:逻辑分区
将系统所有的资源和行为进行逻辑分区，并最小化它们之间的耦合。将行为分区有助于减缓高成本资源的负载。一个最佳实践是将你的应用在代理或用户界面层、控制面板层和数据层间进行逻辑分区。虽然逻辑分割不强制需要进行物理上的分割，但它可以让物理分区成为可能，你可以将你的系统扩展到多台机器上。通过最小化资源及行为之间的关系，你可以减少某个关联任务由于运行缓慢而拖累整个流程的风险。
分区也有助于确认每层性能衡量的标准。一个掌控着访问请求的前端代理层最好根据每秒处理的事务进行优化，管理操作的控制面板最好根据CPU的效用进行优化，而存储层最好能优化每秒的I/O操作。这也能确保你的系统是平衡的，没有某一层表现出瓶颈或使用了过多的资源，后者可能导致资源的未充分利用或给系统其他层造成压力。
八:状态缓存
引入状态缓存集群。如果可能，不要维护状态。状态会消耗宝贵的资源并使伸缩变得复杂。然而，有时你不得不在两次调用之间或确保服务层协议时维护状态。状态不应该被一个单独的资源持有，不然这极易导致资源的征用。
一个最佳实践是在同一个逻辑层的服务器之间复制状态。当一个服务器正在被使用，且其资源被征用着，那么同一逻辑层的其他服务器可以通过使用它们缓存中的状态继续处理会话。然而，小范围点对点的协议可能无法在大范围上适用，所以可以使用一个复杂度为log N的小型专用缓存集群。每台服务器将状态持久化在一台缓存服务器上，接下来这台缓存服务器将这个状态散布到集群中的一部分仲裁服务器。这些服务器可以进一步将状态延迟传播到同一层的其他服务器上，并且这个过程式高效、可伸缩的。
九:分而治之
某种意义上，所有的大数据系统都会面临伸缩边界，而且这无法避免。唯一的办法是经时间验证的分而治之策略：将一个问题简化，将其分割成小的更易处理的步骤。正如你的大数据系统是逻辑分区的，然后可能通过微服务，使用另一个搭建的系统来达到大规模伸缩。
十:自动恢复
在构建更高级、可伸缩的大数据系统的过程中有许多尚未解决的挑战。其中之一就是确保运行的任务是可以自动恢复的。一个设计良好的大数据系统就算意外丢失一两台计算资源也可以恢复正常运行。但是一个真正地可恢复系统需要同时拥有良好的设计和服务层的支持来自动检测并替代失败或不可达的实例。当一个新的实例上线，它应该知道其在系统中的角色，自动进行配置，发现需要的依赖，开始恢复状态，并自动开始处理请求。
转载请注明来源网站:blog.ytso.com谢谢！
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/bigdata/9677.html