驱动企业转变到数据化管理不得不知道的事（二）
关键词：数据化管理、大数据、高性能计算、人工智能、数据分析
在上一文中驱动企业转变到数据化管理不得不知道的事（一），我们讲到了如何通过数据驱动业务发展，数据多，就一定能推驱动业务发展吗？有了数据分析团队，就一定能找出问题来吗？数据驱动业务的数据化管理误区。
在本文中，我们还是围绕数据驱动业务发展为主题，重点聊一下数据化管理的思路。
如何通过数据驱动业务发展
二、数据化管理的思路
如何科学地进行数据化管理？科学的数据化管理不仅要有完备的数据分析，更重要的是基于数据分析结果的行动。
数据采集是基础，在不同的领域不同的行业有不同的数据需求，比如，在电商和互联网行业，采集的维度就包括基础数据统计、用户属性、用户来源、用户行为和模型数据等等，在IT运维行业，采集的数据包括基础设施数据、环境数据、性能数据、业务软件和中间件的数据、流程数据、日志数据、事件数据等等，在房地产行业则需要采集的数据包括土地储备、房型、人群、购买力、热销数据、来源数据、销量等等。
采集的数据繁多、来源也众多、存储的数据库和数据结构也不同、还有与之相关的文本文件、来源于不同业务系统的数据等等。采集的数据由于标准和规范不同，造成后续分析的困难和重复的工作量巨大。如果不能很好的处理和规范这些不同来源、不同架构的数据，最后采集的数据只是脏数据，对于后期分析没有任何意义。
对于多级多地域的数据采集更是如此，如果涉及到物联网的传感器网的行业，则这部分工作的规划和统一则显的更为重要。这时候边缘计算能力的规划是解决问题的很好的方式。
要知道，数据本身没有价值，数据分析才真正有价值。在做数据分析时，主要包括以下几方面内容：多维分析、对象群体分析、交易分析等等。在做数据分析时，数据建模和多维分析是很好的分析手段。我们可以看到数据的整体趋势、能发现业务发展是否有问题或者机会、能发现问题到底出在哪里、机会在哪里。在现代运维领域，我们通过大数据下的AIops就能最终定位问题出在哪里，找到业务的规划和机会，发现驱动业务的真正因子等等。可以帮助企业分析不同业务的属性特征以及行为特征。针对不同的业务，制定差异化运营策略，将运营效果最大化。
在数据分析的结果之上，我们看到问题或者机会，进一步打通数据分析和行动断层的关键是制定行动策略。拿金融领域的网点规划来说，过去是靠拍脑袋的方式进行的，根据人流数据和附近的单位或住宅人口的数据来确定在哪里设置ATM机，在哪里设置分理处、在哪里设置支行等等，但是，这样的后果，经常是不恰当的，有时甚至是严重出错的。但是，在把IT的流量数据进行解析后，我们可以清楚的知道，所有交易流量的全景图，这样我们可以清楚的知道交易类型、交易热点、交易频次等等重要数据，根据这些数据我们可以非常精准的重新规划网店的建设。
策略制定好之后，就是快速执行了。行动是验证数据分析结果和策略有效性的最后一步，优良的执行力非常重要。执行的结果的快速反馈，在这个时候非常的重要，无论是小步快跑，快速迭代，还是大变大动，都需要快速的反馈。出错没问题，但要保证速度。这时候要设计好信息的抓取和比对，从大量的数据中迅速的获取行动策略的正确与否。
从以上的介绍和分析可以看到，在整个数据化管理的过程当中，数据的采集、处理、分析自始至终都起到了非常重要的作用。但现实的很多数据平台，其计算能力是有限的，而且如果数据源发生变化或者需要展现的指标（综合分析指标）发生变化时，他们的处理速度是十分慢的，有时还需要专门的定制化工作。
但是，很遗憾，很多的业务部门以为这仅仅是一个数据展现层的工作，只是在报表层面去下功夫，结果往往不能令人满意！
这种问题十分可能是一个综合性的计算问题，可能设计数据的采集、ETL、处理、存储、优化、展现等各个环节。要根据具体的问题具体分析。
所以，建立数据计算的长期机制十分重要，必须要做到：
1、 报表开发要彻底工具化。完美解决报表没完没了的问题。
2、 数据计算层也要工具化，降低对开发人员的要求。
3、 不必做复杂的环境配置（数据源等），也可以编写简单的代码来实现复杂计算。
4、 对于多样性数据源，比如Excel、文本文件等，也必须支持简单脚本计算。
5、 报表模块要彻底独立化。报表需求变更和新增的时候，仅仅修改报表模块就可以了，不会影响应用系统其他部分。
6、 数据计算层也要完全和应用系统解耦合，实现独立计算和独立维护。
“销盟”专家经过与来自政府、金融、运营商和大型企业的众多的用户的调研沟通，以及与许多的ISV和集成商沟通后认为：解决这些难点的方案可以采用润乾的“离散数据模型的独立计算引擎”来完成，下图是其中一个可以完美解决报表开发过程的彻底工具化和报表模块的彻底独立化，建立长期应对机制，完美解决报表没完没了的难题的方案结构图。
对于数据计算的问题，由于：
1、互联网时代数据形式的种类更多。
2、传统手段要将这些数据转存到一个大数据库中再进行计算，加大数据库负担，多一道IO操作影响性能，实时性也不好，一般只能定时转储。
因而，独立的计算引擎，则可以直接获取这些数据进行混合计算。不需要入库出库，性能更好，也可以临时获取数据计算，实时性更好。
下图给出了这一解决方案的架构图供参考。
“销盟”在2017年帮助众多的企业在IT基础设施运维、流程、业务性能管理、用户行为管理等领域建立了合作共享的基础，在实际的工作中，我们发现，围绕着大数据下的AIops和NPM等切实的可以得到用户的认可，但数据的处理金和计算是一个现实的问题，在帮助大家解决这些问题的过程中，我们也融合了计算、AI等领域，帮助很多的客户和集成商解决了大量的问题。下图是一个较为完整的架构图。
三、搭建数据运营体系的0到1
我们拿政府大数据平台建设的案例来举例：
典型的政府大数据平台建设中存在下图所示的五个问题：平台建设周期长、异构数据源处理困难、业务场景复杂、运算的效率低、接口也不统一……,这些问题给数据化运营带来不少的困惑，甚至有些大数据平台建设完毕就束之高阁！
平台建设周期长：大多数这类平台会采用Hadoop平台，但是Hadoop平台组件数量繁多，过于沉重，搭建与维护周期长成本高。通常的项目实施周期时间紧，平台搭建一般要求1~2个月进行初验。
异构数据问题：政府的信息化系统非常复杂，历史悠久，数据源和数据结构也不同，典型的数据来源有Oracle、DB2、MYSQL、TXT、xls、csv、Hadoop、HDFS、HIVE、外系统数据文件、Web Service……，等等。
业务场景复杂：业务逻辑场景复杂度高，但是，Hive计算能力不足，过程式计算算法实现困难，使用MR硬编码工作量又过于繁重。这实际上使得很多的系统仍然是信息孤岛式的，共享困难。
运算效率低下：由于在Hadoop平台下，HIVE或MR运算效率低下，虽拥有良好的分布式计算能力，但在多线程计算和算法优化上还做得不够。
接口不统一：由于各业务系统缺乏统一标准接口来为前端报表查询提供实时数据输出，元数据标准化处理过程复杂，造成业务沟通成本较高。
在这样的环境下，“销盟”与众多的ISV和集成商在认真研究和反复的比对下，采用了下图所示的结构完美的解决了这些问题。
这整个建设过程中要注意以下几个环节：
指标规划：很多ISV和客户都有数据分析的需求，但是要采集和统计哪些数据，刚开始并不是特别清晰，那这块的规划就非常有必要的。尤其是在数据建设初期，一定要将指标的定义明确，不然很容易在后期数据分析阶段出现扯皮问题。
更新周期：数据是实时更新的、每天更新、还是每周更新，都需要提前规划好。因为数据计算会耗费大量的资源，好钢用在刀刃上，把资源用在最有价值的地方。
数据采集：指标规划好之后，接下来要做的就是数据采集。数据采集包含三个方面的工作，字段分类、数据埋点和数据上报。字段分类很重要，越精细越有助于后续的数据分析。
数据埋点：在自己想采集的数据部分，通过打点的方式统计业务发生数据。
业务调优和编程语言的断点设置：便于维护和追踪。
报表呈现：在数据采集上来之后，我们就需要考虑将数据以报表的形式呈现出来，以帮助分析业务的变化情况。记住，不是追求报表的漂亮，要追求报表的独立性和计算能力。
本文中提到的IT基础设施运维、流程、业务性能管理、用户行为管理、AIOPS、NPM、数据计算等，“销盟”中都有成熟的伙伴在做相关产品和实施服务，如需了解相关详细内容，可直接与联盟秘书处联系。
（未完待续）
分享是一种美德，转载请注明来源和出处！
“相关文章阅读”
从天山上来的润乾，从一阳指到六脉神剑，实现报表到计算的转身（上）
从天山上来的润乾，从一阳指到六脉神剑，实现报表到计算的转身（中）