第4章
企业大数据自主实施思路
当前，新一代信息技术与传统企业的深度融合（互联网+），正在引发影响深远的产业变革，形成新的生产方式、产业形态、商业模式和经济增长点。各行各业都在加大科技创新力度，基于云计算、大数据、人工智能、物联网、智能设备的互联网技术正在引领制造方式变革；个性化定制、供应链优化、财务预测、营销管控、库存优化、用户全生命周期管理、智能客服、电子商务等正在重塑产业价值链体系。
当企业决定实施大数据战略时，应该如何开始？本章将围绕企业大数据在自主实施之前如何规划进行讲解，包括规划原则、目标蓝图、建设目标、组织规划、技术方案、人才规划、投入产出评估、数据风险管理几个方面。
4.1 制定规划原则
在企业级大数据应用系统设计规划过程时，为确保系统的建设成功与可持续发展，在系统的建设与技术方案设计时我们遵循如下的原则：
4.1.1 价值性
公司在做大数据规划之前需要弄清楚一些问题：到底有多少数据？数据都是什么类型？数据分布在哪些环境？数据质量到底如何？这些数据都能干什么？数据价值如何提取？很多企业中的业务部门想针对一些数据进行分析时，却不知道能拿到什么数据，这直接导致了无法准确描述数据价值预期的问题。所以企业开始设计大数据系统实施方案之前，应首先由数据部门牵头，对企业现有业务系统的数据情况进行全方位的梳理，了解各系统的运行情况和各系统之间的关系，完善各个系统的数据字典，并结合数据字典对原有系统中的数据质量进行评估，形成系统数据质量提升方案。
对数据价值性的评估是建立大数据平台的前提和原始动力，如果一家企业自身业务系统数据不够完善且数据质量低，说明数据价值度也低，首先要做的工作是完善业务系统数据规范，提升数据质量，这样才能在大数据系统实施后真正做到数据价值最大化。
4.1.2 实时性
在传统的数据挖掘统计中，不管是数据标签还是数据模型，一般都是通过数据库或传统建模工具定时执行生成的，这种处理方式有几个弊端：
❑只有当事件发生一段时间之后，通过数据报表才能看到，数据延迟性较大；
❑发现问题时再去补救已经为时已晚，需要花费大量的时间和资源去做数据和业务的回滚；
❑在数据仓库创建的过程中，它必然要根据业务系统数据的更新而进行迭代，实现数据完整无误的增量更新，是传统数据仓库建立时最大的技术难点；
❑数据仓库在与业务系统对接后，更需要有效地保障业务系统实时读取和操作相关数据的能力。
所以，为了实现数据实时录入、海量数据实时计算、生成动态实时标签、数据实时提取投入应用等关键节点，需要在大数据平台设计时系统地解决这些问题。如果在大数据平台建设之后仍无法解决，那么大数据平台就沦为一个升级版的“传统数据仓库”，系统价值就会大打折扣。
4.1.3 高效性
当企业中的业务数据系统使用了一段时间后，通常会由于跨多平台和异构数据环境、海量数据的复杂计算、延伸业务模型的优化修正以及重复计算任务的冗余而导致大数据平台效率的低下。
另外，数据平台上线后，随着业务量的增加，原有的计算资源将面临严峻考验。如何根据计算任务的重要级别进行资源分配，使重要任务优先运行；如何解决传统ETL和数据挖掘模型少则几个小时，多则几天的运行效率；如何协调开发和调试阶段资源的分配都是需要解决的问题。
以上问题都是对大数据平台高效性的考验，如何最大程度保障平台执行效率、数据高效的整合能力、数据模型的计算能力、资源分配能力等，都是在平台设计和实施时必须要考虑到的。
4.1.4 安全性
大数据平台安全是由系统类、功能类、数据类、资源类四个层面组成的。一般情况下，系统类、功能类、数据类安全是业务相关的，需要具体问题具体处理。而资源类相对来说比较独立，在服务端体现为ETL、算法及服务器的运行权限，在客户端则体现为数据模型的使用权限。如何将权限分配给用户，不同的大数据集群拥有不同的授权模型，授权模型和组织机构模型有很大的关联性。考虑到企业大数据的共有特性，在整个规划中，我们需要从下面四个层次来了解大数据平台的系统安全：
（1）系统类
在客户端，系统类安全涉及访问IP段的限制、登录时间段的限制、连接数的限制、特定时间段内登录次数的限制等，为用户提供和其权限相关的用户界面，仅出现和其权限相符的菜单、操作按钮；在服务端，则对URL程序资源和业务服务类方法的调用进行访问控制，是大数据平台的第一道防护大门。
（2）功能类
功能类安全会对程序流程产生影响，例如用户在操作业务记录时，是否需要审核，上传数据文件不能超过指定大小，操作按钮可控制的功能范围等。这些安全限制已经不是对入口的限制，而是对大数据平台操作流程的限制，这在一定程度上会影响平台的运行。
（3）数据类
数据安全包括两个层次，其一是字段级数据安全，即用户可以访问大数据平台的哪些库、表、字段；其二是行级数据安全，即用户可以访问字段下的哪条数据。一般以用户所在角色或组为条件进行权限分配。
（4）资源类
从硬件和软件上对大数据平台的执行任务进行控制，用户通过客户端提交数据执行任务时，大数据平台根据用户的级别、任务的重要程度，自动为任务排序并分配CPU、内存等计算资源，以便更好地利用有限的平台计算资源发挥更大的作用，集群的容量大小直接影响到任务运行的效率。
以上四个层次的安全，按粒度从粗到细的排序是：系统类、功能类、数据类和资源类安全。
4.1.5 延展性
在大数据平台设计的过程中，为了最大限度地增强平台的价值，最大限度地吻合各业务部门的需求，充分考虑平台今后的硬件扩展、功能扩展、应用扩展、集成扩展等多层面的延伸，整个实施过程也应该始终贯彻面向数据价值，围绕平台应用，依靠业务部门，注重实效的方针。保证平台的延展性可以提高稳定性且可靠度高，满足用户需求不断发展的要求，便于应用程序的升级及扩展，减少应用系统再开发（二次开发、定制）的工作量从而降低成本。一般地，我们可以从以下几个方面考虑：
（1）组件化结构
采用全组件化结构设计，每个组件都被独立地实现，并通过标准接口联系在一起。每个功能组件在功能上独立，同时可根据用户需求灵活配置、组合，实现平滑升级扩容。功能实体可使业务和开发人员根据具体使用要求增加或减少系统应用模块。
（2）标准化接口
采用标准统一的接口设计，所有功能实体间的数据交换以及对其他模块的数据引用都通过标准接口完成，使多个组件对接时在开放性、稳定性、扩展性与集成性上有着很好的适配空间。
（3）开放的功能包
平台除了组件化结构设计与标准化接口设计以支撑开放体系结构外，为了方便用户个性应用的开发，还应该考虑封装平台及其组件所需的二次开发应用工具包，使其他技术团队对平台进行二次开发时能够更好地复用。
4.1.6 全局性
大型企业尤其是集团性企业通常具有非常多的业务群，要建立一套既能满足整体需求，又能适应各个子体的大数据系统，需要企业做好顶层设计。
顶层设计涉及大数据项目的各个方面，具体如下所示：
❑平台整体技术架构。整体设计大数据平台从底层到应用层的技术架构，包括数据源与数据接入、数据清理与提升、数据存储与检索、数据学习与挖掘、应用模型封装、服务层搭建等。
❑物理和虚拟部署架构。大型企业内部的数据环境往往涵盖物理设备与虚拟化设备，针对性的大数据部署架构也可能产生基于不同环境的对接。
❑软硬件资源评估。对大数据平台搭建涉及的需求以及开发所需要的各种资源需要整体规划，避免资源冗余和浪费。
❑整体组件和功能组成。对于大数据系统内部不同功能之间存在的技术、组件高效率复用，尽量实现功能和组件间的松耦合关系。对于外部其他系统之间的兼容性也需要纳入大数据系统设计之中，外部系统可能包括数据系统（例如报表展示系统、数据采集系统、虚拟化产品等），也可能包括业务应用系统（例如推荐系统、调度系统、库存管理系统等）。
❑平台公有云、私有云和混合云设计。对于大数据平台的实现可能包括公有云、私有云以及混合云三种场景，不同的实现场景都应该有相应的解决方案。最终的终端应用场景会在企业内部或外部，以产品化界面或功能服务或API等形式展现，因此这也意味着在设计之初需要考虑多种服务场景支持的可能性。
❑数据综合治理方案。从整体层面对数据进行全生命周期管理，包括数据标准化、元数据管理、数据安全防护、数据隐私与脱敏、数据质量评估与提升等。
❑应用整合与细分应用场景。所有的上层应用都应该在规划阶段做好，与之对应的底层或中间层的功能实现才能针对性的开发，进而可以避免需求改变导致之前的系统被整体推倒或重新设计开发架构的风险。
❑平台可维护性与升级策略。对于大数据平台建设完成之后的可维护性包括硬件可方便扩展、软件可自动化部署、不间断的升级及补丁修复、集群整体监控与界面化管理、服务的高持续性和可用性、平台高执行效率、低成本维护和升级方案等。
❑项目实施前后的培训和内部推广。对于大数据系统的实现需要企业内外部各个部门和公司的支持，因此对于内部的大数据价值、应用等方案的引导和推广非常重要。尤其是当大数据系统完成并交付之后，直接落地应用的是一线的各个部门，因此针对各个部门的整体培训、指导甚至制度约束等工作必不可少。