资讯详情

数据中台建设

1、数据中台概念明晰

讲数据中台之前需先把相关概念明晰下，现市面上有很多数据相关的说法，如数据治理、数据湖、数据仓库/BI可视化、大数据、数据中台等，看到很多厂商是混淆到一起了，泛泛地去讲一些可提升数据质量和分析处理能力方面内容，类似价值其实并不需要数据中台，BI数据仓库等原本定位就是做这些事的，只是很多企业没做好，或者早些年大数据处理技术没达到，但硬跟风说成是数据中台不合适。

作者理解的数据中台一定还是业务导向的，且必须基于业务中台为基础，在业务中台没建好之前提数据中台的，都不是严格意义上的数据中台，所谓“中台”，还是应紧密围绕着“中台”的业务目标，如果只是因为技术层面升级了一些内容就改名叫中台，那不如叫“大数据分析平台”或“数据智能平台”等更为合适。

2、数据中台渊源及特征

为什么会有数据中台的概念出现，理论上如果系统性能足够强大，完全可以把数据中台的能力和业务中台做到一起（放到同一个项目工程中），业务中台也有数据库，也可以做数据分析，直接在业务中台里增强报表中心的处理能力及把所有数据处理相关功能放到DAL层或封装成数据服务，这样用户一套系统搞定，还不需要用两套系统反而麻烦。

正是因为业务中台“全渠道、多触点、大一统、智能化”的建设要求，决定了很大可能对于有一定体量的企业，当业务中台建设完善后会面临着大数据量级的管理，这些数据包含了企业自身相对刚性的交易相关数据，也包含外部客户相关的行为数据或更丰富的基础数据，以及沉淀多年的历史数据等，数据的量级可能是千万级甚至更多，传统的关系型数据库技术在某些场景下会变得难以支持，故而才把一些分析类及智能处理类的能力切分出来，借助数据中台的建设来实现支撑。

总结下数据中台的几个核心特征：

1）数据中台应以业务中台为基础，作为业务中台在数据处理分析方面能力的增强；

2）数据中台主要的能力由数据服务、大数据管理分析及报表展现等构成；

3）数据中台强调实时/准实时的数据处理分析，强调将分析处理结果（准）实时传回给业务中台对其进行赋能，实现数据智能。

3、数据中台建设注意点

为何没花太多篇幅讲来数据中台，是因为以作者过往服务大量传统企业的经验，哪怕是一些头部企业，其实在数据方面的能力还远远达不到智能，离数据中台或数据智能的目标较远，故更建议是先扎扎实实做好业务中台。

过往存在企业高层领导抱怨想看到数据但没有，想看到报表看不到，一些号称做数据治理的公司取巧想跳过业务和应用，就数据治理数据，殊不知一是我们说数据的“收管用”，很多企业往往是在数据“收”的环节就已经有问题，数据质量（完整性、准确性等）都不高，比如在填数据的时候没有准确性验证，客户名称、手机号码、邮箱等很多信息是错的，甚至很多数据还缺失或没有系统管，靠excel表格在人工填，所谓“垃圾进，垃圾出”，数据质量本身都还有大把问题，后面的治理和分析期望能产出什么有价值的洞察；二是就数据论数据，理论上可以，实际落地时如果数据不和业务、不和系统界面及功能联系在一起，孤立的分析将是一件极为枯燥且对人员要求极高的事，这意味着相应人员对相关业务要超级熟悉，能直接仅通过数据洞察其包含的业务含义，属于理论上可能能行实际落地挑战极大要求极高的活。

基于此，作者建议相对容易的其实还是先扎扎实实地构建业务中台，首先通过业务中台，系统化业务流程，统一全渠道数据口径及标准，让所有相关业务先跑在系统上了，方可以更好地确保数据质量，有了数据质量之后，再去谈数据处理分析，再去针对性地就一些业务要点或痛点构建数据中台能力，稳扎稳打，在落地的过程中持续完善双中台能力，进而增强数据智能能力，而非站在一个很高的层面提一堆理念，在很高的层面感觉好似做到了逻辑闭环，然后一落地发现根本落不了。

中台相关常见核心问题答疑

1. 供应链能力要不要放到中台？

基于前文对中台价值的阐述，围绕几个关键特征及价值点：如全渠道多触点、统一指挥中心、三高等，一般认为供应链相关能力（如生产、仓储、物流、研发等）不放到中台，或者说不放到全渠道业务中台，用传统各领域的相应软件（如ERP、MES、WMS、SRM等）即可支撑；还有一个比较重要的原因是销售订单转换为生产订单以及生产订单转换为物料采购订单的过程（MRP）业务逻辑往往较为复杂，而此部分功能属于传统ERP的核心功能范畴，没有必要再来重做一遍。故在整个IT架构的规划中更建议的是不将供应链相关业务域归到中台。

2.中台是不是一定要微服务？

中台不是必须要微服务，中台非前端业务系统，并不直接让终端客户使用，系统用户几乎都是企业内部人员人数不会太多，从数据并发来讲可以采用MQ等技术方式排队处理削峰平谷，减轻前端数据传输压力，所以中台系统的性能挑战更多在于企业本身的数据量级及业务复杂程度，如果量级不是特别大，且没有特别复杂的业务逻辑算法，单体应用一样可以支持；同时，据过往实际项目经验，如果仅从技术架构层面来看，微服务架构的优势毋庸置疑，但如果结合成本考虑，要是没有20人以上研发团队持续投入，建议选择微服务要慎重，因为系统架构复杂度所带来的人力资源需求会高很多。

3. 微服务能力复用本质？

所谓的微服务的复用有点像个“伪命题”，因为面向对象设计思想，或者再说大一些软件工程的设计思想，其核心就是为了复用，以往的程序设计里类和方法的复用亦是类似的道理，复用这种思想一直都存在，并不是微服务出现了才有，而微服务多的无非是封装成了API接口，可以跨平台跨语言进行调用而已。作者认为复用的本质更重要的并不是技术，而是对业务能力的高水平抽象及微服务体系的良好治理，最好是要有人能同时精通业务和技术，才可能真正做好微服务的复用。

4. 如何进行微服务拆分？

微服务拆分会有一些方向的参考，但并没有绝对的标准，总体来说建议由粗到细，一开始结合过往经验把一些核心的能力先拆解出来，更注重的是整体服务治理架构的良构，遵循由粗到细的原则，即用到存在共享的更细的微服务才拆分出来放到通用层，微服务的拆分是个逐步迭代的过程，切勿想一次到位，敏捷迭代才是正确方向。

5. Devops与ITIL的关系？

Devops和ITIL并不冲突，在Devops体系下同样需要交维，只是交维的频率也是敏捷交维，Devops还是偏技术开发、测试、运维，而ITIL更多还是偏管理运维，两者应充分结合，为企业提供比传统更强的IT运维服务体系。