|
数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。 数据中台解决的问题可以总结为如下三点： 1．效率问题：为什么应用开发增加一个报表，就要十几天时间？为什么不能实时获得用户推荐清单？当业务人员对数据产生一点疑问的时候，需要花费很长的时间，结果发现是数据源的数据变了，最终影响上线时间。 2．协作问题：当业务应用开发的时候，虽然和别的项目需求大致差不多，但因为是别的项目组维护的，所以数据还是要自己再开发一遍。 3．能力问题：数据的处理和维护是一个相对独立的技术，需要相当专业的人来完成，但是很多时候，我们有一大把的应用开发人员，而数据开发人员很少。 这三类问题都会导致应用开发团队变慢。这就是中台的关键——让前台开发团队的开发速度不受后台数据开发的影响。 数据仓库、数据平台和数据中台的区别表现在以下几个方面： 1．数据中台是企业级的逻辑概念，体现企业 D2V（Data to Value）的能力，为业务提供服务的主要方式是数据 API； 2．数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表； 3．数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集； 4．数据中台距离业务更近，为业务提供速度更快的服务； 5．数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景； 6．数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。 7．数据仓库具有历史性，其中存储的数据大多是结构化数据，这些数据并非企业全量数据，而是根据需求有针对性抽取的，因此数据仓库对于业务的价值是各种各样的报表，但这些报表又无法实时产生。数据仓库报表虽然能够提供部分业务价值，但不能直接影响业务。 8．数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题，所以先撇开业务需求、把企业所有的数据都抽取出来放到一起，成为一个大的数据集，其中有结构化数据、非结构化数据等。当业务方有需求的时候，再把他们需要的若干个小数据集单独提取出来，以数据集的形式提供给数据应用。 9．数据中台是在数据仓库和数据平台的基础上，将数据生产为一个个数据 API 服务，以更高效的方式提供给业务。 数据中台需要能够为企业提供以下六个方面的能力： 1．数据资产的规划和治理。做中台之前，首先需要知道业务价值是什么，从业务角度去思考企业的数据资产是什么。数据资产不等同于数据，数据资产是唯一的，能为业务产生价值的数据。 对于同一堆数据，不同业务部门所关注的数据指标可能完全不同，怎么让各个跨域的业务变成统一的标准，就需要规划企业的数据全景图，将所有有可能用上的、所有对企业有可能有价值的数据都规划出来，最终梳理出企业的数据资产目录。在这个时候不需要考虑有没有系统、有没有数据，只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细，太细就难以形成标准，不能适用于多个场景了。数据治理是数据中台很重要的一个领域，在现在业务边界消失、需求快速变化的情况下，企业需要具备精益数据治理的能力。传统的中心化、事前控制式的数据治理方式，要改变为去中心化、事后服务式的治理方式。 2．数据资产的获取和存储。数据中台要为企业提供强大的数据资产的获取和存储的能力。 3．数据的共享和协作。企业的数据中台一定是跨域的，需要让所有的人都知道数据资产目录在哪里。不能因为数据安全，就不让大家知道企业有什么数据。没有共享和开放，数据没有办法流动起来，没有流动的话数据的价值产生的速度就会非常慢。所以在数据安全的基础上，企业的数据资产目录要对利益相关者、价值创造者开放，要让业务人员能够做到“Self-Service”。 4．业务价值的探索和分析。数据中台不仅要建立到源数据的通路，还需要提供分析数据的工具和能力，帮助业务人员去探索和发现数据的业务价值。一个好的数据中台解决方案中需要针对不同业务岗位的用户提供个性化的数据探索和分析的工具，并且在此基础上一键生成数据 API，以多样化的方式提供给前台系统。 5．数据服务的构建和治理。数据中台需要保证数据服务的性能和稳定性，以及数据质量和准确性，还需要具备强大的服务治理能力。数据中台是一个生态平台，在数据中台上面会不断生长各种数据服务，所以从一开始就构建好数据服务的治理结构是非常重要的，数据服务需要可以被记录、可被跟踪、可被审计、可被监控。 6．数据服务的度量和运营。如果数据中台最终只是做到把数据给到业务人员，那它就只是一个搬运工的角色。数据中台还需要具备度量和运营数据服务的能力，能够对中台上提供的数据服务及相关行为持续跟踪和记录，包括哪些数据服务被哪个部门用了多少次等，通过这些去度量每一个数据服务的业务价值。 数据中台建设面临的挑战包括： 1．梳理业务场景：搞清楚数据中台如何对业务产生价值。 2．建设数据中台的优先级策略：需求可能大而全，但我们不能直接建大而全的数据中台，应该根据业务重要性来排需求的优先级。 3．数据治理问题：和业务独立开的数据治理少有成功的，大的数据标准要有数据资产目录，通过数据资产目录将共有的纬度、共性的业务模型提炼出来，在此基础之上数据治理需要跟业务场景紧密结合。 数据中台是为了加快从数据到业务价值的产生速度，但是它的生产过程依然是需要时间、有很多复杂的工作要做的，所以对于数据中台的投资方和数据中台的建设方来讲，都需要对应的战略耐心： 1．对于投资方来讲，要充分认识到数据中台类项目的价值和局限性。在现在的组织结构和技术成熟度下，数据中台依旧是一个技术平台，对于业务价值的产生是一个加速的过程。但是业务对于数据的需求不会因为有了数据中台就减少，数据中台也不是哆啦A梦，不能随心所欲地变出各种业务想要的服务。这依然是一个需要统筹规划、敏捷迭代、演进建设的系统性工程，所以需要要管理好期望，有一定的战略耐心。 2．对于建设方来讲，要充分认识到数据中台建设的复杂度，不要操之过急，不要期待毕其功于一役。要从小中台做起，围绕具体有价值的业务场景去建设，尽量不脱离场景去搞周期长、大而全的纯工具平台建设。 建设数据中台的关键考量包括两方面： 1．数据中台一定要与业务价值对齐。构建数据中台，最重要的不是技术，也不是数据质量好不好，而是数据思维和数据文化。数据思维就是要建立起从数据的视角去思考问题的方式；数据文化就是要把数据和业务当成一体去看，而不是只将数据当作一个支持工具。想清楚业务对于数据的诉求是构建数据中台的第一步，哪怕暂时不能想的太细，也要去想，想不清楚就先不要做。不要在业务场景还没有明确、优先级还不清晰、价值度量体系尚未建立起来的时候，就建立大而全的数据平台，并且把所有的数据都存起来。企业都是追求投入产出比的，大而全的数据平台往往会面临尴尬的局面，一堆功能看上去很有用，应该都能用上，但是缺乏应用场景，真的有了场景，发现也不能开箱即用，还需要众多的定制化。 2．数据中台应该从小数据、小场景做起。数据中台是面向场景而非面向技术的，这种与客户的业务、企业的结构和信息化发展阶段有着紧密的相关性的业务基础架构，是很难买一个大而全的产品来一劳永逸解决的。 数据中台团队通常需要包含以下角色： 1．业务专家团队：了解业务、梳理业务场景，确定数据资产与业务场景的一一对应关系，确定业务场景的优先级，为数据中台的建设提供依据。 2．数据工程团队：建设和维护数据中台，包括 ETL、数据采集，以及数据中台性能和稳定性保证，利用中台的工具采集、存储、加工、处理数据。 3．数据分析团队：分析数据价值、探索场景，生产更多的数据服务。 4．数据治理团队：梳理数据标准、构件数据安全和隐私规范，利用开源去中心化的数据治理工具（比如 atlas、wherehows）来围绕业务场景解决数据质量和安全问题。 5．智能算法团队：为数据分析、业务探索提供智能和算法工具。 【出处】网络。
| 
发表于 2025-11-24 18:57:44
