他们会说业务能力，比如业务管理、客户细分、营销能力、销售能力等等。如果你问公司的数据团队：“你们最核心的能力是什么？”

进入公司以后用过不少BI软件，brio、BO、BIEE等等，现在很热的Tableau、FineBI、Qlikview没用过，据说提供了很多自助式的能力，但留在我印象中的BI软件大多是概念很好，但实用性不强的家伙。前几天正好看到陈果的《为什么BI软件在中国很难做》的文章，谈到了商业智能（BI）在中国很难做的现象，认为BI是个开放式、探索式工具，国外的数据科学家依赖BI工具来进行快速的数据探索和分析，这种工作模式使得BI有很好的群众基础，而中国人的思维方式不是探索式（Exploration）的，而是“结果导向式”的，中国管理者都习惯看固定格式报表、基于指标的图表，中国企业里很少有数据科学家（data

文章来源：数据工匠俱乐部0从一个曲线图说起数据可视化只是数据分析中的一步，不是所有。今天，我们从一个数据可视化中典型的指标曲线开始说起。（图-1：某连锁超市每个月利润率的指标曲线）如上图，某个业务指标的趋势很容易通过可视化展示出来，但缺憾在于，单纯的可视化不能告诉用户，某个节点指标大幅波动（上涨或下跌）背后的原因是什么。又是什么关键因素引起了这个波动？如果排除一个或多个关键因素后，可能会带来什么变化？然而这些问题，图-1这样简单的可视化图表无法直接给予用户答案，通常要有资深业务经验的分析师通过大量的分析操作，才能进一步解答。图中数据指的是连锁超市在一段时间内的利润率变化，那么2015年1月利润率的骤降是什么原因引起的？销售时间/周期、地区/门店、品类、送货方式，还是数据集中其他维度？分析师需要对每个维度做分析找原因，倘若品类维度是主要因素，那如何在成百上千个SKU里找到关键影响因子？可能需要分析师逐个排除寻找。在数据分析技术飞速发展的今天，是否有方式，来加速、简化整个分析过程？或者有没有一种方式可以降低准入门槛，在资深分析师人才短缺的情况下，让更多数据分析师，通过工具能力具备相关技能，加速实现业务目标？近年来，一个逐渐被大家熟悉的产品能力

文章来源：数据社数据治理是企业数据建设必不可少的一个环节。好的数据治理体系可以盘活整条数据链路，最大化保障企业数据的采集、存储、计算和使用过程的可控和可追溯。如何构建企业数据治理体系？企业数据治理过程需要注意哪些问题？总体而言，不能一口一个胖子，路要一步一步地走。下面我将结合企业级数据治理经验，详细介绍从0到1搭建数据治理体系全流程，帮你梳理数据治理的主要内容以及过程中会遇到的哪些坑。1

文章来源：数据治理体系数据仓库模型构建一、数据仓库构建需要考虑的问题与数据库的单表基于ER模型构建思路不同，其面向特定业务分析的特性，决定了它的构建需要整合多套数据输入系统，并输出多业务条线的、集成的数据服务能力，需要考虑更全面的因素，包括：业务需求：从了解业务需求着手分析业务特点和业务期望；系统架构：从系统架构和数据分布、数据特性等角度，分析系统架构设计上是否有问题；逻辑设计：从数据模型逻辑设计出发是否设计合理，是否符合数据库开发和设计规范等；物理设计：从库表类型、库表分区、索引、主键设计等维度，主要针对性能，可扩展性进行物理模型设计审查二、什么是数仓的数据模型数据仓库模型构建的宗旨能够直观地表达业务逻辑，能够使用实体、属性及其关系对企业运营和逻辑规则进行统一的定义、编码和命名，是业务人员和开发人员之间沟通的一套语言，数据仓库数据模型的作用：统一企业的数据视图；定义业务部门对于数据信息的需求；构建数据仓库原子层的基础；支持数据仓库的发展规划；初始化业务数据的归属；常用数据模型的是关系模型和维度模型，关系模型从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，其站在企业角度进行面向主题的抽象，而不是针对某个具体业务流程的，它更多是面向数据的整合和一致性治理；维度建模以分析决策的需求为出发点构建模型，直接面向业务，典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型，大多数据仓库均会采用维度模型建模；维度建模中的事实表客观反应整个业务的流程，比如一次购买行为我们就可以理解为是一个事实，订单表就是一个事实表，你可以理解他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录，订单表存放一些维度表中的主键集合，这些ID分别能对应到维度表中的一条记录，用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息：如果是采用ER模型，需要设计出一个大宽表，将订单-商家-地址-时间等信息囊括在内，比较直观、细粒度，但也存在设计冗余，如果数据量很大，对于查询和检索将是一个灾难；三、如何构建数仓的数据模型概念模型设计（业务模型）：界定系统边界；确定主要的主题域及其内容；逻辑模型设计：维度建模方法（事实表、维度表）；以星型和雪花型来组织数据；物理模型设计：将数据仓库的逻辑模型物理化到数据库的过程；1、概念模型设计数据仓库中数据模型设计顺序如上，数据仓库是为了辅助决策的，与业务流程（Business

这个话题备受争议，今天就来聊一聊。OLAP系统和OLTP系统分别叫事务系统和分析系统，业务中台一般属于OLTP，数据中台一般属于OLAP，传统业务中台和数据中台无论在组织上、系统上都是泾渭分明的，除了数据中台需要从业务中台采集数据，两者甚至可以做到老死不相往来。随着数字化转型的深入，很多企业的数据中台和业务中台的界限越来越模糊了，甚至开始发生职能冲突，下面是一个例子，大家可以感受一下：上面这张图体现出一个重要但隐蔽的问题，就是为前台提供推荐服务的场景，到底用哪种方案，是用③

摘要：京东零售十年交易额快速增长的背后，不仅是京东零售高速发展的十年，也是数据仓库技术架构演进创新的十年，EB级数据如何进行资产化沉淀和治理？如何支撑业务高速发展、精细化运营、规模化创新的不同阶段？在未来更加复杂多变的环境下，将如何持续演进？作者：尹翔编辑：老鱼

今天给大家分享一波数据分析必备技能——SQL基础知识数据分析的基础查询语句，不管是数据分析小白还是在恶补基础知识的数据分析师，都快来学一学吧！本文目录：基础查询字符串\数字\日期时间聚合数据查询子查询联接\组合查询高级查询更新数据01基础查询02字符串\数字\日期时间03聚合数据查询04子查询05联接\组合查询06高级查询07更新数据参考资料：《SQL

能够实现数据分析、机器学习，数据访问和管理等细粒度的授权、审计等功能。数据湖对存取的数据没有格式类型的限制，数据产生后，可以按照数据的原始内容和属性，直接存储到数据湖，

随着数字化时代的到来，近几年数据领域的新技术概念不断涌现，无论是数据湖、湖仓一体、流批一体、存算一体、数据编织抑或数据网格，很多还爬上了Gartner曲线，其中数据网格备受关注，数据网格从字面意思来看挺抽象的，会劝退很多人，但当你深入去理解这个概念时，才发现奥妙无穷。一、数据平台架构演进历史要理解数据网格，先得回顾下数据平台的发展历史，它们的典型代表分别是数据仓库、数据湖及湖仓一体。第一代：数据仓库1980年代中后期，为解决数据库面对数据分析的不足，孕育出新一类产品数据仓库。让我们先来看下数据仓库的定义，数据仓库（Data

规范化和反规范化当具有多层次的维度属性，按照第三范式进行规范化后形成一系列维度表，而非单一维度表，这种建模称为雪花模式。将维度的属性层次合并到单个维度中的操作称为反规范化。3.

price>100--END--详解维度建模之事实表数仓中指标-标签，维度-度量，自然键-代理键，数据集市等各名词解析及关系数据交换工具是ETL的替代升级吗？数据中台和大数据平台有啥不一样？|

文章来源：五分钟学大数据一、背景在大数据时代，规范地进行数据资产管理已成为推动互联网、大数据、人工智能和实体经济深度融合的必要条件。贴近业务属性、兼顾研发各阶段要点的研发规范，可以切实提高研发效率，保障数据研发工作有条不紊地运作。而不完善的研发流程，会降低研发效率，增加成本与风险。数据研发规范旨在为广大数据研发者、管理者提供规范化的研发流程指导方法，目的是简化、规范日常工作流程，提高工作效率，减少无效与冗余工作，赋能企业、政府更强大的数据掌控力来应对海量增长的业务数据，从而释放更多人力与财力专注于业务创新。二、数据开发流程鉴于对日常数据仓库研发工作的总结与归纳，将数据仓库研发流程抽象为如下几点：需求阶段：数据产品经理应如何应对不断变化的业务需求。设计阶段：数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素，更好地组织与存储数据。开发阶段：数据研发者如何高效、规范地进行编码工作。测试阶段：测试人员应如何准确地暴露代码问题与项目风险，提升产出质量。发布阶段：如何将具备发布条件的程序平稳地发布到线上稳定产出。运维阶段：运维人员应如何保障数据产出的时效性和稳定性。具体开发流程需求：与运营产品讨论需求。业务方把需求提交到JIRA，并且和产品沟通过。PRD评审：产品评审PRD文档。技术方案讨论：最好是负责人先沟通一个初级的方案，然后找大家一起讨论（可能比直接头脑风暴效率搞，根据负责人的经验来讨论）；然后找大家一起讨论。技术设计评审：设计评审叫上测试。设计评审的原则是，评审会议应该是设计方案大家基本认同的前提下，做方案的文档。设计接口：重点准确描述输入和输出。设计字段：根据需求定义字段，并确定字段指标和获取来源，建立数据字典。开发：开分支，写代码。做好测试case的建立，然后自测。代码review：叫上测试和一个其他开发同学，给出review的结果。目的是让其他同学帮忙review其中的逻辑。提测：给出提测报告，包括罗列测试点。上线：提前告知运维，提前申请机器资源，根据业务预估好CPU、存储、带宽等资源。文档：开发完成后，文档记录一下流程以及提供数据表字段说明，方便重构。数据需求流程各个角色职责这个流程针对的是项目是开发，在项目立项的开始，就需要明确各个角色的职责，而且需要和多个角色进行配合。作为数据开发人员，需要协调和各个角色之间的交互：需要和产品评估该需求的合理性，现有技术栈能否支持该需求，例如：公司想要做个实时数据大盘，如果没有实时数仓的架构，是没法完成这块需求。一旦确定开发，需要协调资源，包含开发资源、设备资源等等。需要和业务方、产品方评估数据可行性，数据开发的数据源并不是凭空出现的，需要和业务方明确已有数据能否支撑需求开发，如果缺少数据，则需要另行规划缺失数据的抽取方案。需要自己评估技术可行性，数据开发可能涉及到数据传输、数据同步、ETL、实时开发、离线开发等等，要评估从数据源获取到数据展现一套流程的可行性，例如：数据源如果为多个地方产出，可能需要从binlong获取、Kafka读取、业务库同步、HDFS读取等等，数据输出也可能到各个地方，例如：mysql、hive、ES、Kafka、redis等等多个存储，需要在开发之前确定整套数据的流程。需要确定是否满足安全与合规要求，对于一些敏感数据如何处理，是一个很重要的组成部分，作为数据开发人员，可能接触的数据比较多，但是哪些数据可以展现、哪些数据脱敏后可以展现、哪些数据不能落地等等，而且在数据流转过程中，也要关注数据的安全性，能否落地、能否转存等等。需要和测试同学同步数据处理逻辑，并将一些逻辑的SQL进行文档化，方便测试同学进行单元测试，在交付测试之前，需要对代码进行自测，以便保障流入到测试执行环节的代码达到一定的质量标准。同时最好能让代码通过配置在不同环境进行切换，方便测试同学在测试环境、预发环境进行测试，测试通过后同一套代码能够直接上线。三、日常数据支撑除了项目式的开发外，数据开发人员大部分情况下都会面对产品提出来的一些临时性的数据需求，例如拉去一下近半年的销售情况、用户访问情况等等，这部分数据支撑不需要后端配合、可能也不需要进行测试，而是在已明确的数据指标的基础上，定期或者不定期的提供一个数据报表。这部分的数据开发模式相对来说比较简单和快速，但是也需要明确：明确数据需求模板、常规需求申请单等等，提供需求单的目的是避免长时间的沟通，特别是已经有的数据指标，只需要让产品提供一份详细的数据需求单，按照需求单的模版进行提供数据即可。模版如下：指标需求中通常会涉及到下表中的约定项，如果需要自定义约定项，可以在自定义格式列进行填写。明确需求的指标含义，和所需求的字段明细、统计周期、开发周期等。四、注意需求评审完成后，如果发生需求变更或者迭代，一定需要提供迭代/变更的需求申请单，或者提供JIRA，避免需求不可追溯。对于一些重要指标的定义，就算文档中写了，也要和产品进行确定，例如产品需要近半年的所有销量，那么要明确这个销量是否包含退款、是按照成交时间还是付款时间来计算等等。避免数据指标不匹配，导致二次开发。开发过程中，文档要规范，先设计在开发，而且在做系统建设的时候，要有全局视野，不局限某一个点，并不是发布完成了，就算结束，代码开发完成只是第一步，后续的文档建设、代码复盘、数据监控、数据告警、稳定性等等，都需要在开始规划好。及时反馈，在开发过程，不论进行到哪个阶段，项目期间每天都需要和前后端同步一下进度，避免延期的风险。故障处理，在程序上下后，可能会因为客观或者代码的原因出现一些BUG，不同的故障处理方案不同，但是注意复盘和故障记录，避免下次出现相同的BUG。故障等级定义：P0

自我接触数仓以来，数仓建模就是最为核心的工作，而数仓建模的主要目的是建立公共层，公共层主要起到两个作用，第一个是屏蔽底层的变动对上层应用的影响，第二个作用是通过复用沉淀的公共层来提升应用支撑的效率，但在长期的数仓公共层运营实践中中，我发现公共层的表现不总是沿着我们设想的轨迹演进。1、无论数仓公共层开始的时候设计的多么完美，数仓公共层最后的使用比例2/8现象明显，大量的公共层模型是没人使用的，项目投入的80%都被浪费了。2、当前的数仓公共层和5年前的数仓公共层差别不是很大，意味着新业务没必要用新的公共层去支撑，间接否认了公共层存在的必然性。3、数据仓库公共层经常会由于积重难返而被推道重来，比如5年一次，对于公共层的投资似乎并不是很划算的生意。我们当然不能否认公共层的价值，但其价值也许的确被高估了，设想一种场景，假如不预先做数仓公共层的建模，我们对业务的支持真的会变得很糟糕吗？恰好，我也有实践。1、在遥远的报表时代，为了实现报表会做大量的临时汇总表，那个时候没怎么考虑复用，但似乎也没什么大问题。在报表时代过度到数据仓库时代的时候，其实并没有什么强烈的业务驱动要做什么公共层，但由于那个时候数仓关系建模已经兴起，大家都觉得做公共层成了理所当然的事情，毕竟复用是很先进的理念，但其实大多就是把临时汇总表搞成了公共层而已。2、在大数据时代，我们在hadoop上开出了很多租户，虽然主租户做了大量公共层模型，但各个部门的租户基本上是随着应用的需要建立起的一堆中间表和宽表，复用主租户的公共模型并不是很多，但大多却活得很好，我们经常指责租户没用复用意识，导致大量的计算资源浪费，但要说浪费，我们80%的公共模型没人使用何尝不是更大的浪费呢？事实上，各个部门租户的资源是有限的，但各部门还是靠自己的运营保证了基本的生产需要。数仓公共层的理想很好，但大多数据团队实际并不具备什么公共层的运营能力，为什么呢？1、大多公司的业务团队比较强势，数据团队很难坚持一些数据架构的原则2、业务部门提需求没有什么成本，大量低质量的需求把数据团队有限的资源耗光了，数据团队很难有时间去考虑公共层的优化3、公共层的价值体现很慢，大家更多的精力还是投在了应用建模上4、公共层对于业务、技术、数据的综合要求很高，数据团队普遍缺乏此类人才与此同时，数据湖、湖仓一体等新技术的出现都对数仓公共层的建设必要性提出挑战，技术的趋势似乎都在朝着数仓公共层的反面进行，即强调原始数据分析的所见即所得，强调对不可知数据和不可知业务的探索分析。数据仓库通常预先定义

文章标题看起来有点政治不正确，但话糙理不糙，虽然数据治理最终靠的是文化，但起步的时候，还是要多诉诸利益。下面给出了基于利益驱动来解决数据治理十大问题的方法（仅是示例），供你参考，注意这里的主角是企业数据管理者。问题一、数据治理如何加钱加人？理性做法：跟财务部和人力部说明数据治理的重要意义和价值，然后提出数据治理人和钱的需求。利益做法：跟大老板汇报企业数据治理的举措，获得他的支持，顺便提出人和钱的需求，录下老板的承诺，然后将录音转给财务和人力。问题二、部门墙如何打破？理性做法：在跟A部门谈提升数据汇通效率的时候，晓之以理，动之以情，国家，政府，集团，领导的各种大道理都搬出来，但A部门可能岿然不动，因为A部门有自己的苦衷，比如条线有自己的管理要求，技术上有很多的挑战，反正总之已经尽最大努力来提供数据了。利益做法：去A部门开个会，给A部门带几个礼包：A部门需要的其它领域的数据全部提供，A部门数据开放产生的安全问题我背，然后一起到公司领导这边拍胸脯。问题三、数据安全如何平衡？理性做法：要求数据安全部门充分考虑安全和灵活的平衡，不要因噎废食，多考虑用数字化手段来解决数据安全开放的效率问题。利益做法：对公司提建议，要求安全部门的KPI不仅要背安全指标，还要背数据开放的效率指标，比如数据直接开放的比例、数据开放的时长等等，这些指标的权重不低于50%。问题四、如何让各部门重视数据治理？理性做法：成立企业级数据治理组织，发布数据治理标准和规范，打造联合项目团队，推进重点改革项目，一把手带头宣贯。利益做法：数据治理具体要求写进各部门的职责，各部门设立数据责任人和数据专员，每个月各部门参加企业数据治理推进会并汇报工作。问题五、如何有效推进数据治理工作，比如数据盘点？理性做法：让领导开个宣贯会，给各部门安排数据盘点的工作，要求大家务必高度重视，在XX之前保质保量完成盘点。利益做法：制定数据盘点的方法，提供盘点的模板，明确盘点的优先级，进行盘点的培训，做好盘点的审核和反馈，安排专员提供服务支持。问题六、应该由谁负责主数据？理性做法：基于成本最低原则，谁主数据多，谁离主数据近就谁负责。利益做法：谁获益最大谁负责，如果实在找不到，那就让企业数据管理部来吧，如果谁都不愿意交出自己领域的主数据，那就让损失最大的部门负责。问题七、数据治理价值如何体现？理性做法：数据采集周期缩短X%，数据开放流程环节从Y缩短到Z，端到端开放周期缩短E%，数据治理不直接产生业务价值，体现的是蜜蜂效应。利益做法：数据A的新增直接带来了多少商机，数据B的量级提升让客群规模提升多少倍，数据C让以前不能做的多少应用可以实现，断供。问题八、数据治理如何提升感知？理性做法：自底向上，工匠精神，埋头苦干，相信酒香不怕巷子深。利益做法：把数据治理当成产品去运营，做好也要Show好，大屏出现在各种场合，如下示例。问题九、如何应对跨域数据支撑的惰性，比如对于其它领域的创新业务支持度不够？理性做法：强调创新业务的价值和协作拉通的重要性，建立跨部门项目团队推进。利益做法：引入第三方数据团队（比如企业数据治理团队）打破领域数据的垄断支撑，触发领域的损失厌恶。问题十、领域能不能仍然保留自己的数据中台？理性做法：数据中台只有一个，领域不能保留自己的数据中台，这样才能保证数据的一致性和集约化。利益做法：领域数据中台只要遵循规范，可以作为企业数据中台的一部分存在，双方逻辑虽然分开，但可以互相赋权，对外呈现一套数据目录，和而不同。如何保障数仓数据质量？数据开放，90%的人搞不清的事情

。事实可以通过回答“过程的度量是什么”来确定。应该选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致。事实有可加性、半可加性、非可加性三种类型

作为一个数据人，是不是经常被各种名词围绕，是不是对其中很多概念认知模糊。有些词虽然只有一字之差，但是它们意思完全不同，今天我们就来了解下数仓建设及数据分析时常见的一些概念含义及它们之间的关系。本文结构如下图所示：一、数仓中常见概念解析1.

正文开始研究国外业内前沿数据产品，了解当前实现数据价值的最新思路和实践。无论哪一种数据产品，仪表盘（Dashboard）都是最核心的功能。它作为用户接触数据的第一个页面，相当于数据产品的门户，担负着提纲挈领，引导分析的重要职能，帮助用户能够快速判断业务情况，支持他们做出决策并行动。个人有幸经历过三个数据平台的

正文开始引言数据服务交换和服务工具作为一体化数据治理和共享平台一个重要组成部分,包含了数据采集服务、数据交换服务、数据加工服务、数据共享服务等模块。数据交换和服务工具采用面向微服务的插座式的架构，实现数据交换、数据整合、数据复制、数据的传输、数据共享等功能。支持跨组织、跨网段的、不同区域的、上下级单位海量数据交换和服务、适应基于前置机的、物理隔绝的数据交换和服务等多种应用场景，保证数据完整性、安全性、可靠性和传输性能，确保提升数据质量与及可用性，为数据需求部门提供准确可用的数据。本文详细介绍数据服务交换和服务工具发展阶段,相关功能及典型的应用场景。一数据服务交换和服务工具经历三个阶段本文档---数据服务交换和服务工具处于第三个阶段，是统一的数据服务平台。也属于一体化数据治理和共享平台的重要组成部分。数据服务交换和服务工具发展阶段第一个阶段是比较原始的，缺少工具阶段。通过写脚本、针对项目的开发实现，工具化程度差，项目实施和运维成本高。第二个阶段多样化的工具阶段，提供了能解决特定功能的工具产品。如消息中间件、ETL、文件传输等。但对于复杂环境下的大型项目有很大的不足，需要多个工具集成，缺少统一的架构、有孤岛，集成实施成本高，交换过程中面临丢包、系统堵塞等问题，安全稳定性差。第三个阶段是统一的数据交换和服务平台，提供面向服务的插座式架构，基于统一的规则和元数据、统一架构、统一工具能可视化配置出数据采集、数据交换、数据加工、数据共享等不同的数据服务方案，能满足客户不同项目的数据交换和数据管理需要。提供端对端的数据交换和整合服务，保证了交换过程中的可靠传输，避免了丢包、系统堵塞等问题。二挑战与解决思路2.1传统的数据交换工具面临挑战（1）传统的数据交换解决方案是基于多个模块/产品集成实现跨网段数据交换，当一个环节出现问题时易造成数据不一致。（2）当采用异步交换方式时，异步的交换机制造成IO等系统资源占用、文件锁死、堵塞挂起等现象。（3）当采用同步的交换方式时，同步交换机制在交换数据量比较大，需要传输或者装载时间比较长时，易造成通讯挂起、堵塞等现象。传统数据交换工具示意图2.2跨网段情况下的大数据量的数据交换与服务思路（1）基于统一的数据交换服务实现了端对端的数据交换。（2）通过事务处理机制保证跨网段交换的数据一致性。（3）状态传感器技术解决了分布式传输过程的状态感知，避免了需要长时间处理情况下的通讯挂起现象，保证了传输的畅通。一体化数据交换和治理示意图基于统一的数据交换服务实现了端对端的数据交换。通过事务处理机制保证交换的数据一致性。状态传感器技术解决了分布式传输过程的状态感知，避免了需要长时间处理情况下的通讯挂起现象，保证了传输的畅通，跨网段情况下的大数据量的交换能力强。配置、部署、运维简单。三数据交换与服务工具总览数据服务交换和服务工具包含数据采集服务、数据交换服务、数据加工服务、数据共享服务等模块，并提供统一的工具实现可视化配置、任务的管理、安全管理、运维监控等。͏数据交换与服务工具数据服务工具采用面向服务的架构，提供数据服务实现数据交换、数据整合、数据复制、数据的传输、数据共享等功能。主要包括运行支撑、加工组件、服务组件、数据服务总线等组成。基于统一工具、统一的架构、统一的运行支撑、统一元数据管理实现数据采集、交换、加工、共享等功能，可以根据项目特点选择不同的模块组合，形成不同的数据服务和治理解决方案。基于微服务架构的“插座式”架构四数据交换与服务工具详细功能设计4.1数据采集服务组件数据采集服务主要负责异构、异地的多源数据到贴源缓存区的采集，实现内外部系统的结构化数据、半结构化数据、非结构化数据等不同类型、不同时效的数据的复制与整合。（1）异构数据的采集与加工基于流加工技术提供统一、规范的数据接入方法，从内外部数据源向平台导入结构化数据（如关系型数据库数据、应用系统数据、生产实时数据）、半结构化数据（如日志、邮件等）、非结构化数据（如文本、图片、视频、音频、网络数据流等）等不同类型的数据、不同时效的数据，并提供这些数据的整合方式。主要特点：提供分组平行加工能力，提高数据采集的性能。支持复杂网络环境下可靠数据采集，提供跨网段、跨单位的联动式数据采集。提供事务处理机制，保证采集数据的一致性。通过统一的采集处理接口，方便不同的采集源集成，满足特殊数据采集的需要。通过可视化工具实现异构、异地数据采集的可视化配置；实现采集过程中的数据加工规则的可视化配置；实现数据采集过程中的可视化管理和监控。（2）数据复制支持结构化数据和非结构化数据的复制，将异构、异地的数据库数据、文件数据复制到缓存库中。数据复制与验证服务

“

本文根据系统架构师IT老兵王保强在ITPUB技术栈系列线上沙龙活动演讲整理而成。前一段时间，一篇《“中台”是怎么臭了大街的》把“中台”这个风口又推倒了浪尖，自2018年中台火了以后，冰火两重天，赞美和质疑之声从未间断。数据中台是什么？数据中台和大数据平台有啥不一样？相信是很多人的困惑。ITPUB技术栈在疫情期间推出一系列线上沙龙活动主题包含大数据应用架构、存储与计算、数据治理与数据中台的建设、云计算的实践与探索，本期邀请到了IT老兵王保强，结合自身经验探讨大数据平台和数据中台的建设之道。目前在南方电网旗下某IT公司任职的王保强主要负责数据治理工作，拥有21年IT工作经验，曾在海南移动负责数据仓库、大数据平台等项目，见证了从传统数据仓库转型到大数据平台的全历程，见证了大数据平台从0到1的全部过程，对数据中台也有自己独特的思考。什么是数据中台？现在各种新名词层出不穷，顶层的有智慧地球、智慧城市、城市大脑；企业层面的有数字化转型、互联网经济，数字经济、数字平台；平台层面的有物联网，云计算，大数据，5G，人工智能，机器智能，深度学习，知识图谱；技术层面的有数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等，总之是你方唱罢他登场，各种概念满天飞…关于数据中台，王保强总结了市场的几个主要概念和描述：1、数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。2、数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。3、数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。4、数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。5、数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。“数据中台就是数据服务化，服务化的核心是数据模型化和服务组件化，服务化的基础是大数据平台或数据仓库。”王保强认为能够提供高效的数据服务化，是数据中台的特征。结合王保强的实践经验，从数据仓库到大数据平台再到大热的数据中台，是一脉相承的。数据仓库

group，默认为10000个值组成。每次读取文件是以行组为单位的，一般为HDFS的块大小，保存了每一列的索引和数据。在ORC文件中保存了三个层级的统计信息，分别为文件级别、stripe级别和row

01文章概览（一至五）✦一、为何需要实时数仓架构二、数仓如何分层&各层用途三、数仓分层的必要性四、从Lambda架构说起五、Kappa架构解决哪些问题02文章概览（六至九）✦六、深入实时数仓架构［五种方案讲解］

关注精准营销、标签画像系统的同学，应该对阿里的达摩盘都很熟悉。今天和大家简单分享一些达摩盘的内容，主要是标签数据的层面，是作者自己写的爬虫把达摩盘的标签都爬下来然后整理的。因此，市面上应该是独一份哦！供各位做标签画像系统的朋友参考。关注我们的公众号，在公众号内发送“达摩盘”，将发送大家材料的分享链接。。本来这篇文章是去年发过的，但是当初关注的用户比较少，很多新朋友没有看过这篇。再加上这两天好几个公众号转发了我这篇文档，收获了很好的阅读与关注，因此再次给大家分享一下。下面简单介绍一下达摩盘以及这份调研材料的一些内容。01—达摩盘是什么达摩盘其实就是阿里推出的一款精细化运营的工具，涵盖了消费行为、兴趣偏好等各种类型标签，提供

阿里数据中台建设方法论工商银行近20年实时大数据平台建设历程点击左下角“阅读原文”查看更多精彩文章，后台回复【加群】申请加入万人数据学习社群🧐分享、点赞、在看，给个3连击呗！👇

本文根据系统架构师IT老兵王保强在ITPUB技术栈系列线上沙龙活动演讲整理而成。前一段时间，一篇《“中台”是怎么臭了大街的》把“中台”这个风口又推倒了浪尖，自2018年中台火了以后，冰火两重天，赞美和质疑之声从未间断。数据中台是什么？数据中台和大数据平台有啥不一样？相信是很多人的困惑。ITPUB技术栈在疫情期间推出一系列线上沙龙活动主题包含大数据应用架构、存储与计算、数据治理与数据中台的建设、云计算的实践与探索，本期邀请到了IT老兵王保强，结合自身经验探讨大数据平台和数据中台的建设之道。目前在南方电网旗下某IT公司任职的王保强主要负责数据治理工作，拥有21年IT工作经验，曾在海南移动负责数据仓库、大数据平台等项目，见证了从传统数据仓库转型到大数据平台的全历程，见证了大数据平台从0到1的全部过程，对数据中台也有自己独特的思考。什么是数据中台？现在各种新名词层出不穷，顶层的有智慧地球、智慧城市、城市大脑；企业层面的有数字化转型、互联网经济，数字经济、数字平台；平台层面的有物联网，云计算，大数据，5G，人工智能，机器智能，深度学习，知识图谱；技术层面的有数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等，总之是你方唱罢他登场，各种概念满天飞…关于数据中台，王保强总结了市场的几个主要概念和描述：1、数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。2、数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。3、数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。4、数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。5、数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。“数据中台就是数据服务化，服务化的核心是数据模型化和服务组件化，服务化的基础是大数据平台或数据仓库。”王保强认为能够提供高效的数据服务化，是数据中台的特征。结合王保强的实践经验，从数据仓库到大数据平台再到大热的数据中台，是一脉相承的。数据仓库

文｜傅宇康有赞数据报表中心为商家提供了丰富的数据指标，包括30+页面，100+数据报表以及400+不同类型的数据指标，它们帮助商家更合理、科学地运营店铺，同时也直接提供分析决策方法供商家使用。并且，每天在跑的底层任务和涉及的数据表已经达到千级别。面对如此庞大的数据体系，作为测试如何制定质量保障策略呢？这篇文章将从：1.有赞数据链路

有好友负责企业数据治理的工作，最近制定了一部企业内的数据开放管理办法，初稿出来后，就发给各个部门征求意见了，然后各种意见纷至沓来，令他惊讶的是，大家似乎对数据开放这个概念的理解并不一致，比如：A部门建议：“公司内部的数据流通不能叫数据开放，应该叫数据共享！”B部门建议：“系统间的数据流动需要在数据开放管理办法考虑！”C部门建议：“报表的开放需要在数据开放管理办法中予以考虑！”D部门建议：”部门内的数据流动需要在数据开放管理办法中予以考虑！“数据开放这个概念看着简单，但每个部门每个人似乎都会受到自身背景的影响而对这个概念产生不同的理解，比如搞安全的很容易把数据开放与数据共享、数据交换等概念混为一谈，认为这些都是需要在办法中考虑的。那么，数据开放和数据共享有没有区别？部门内的数据流动是否属于数据开放的范畴？报表算不算数据开放的形式？今天就来聊一聊。在《数据资产管理实践白皮书（5.0版）》中，我找到了以下的关于数据开放、数据共享及数据交易概念的诠释：数据共享是指打通组织各部门间的数据壁垒，建立统一的数据共享机制，加速数据资源在组织内部流动。数据开放是指向社会公众提供易于获取和理解的数据，对于政府而言，数据开放主要是指公共数据资源开放，对于企业而言，数据开放主要是指披露企业运行情况、推动政企数据融合等。数据交易是指交易双方通过合同约定，在安全合规的前提下，开展以数据或其衍生形态为主要标的的交易行为。数据共享、数据开放、数据交易的区别在于交换数据的属性与数据交换的主体范围。对于具备公共属性的数据，在组织体系内部流通属于数据共享，如政府机构之间的数据交换，在组织体系外部流通属于数据开放，如公共数据向社会公众开放。对于具有私有（商品）属性的数据，在组织内部流通属于企业数据共享，如企业部门间数据交换，在组织外部流通属于数据交易。在《数据治理-工业企业数字化转型之道》中，也有类似的解释：数据共享主要指的是面向企业内部的数据流动，其中由数据应用单位提出企业内部跨组织跨部门的数据获取需求，由对应数据供给单位进行授权并由信息部门向该数据应用部门开放数据访问权限。而数据开放则指企业向政府部门、外部企业、组织和个人等外部用户提供数据的行为。可以看到，数据开放似乎变成了政府公共数据对外开放的专有名词，但站在企业的角度看自己内部，如果这个企业拥有一个统一的企业数据管理组织，即数据供给组织，它已经归集了企业所有的数据并且有管理权，那么就存在一个向各部门开放数据的问题，这理所当然也是数据开放的范畴。很多企业还没有企业级的数据管理组织，数据开放的主体并不存在，无所谓数据开放，因此把各个部门间网状的数据流动叫作数据共享。但如果像华为一样，企业已经建立了数据责任人制度，明确了企业数据责任人和领域责任人，这个时候企业数据责任人也需要履行跟政府类似的职能，比如制定数据开放管理办法，用以规范向各部门开放数据的行为，将以前无序、低效的数据流动（比如数据共享）转变成有序、高效的数据开放，只有这样才能充分释放出数据要素的价值。那么，报表下载这种算不算数据开放呢？我们可以先看看业界对数据开放的定义：世界银行：开放数据是指“能被任何人出于任何目的不受限制地进行自由利用、再利用和分发，并最大程度保持其原始出处和开放性的数据”。G8《开放数据宪章》：开放数据是指“具备必要的技术和法律特性，从而能被任何人、在任何时间和地点进行自由利用、再利用和分发的电子数据”。浙江省政府：公共数据开放是指“公共管理和服务机构面向社会提供具备原始性、可机器读取、可供社会化利用的数据集的公共服务”。上海市政府：公共数据开放是指“公共管理和服务机构在公共数据范围内，面向社会提供具备原始性、可机器读取、可供社会化再利用的数据集的公共服务”。从这些定义了会发现几个关键词即“原始数据”、“可机器读取”、“可供社会化利用”，为什么要强调这些特征呢？数据开放的目的是让别人也能有效利用数据产生价值，但不同层面的数据可供再利用的潜力是不一样的。就拿政府的信息公开来讲，你说这些公开的信息有没有价值，当然有，但这些“信息”往往经过了分析、加工和解读，被赋予了特定意义，其再被利用的价值已经很低了，举个例子：气象局告诉你“今天会下雨”，这是一个信息，但你很难利用这个信息再进行二次创造，但如果气象局把得出“今天会下雨”这个结论依赖的原始数据和预测算法也告诉你，比如温度，湿度等等，那么你就可以利用这些原始数据用于更多的用途，比如预测灾难。可以说，数据是信息的底层，数据比信息具有更大的再利用空间和挖掘潜力。但如果气象局只是把温度，湿度等原始数据通过文档或网页文本的形式提供出来，由于这些文本数据无法被机器直接读取，或者需要通过人工或NLP等方法处理后才能使用，这样成本就太高了，这种数据开放的价值就大打折扣了。因此，在各国的数据开放实践中，开放数据通常呈现为以电子化、结构化、可机读格式开放的数据集。数据集是指由数据组成的集合，通常以表格形式出现，每一列代表一个特定变量，每一行则代表一个样本单位。报表虽然也是一种数据流通的方式，但一般不把报表看做数据开放，一方面是因为大多报表数据是面向特定业务高度加工过后的信息，另一方面是报表往往无法被机器直接读取，需要一定的转化处理，很多企业动辄说我有10000张报表，1000个指标，你看我数据的利用很好吧，但数量多并不意味着质量，也许生成10000张报表的基础只是50张原始表而已，大家都在自己画的圈里面内卷。同样的，数据可视化、数据服务、数据产品一般也不属于数据开放的范畴，因为用户无法有效获得可视化、数据服务、数据产品背后的原始数据集，也无法对这些数据进行再次利用。很多企业部门间数据开放，数据提供部门由于各种利益的考虑，往往只愿意提供汇总数据，不愿意提供原始数据，而且要求数据需求部门说明业务用途，这种数据开放的价值其实不大，因为只能定向解决一个特定的业务问题，跟数据开放的目标相去甚远，企业所以要建立统一的数据管理组织，就是要规范这种问题，数据共享讲得是解决具体问题，数据开放追求的则是价值创造。当前主流的数据开放形式有两种，一种是数据集合，另一种就是API。数据开放是跨组织数据消费的基础，明确数据开放的定义和范围，形成大家对数据开放的共识，是推动数据开放能力提升的前提，希望对你有所启示。如何跟老板解释清楚什么是主数据？by

Hive作为大数据平台举足轻重的框架，以其稳定性和简单易用性也成为当前构建企业级数据仓库时使用最多的框架之一。但是如果我们只局限于会使用Hive，而不考虑性能问题，就难搭建出一个完美的数仓，所以Hive性能调优是我们大数据从业者必须掌握的技能。本文将给大家讲解Hive性能调优的一些方法及技巧。Hive性能调优的方式为什么都说性能优化这项工作是比较难的，因为一项技术的优化，必然是一项综合性的工作，它是多门技术的结合。我们如果只局限于一种技术，那么肯定做不好优化的。下面将从多个完全不同的角度来介绍Hive优化的多样性，我们先来一起感受下。1.

在生活中，标准与我们息息相关，吃的食品需要满足国家标准才能食用，汽车排放达标才能够上路行驶，电脑接口得满足统一的标准才能够与外设对接等等。而在数据的世界，数据标准也同等重要。我们期望将数据标准真正应用到实践中去，帮助客户解决资产化不足、数据质量难以提升、数据开发效率低等问题，于是网易开始了数据标准的建设。本文将基于我们对数据标准的理解，阐述标准的建立并依据标准的建立内容和流程来设计的标准管理产品的介绍以及标准在数据治理过程中的具体实践，希望与大家碰撞出新的认识。1数据标准的是什么？在实际的工作生产中，我们一般会参照国家标准、地方标准、行业标准等来进行具体的活动，来确保我们生成过程符合监管要求、便于上下游协同等，于是我们会见到如下的标准指导文件：同样，数据标准也会以文件的形式存在，在除了国标、行标定义的标准外，企业内部为了便于各部门采取同样的数据建设规范，通常会使用文件来定义数据标准，以供各部门达成统一的共识。虽然文件是标准的一种体现形式，但文件是非结构化的，在实际应用中，我们只有理解、提取文件里的内容，将标准应用于产品设计及流程活动当中去，标准才能起到真正的规范约束作用。根据信通院发布的《数据标准管理实践白皮书》定义：数据标准（Data

前导读：数仓架构（ods-dwd-dws-ads）每一层之前我们已经分享过很多干货了，但dwd却还没有。今天这篇文章主要讲解数仓dwd层业务事实数据的搭建、解析、加载与案例实践。言往期干货：数仓建模—指标体系数仓建模分层理论数仓建模—宽表的设计数仓建模方法论数仓架构发展史一、DWD层结构DWD层是对用户的日志行为事实进行解析，以及对交易业务数据采用维度模型的方式重新建模（即维度退化）。1、回顾DWD层概念我们在来回顾一下对DWD层（Data

10年前，我是一支数据技术团队的主管，那个时候大数据概念开始流行，部门来的新领导挺感兴趣，因此安排我写一个大数据趋势判断的PPT材料，写了一个礼拜后，自己被安排去国外出差，为了不耽误PPT的进度，自己在宾馆闭门了2个礼拜，在回国之前终于完工。回国后第一天我就兴高采烈的去找领导汇报PPT，哪知领导才翻了2页PPT，就跟我讲，这不是我需要的东西......然后巴拉巴拉，自己这一个月的心血就这么白花了。后来吸取了教训，尽量压缩PPT初稿的时间，希望能在2个礼拜内能跟领导汇报一次，这样可以根据老板的意见尽快修改，但这种写法让自己和团队背负较大的PPT进度压力，而且每次跟老板汇报初稿后也不尽如人意，大改是十之七八，很多从头再来，大家都会觉得，跟老板过PPT是非常恐怖的事情。随着自己走上管理岗位，我意识到给老板写PPT也需要向上管理，老板的时间虽然宝贵，但其实我们的时间也不能随便浪费，老板经常花20分钟否决了我们3个人花了一个礼拜写得东西，对于公司也是一种资源的浪费，很多原因仅在于我们没有跟老板及时对齐信息而已。为什么会信息不对称呢？第一、你的背景跟老板背景不同，知识体系跟老板的也不一样，企业里层级差异越大，这个信息不对成程度就越大。第二、老板有很多的事情，没有足够的时间给出指示或想清楚具体要求。第三、下属没有勇气争取到让老板指示或想清楚的时间。很多PPT从一开始就走错了方向导致推到重来，写PPT，也需要向上管理。向上管理的策略很简单，就是遵循《精益创业》中提到的MVP

指标体系指标建设过程中遇到的问题指标建设方法论指标的构成如何设立指标体系评价指标体系指标管理场景落地总结指标体系提起指标这个词，每个人似乎都可以说出几个指标，像经常在工作中会听到的日活、月活、注册率、转化率、交易量等

Store，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到数仓。CDM：Common

报表的性能很重要，是一个总被谈及的问题，跑的慢的报表用户体验恶劣，无法忍受。解决这些慢的性能问题，也成了项目方和工程师头疼的事情。一出状况，就得安排技术好的，能力强的工程师去救火，本来利润就薄，还得不断的追加人工成本，而且工程师有时候也无能为力，并不是所有的性能问题都能靠程序员能力解决的这个总会让人头疼的问题没办法解决吗？没有好的方法去提升性能了吗？解决这个问题之前，我们得先理清楚问题的根源，是什么导致了报表的性能问题，找到根源，我们才能对症下药，才能治本报表性能问题出在什么环节？报表的呈现周期中，大致可以分为下图的

从事数据治理工作后，自己对于人才的追求越加迫切，那么，什么样的人能干成事呢？能理解别人的意思，能让别人理解你的意思，遇到问题能快速的形成思路去解决，做事始终能稳在重点上，这就是我心中的职场聪明人，今天就来聊一聊。1、能理解别人的意思这里有三层含义：第一层：善于接近老板。职场的聪明人不是指溜须拍马，而是对于老板的言行比较关注，努力寻求相同的上下文，从而能够站在老板的角度思考事情，这其实是一种换位思考能力。比如公司刚开过工作会议，你可能瞄几眼就扔一边了，但聪明人（比如你的上级）可能就在那里琢磨推敲，这就是为什么同样是面对老板，聪明人能接的住话，而你可能根本不知道老板在说什么。有一次我带着下属A去做专题汇报，老板问了一个专业问题，我示意A回答一下，发现其没反应，回来的路上就问原因，A回答：“听不懂老板在问什么。”第二层：专业知识比较过硬。专业能力超过老板看似简单，但一般职场人士不一定能做到，因为老板认知水平比较高，问的专业问题不是那么好回答，如果职场人士平时荒废学习，不懂得刨根问底，很难说过得了老板这一关。比如老板问主数据是什么，有人会望文生义的说是主要的数据，其实这种解释老板自己拆字就能理解，根本不要你说，而聪明人则能把主数据是核心业务对象这个概念说出来，这才叫专业。第三层：敢于进行反复确认。老板不是每样事情都能交代的很清楚，到底只是随便说说，还是希望探索一下，或者真的在安排任务，聪明人都会主动核实，这需要一些勇气，看起来比较老实，但其实是大智，那种认为跟老板确认问题会被小看的人，会误了大事。比如有一次去跟老板汇报数据开放工作，老板要求我去梳理下公司的流程，当时自己误解为全部的流程，慌得很，会后自己大着胆子跟老板做了确认，才知道只是梳理数据开放的流程。第四层：善于听出话外之音。严格按照老板说的去做，往往只能做到70分，但如果能把握住老板的最终期望，就可能做到90分。很多聪明的人就是这么干的，老板让他这么干，他不仅要干成，而且要干的漂亮，这又何尝不是真正理解了别人的意思呢？达到这个境界的聪明人，做事往往有使命感，不是简单的给老板打工。最后，相信好记性不如烂笔头。遗忘是大脑的杀手，因此，对老板的重要讲话进行录音是理解老板意图的最有效手段之一，你的理解水平再差，架不住录下来分发给一堆智囊来为你出谋划策，聪明人都这么干。2、能让别人理解你的意思第一、重要的事情说三遍。一方面，我们要将脑子里网状的想法用语言这种线性的方式表达出来，本来就挺困难，另一方面，人类有个艾宾浩斯的遗忘曲线，我们看到的，听到的，如果没有记录下来，很快就会消失在记忆的彼端，比如读完一小时后会遗忘约56％。聪明人布置工作的时候，一般当场就会反复强调几次，甚至让人复述一遍，然后周会月会再提一下，这样才可能让别人记清楚。这个策略也特别适合去解决问题，今天说，明天说，一年后再提，直到问题解决。第二、先宏观再微观。专业人士之间的对话可以直入细节，但大多时候，我们的对话都在背景不太一样的两个人身上发生，一般还是要遵循先宏观讲一下，比如让人家知道做这个事情的背景、意义，价值，目的，思路等等，然后再讲较微观的内容，比如方法，流程，实操等，也就是说，只有两个人先对上眼了，才有继续展开的必要，这符合循序渐进，由浅入深的原则。每个人的知识体系结构就像一颗大树，先有树干，再有树枝，树干是掌握的最牢固的，新的信息要被理解，最好先跟树干发生关系，然后慢慢衍生，这也是先宏观再微观的底层逻辑。有时下属跟我汇报工作，一开始就没头没脑的讲细节，自己听得云里雾里，为了跟上下属的节奏，要么囫囵吞枣乱听一气，要么就不停的打断和提出挑战，沟通的效率之低可想而知。第三、用业务的语言表达。本质上就是换位思考，用别人都能理解的语言去表达事情，也就是说人话，如果在公司的语境里，说人话就是用公司的业务语言。举个例子，如果你跟老板汇报数据治理，老板一般能理解数据治理这个概念，因为治理概念大家都懂，但如果你提了主数据这个名词，就得先用业务的语言解释清楚什么是主数据。用业务的语言表达清楚专业知识对每个专业人士都是巨大挑战，没有一定的融会贯通，很难说得通俗易懂。3、遇到问题能快速的形成思路去解决遇到问题自己会干的就直接干吧，这是效率的保证，但如果碰到不会干的呢，聪明人也是有方法的。第一、充分利用别人的经验去做事。始终要相信，你干的事情，99%的前人已经干过了，他们的经验就是你做事的起点，不要做什么都重头再来。怎么吸收前人的经验呢？从领导、导师、专家和同事获得，无论是面对面沟通还是开会讨论，都是在尝试从别人那里获得经验并为我所用，单干蛮干是新人做事的大忌。我们可以学学领导，每次开会都是让别人先发言，吸收消化后再总结发言，这就是套路，发言最多的，往往不是水平最高的。第二、通过抽象思维实现举一反三。要做的事情总是千变万化，我们不可能每次做事都能找到一模一样的场景和解决办法，这就需要培养抽象思维的能力，即归纳和演绎，任何事情回归第一性原理以后，底层的道理就是那么点，基于这个点掌握方法论，做任何事情就能举一反三，做事的能力就能不断提升，孔子的“学而不思则罔”也是在讲这个道理。最近我发现DevOps跟数据治理底层的道理类似，为啥，因为都在做全局流程优化的事情，这就是归纳的价值，然后我如果掌握了流程的方法论，那么就可以演绎到DevOps、数据治理等工作上去。第三、具备拆解问题的能力。很多事情是非常复杂的，可能一下子找不到综合解决办法，这个时候可以借鉴下人类的分工思维，就是把事情拆解成一个个高内聚低耦合的简单模块，然后简单的人干简单的事，这样成本最低，效率最高。架构师干的就是这事，把系统合理拆分，然后拆分后的各个系统后续建设和运维成本最低，又比如让去你做数据治理，开始的时候会一头雾水，但是如果把数据治理拆解成组织、机制、流程、IT、文化等五个部分，就可能会找到一些切入点，如果粒度还太大，那就继续拆分，直到拆解到最小的可执行单元。4、做事始终能稳在重点上。前面大多在讲如何正确的做事，但事情做得再好，如果方向偏了，那也是竹篮打水一场空。第一、准确领会上级的意图。这一点在第1点里已经讲了方法，但要注意，老板安排的工作并不一定都是重要的，如果同时安排有多项工作，跟老板确认工作的优先级是必要的，不要去试图平均分配资源，不要想当然的认为可以干好。事实上，老板给的资源总是有限的，但你在老板最关注的点上投入再多的资源也不算多，在公司看来，一年里你只要干成一样事情就已经够多了，其他也许无足轻重，60分可以了。第二、能够跟上级汇报工作。如果自己的工作是重要的，那么上级一定愿意安排时间来听你汇报进展，只有在汇报过程中，才能进一步理解上级到底想要什么，有哪些衍生的事情需要去做，永远不能想当然的认为老板年初安排好工作年末去交答卷就可以了，这不是有标准答案的考试。很多重点工作是在汇报的交流中新产生的，上级不是神仙，不可能一下子给你安排一个肯定能爆仓的事情，在汇报中，大家可能会逐步了解到做这个事情的价值没想象中那么大，而那个事情价值更大，因此需要及时调整。第三、利用好OKR和KPI。两个都是目标管理，只是在量化上，周期上，方式上有些区别，KPI更适合按部就班型的工作，OKR更适合创新型的工作，这里以OKR为例说下，首先，本来上级要下级理解公司的目标挺难，也许说了三遍也没啥用，OKR比较决绝，索性让下属自己把目标定出来，然后跟上级去达成共识，这种方式的好处是记得住，其次，OKR以周为单位跟踪，以季度为周期去评估，比较容易与时俱进，不容易中途跑偏；最后，OKR不设置上限，容易激发活力，做出超出老板预期的事情。我最早在《详谈：赵鹏》这本书看到了这四个观点，深以为然，因此结合自己的理解总结成文。到底如何划分数据产品与数据中台的边界？by

知识体系吐血总结深度好文：关于数仓建设及数据治理的超全概括点击左下角“阅读原文”查看更多精彩文章，后台回复【加群】申请加入万人数据学习社群🧐分享、点赞、在看，给个3连击呗！👇

中台究竟是什么？它对于企业的意义又是什么？当我们谈中台时，我们到底在谈些什么？想要找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个⾓度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度来思考中台的价值，试图反推它存在的价值。所以，为了搞明白中台存在的价值，我们需要回答以下两个问题：第一个问题：企业为什么要平台化？先给答案，其实很简单：因为在当今互联网时代，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。很残酷，但这就是这个时代最基本的企业⽣存法则。⽽平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最核心的能力：⽤户响应力。这种能力可以帮助企业在商战上先发制⼈，始终抢得先机。在互联网时代，商业的斗争就是对于用户响应力的比拼。我们来看⼏个例子:1、阿里说起中台，最先想到的应该就属是阿里的“⼤中台，⼩前台”战略。阿里⼈通过多年不懈的努力，在业务的不断催化滋养下，将自己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。2、华为华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火”

等联机数据库中。将这部分数据以服务的形式暴露，即数据中台服务，从而提供给应用调用。粉色链路的数据，最终回到数据分析师那里，是蓝色链路的衍生。各个应用产生的数据，通过

指标体系指标建设过程中遇到的问题指标建设方法论指标的构成如何设立指标体系评价指标体系指标管理场景落地总结指标体系提起指标这个词，每个人似乎都可以说出几个指标，像经常在工作中会听到的日活、月活、注册率、转化率、交易量等

有一天，一个年轻人到美术馆看到一幅很美的画，不禁脱口而出：“这幅画真美。”一位老人走过来说：“年轻人且慢，我叫苏格拉底，你说这幅画真美，代表你知道”美“的意义是什么，我这把年纪了还不知道”美“的意义，请你启发我，告诉我什么是美？”年轻人觉得这个问题太简单了，可真要开口，却不知道从何说起。简单来说，美是客观的，还是主观的？如果说美是客观的，任何画只要满足某种条件（如布局、背景、色调满足一定标准）就可以称为美的，但天下没有这样的画；如果说美是主观的，只代表个人的审美品位，则不能用“美”来形容以求取别人的认同。年轻人本以为自己懂得了什么是美，追问之下发现其实不懂，心里十分沮丧。过了几天，年轻人又去美术馆，发现苏格拉底先到一步，站在一幅画前赞叹“这幅画真美！”年轻人心想机会来了，上次被问到说不出话，今天倒要看他怎么回答：”请问，你所谓的‘美’的意义是什么？”苏格拉底说：“很好，你问我‘美’的意义，请先告诉我‘’意义‘是什么意义？”天啊，这是什么问题！但千万不要认为这个问题不能成立。以上的故事虽然是虚构的，但绝对不是抬杠。一位西方学者出版了一本书叫《意义》，对“意义”一词给出了26种不同的含义。这说明进行逻辑思考首先应澄清概念，清楚分辨概念的主观意象与客观意义，尽可能排除主观的意象成分，而用客观的意义进行沟通，思考从起步就要非常谨慎。数据治理涉及公司组织、机制、流程、文化的变革，需要有人能把数据治理的概念普及到公司的每个人，特别是老板。但数据治理的概念很多，要理解清楚这些概念的本质不容易，把这些概念跟别人讲清楚就更不容易了，想当年光一个元数据的概念就把我绕晕了，什么技术、业务、管理元数据，元模型啥的。今天就来讲讲主数据，为什么要讲它呢，因为有次老板问什么是主数据，当时感觉没解释清楚，倒并不是说自己不懂主数据，而是缺乏有效的诠释方法，这也是写这篇文章的原因。那么，如果老板问你主数据是什么，假如只有15秒的时间，怎么才能言简意赅的把这个概念说清楚？按照我自身的经验，专业人士在对外解释专业概念的时候，容易犯二个错误：第一，把自身的背景知识等同于别人，比如会认为某个概念的基本定义就是常识，常识有什么好解释的呢，我去解释常识，显示水平低吗？第二，把实践经验当成真知，虽然实践得到的经验可贵，但容易以偏概全，这也是我们要去学习理论和规范的原因，做数据治理做到一定程度，还是要去读读DAMA等书籍，这可以让我们开阔视野，对数据治理的理解能上一个层次，经验抽象成了定义以后，不仅适用的范围广了，而且更容易让别人理解。很多人虽然干了主数据很多年，但也许真的不知道主数据是怎么定义的，老板一问，直觉反应就是把自己干的主数据的具体事情说一遍，什么物料编码啥的，什么一致性啥的，这对于外人的理解门槛是比较高的，特别是对于爱学习的老板，再往下沟通就比较难了，没有基本概念这个“1”托底，后面有再多的“0”，似乎也缺失了意义。那么，主数据的基本定义是什么呢？DCMM定义：组织中需要跨系统、跨部门进行共享的核心业务实体数据。DAMA定义：主数据是关于关键业务实体的权威的、最准确的数据，可用于建立交易数据的关联环境，主数据值被认为是“黄金”数据。《数据治理-工业企业数字化转型之道》定义：指满足跨部门业务协同需要的、反映核心业务实体状态属性的基础信息。主数据是用来描述企业核心业务实体的数据，是企业核心业务对象、交易业务的执行主体，是在整个价值链上被重复或共享应用于多个业务流程、跨越多个业务部门和系统、高价值的基础数据，也是各业务应用和各系统之间进行数据交易的基础。从业务角度看，主数据是相对固定、变化缓慢的，但它是企业信息系统的神经中枢，是业务运行和决策分析的基础。《华为数据之道》定义：具有高业务价值的、可以在企业内跨流程跨系统被重复实用过的数据，具有唯一、准确、权威的数据源。主数据通常是业务事件的参与方，取值不受限于预定义的数据范围，在业务事件发生之前就客观存在，比较稳定。因此，当老板问你主数据是什么的时候，首先要回答的就是“主数据是企业内核心业务实体数据”这个解释，老板也许很难一下子理解主数据能带来什么业务价值，但肯定能理解“核心业务实体”这种业务概念。如果能做到这一步，那么就算起了一个好头，虽然我们不能死读书，但超越经验，牢记一些基本定义是需要的，这不仅是加深理解的需要，更是高效沟通的需要，因为老板给你的时间也许只有15秒，啰里啰嗦抓不到重点是很多专业人士的毛病。其次，有些概念的定义是比较抽象的，这个时候，结合定义举些公司的主数据实例也是必要的，比如客户、用户、员工、合同、物资、策划、设备、地址等等，这样让老板有更感性的认识。再次，即使老板当时已经大致理解了主数据的概念，也许仍然不够，因为孤零零的一个没有任何联系的新概念很容易被忘掉，下次老板碰到你还会问，而让别人理解一个概念最好的方法就是能够与其已有的知识体系联系起来，让其感到既熟悉又意外。我们都知道，主数据是一种数据类型，按照《华为数据之道》和《

作者介绍经海路@薄荷点点京东物流数据PM一枚。专注“BI+”，带你发现数据产品的更多可能性。最近这段时间根据Gartner相关报告中涉及到了BI系统、数据分析的技术趋势，进行了一些归纳总结，对于某些趋势点，特意去找了现存的BI产品，让我们脚踏实地的脑洞一下吧！1分析时刻分析时刻是Gartner定义的一种数据分析流程，通过对数据进行可视化、探索和应用算法，支持业务成果的交付，从而做出更好或更快的决策，实现业务流程的自动化。随着数据使用门槛逐步降低，自助式、平台式BI成为趋势，数据分析的主动权会逐步转移到业务人员手中，数据分析直接由遇到业务问题的业务人员发起，业务人员可以使用数据分析工具/平台完成数据分析内容。举例：当一名业务人员想知道某个商品的线上销售预测，或者为什么购物车中的商品没有被某些客户转化为购买，在过去，这名业务人员必须求助于IT部门的专业数据分析师（提取可能相关的数据，输出特定分析报告）、数据科学家（建立预测模型），但是试想一下，如果BI系统中建立了常用的预测算法模型、归因分析工具，可以方便的连接数据集，业务人员自主快速完成分析内容，他通过自助分析很快就知道了这几个数据结论或者问题原因，从而做出业务上的反馈。2增强分析增强分析主要是指以机器学习为基础的数据分析和BI功能，通过机器学习、人工智能等技术的应用将常见通用的数据分析的场景沉淀为产品功能中，帮助普通用户在没有数据科学专家或

00导言在企业内部运营中，各业务部门如果想获取数据，除了找IT部门的“表哥表姐”们“导表儿”，还有其他两大数据获取方式：一是从各业务系统如ERP自带的报表模块（后续简称“报表模块”）看数。业务人员登陆业务系统，可以在“报表模块”看到数据明细和统计汇总结果，系统功能包括多维查询、报表导出，有的还附加类似“驾驶舱仪表盘”的展示。(图1-2)二是基于数据仓库的专业BI用数。经过BI平台授权后，业务人员和管理者，可以在BI平台中看到多业务数据的统计结果、直观的图表等。BI通常还附带自助分析的功能(图3)。常见的BI产品如Power

大鱼先生点击左下角“阅读原文”查看更多精彩文章，后台回复【加群】申请加入万人数据学习社群🧐分享、点赞、在看，给个3连击呗！👇

本文是一篇数据湖的面试题，同时也是数据湖知识点的讲解！本文目录：一、什么是数据湖二、数据湖的发展三、数据湖有哪些优势四、数据湖应该具备哪些能力五、数据湖的实现遇到了哪些问题六、数据湖与数据仓库的区别七、为什么要做数据湖？区别在于？八、数据湖挑战九、湖仓一体十、目前有哪些开源数据湖组件十一、三大数据湖组件对比一、什么是数据湖数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。用架构图能很快说明白，用阿里的数据架构图来说:ODS（operational

的首页显然承接了更多消费以外的需求，如商业化、签到、游戏场景等。究其原因，平台在不影响现有消费导向用户的体验的前提下（搜索作为主入口），满足更多特定群体用户的偏好需求，以提升[活跃用户规模

数据成为生产要素后，各种跟数据相关的概念就出来了，其实很多概念没有权威定义，大家各有各的理解，这导致了理解上的歧义。数据管理、数据治理、数据资源管理、数据资产管理这四个概念现在出现的频次很高，但我仍然无法有效区隔，连续看了几位老师的解释文章后，虽然有所领悟，但还是觉得有不清晰的地方，于是有了这篇辨析的文章，不一定准确，但至少体现了我当前的认知水平。1、数据、数据资源及数据资产的定义数据：指“原始数据”，即记录事实的结果，用来描述事实的未经加工的素材数据资源：指加工后具有经济价值的数据，注意这个有价值是未来时，需要人工判断数据资产：指可控制有价值的数据2、数据、数据资源及数据资产的区别数据在某个地方，但你不知道在哪里，那这个数据对你来说不能叫数据资源；数据你知道在哪里，但加工了也毫无用处，那也不叫数据资源；你知道某个数据有潜在价值但还没去加工，那最多也就是数据资源。数据资源加工后产生经济利益的数据叫数据资产，数据有没有资产属性并不是由其本身决定的，而是由市场决定的。举例如下：CRM系统建设完成后会有很多数据，这些数据就是原始数据，业务人员对这些原始数据进行价值判断，发现一些配置数据没有有效用途，一些行为日志可以用来完善客户画像，那么这些行为日志就成了数据资源，这些行为日志被采集进数据仓库，加工后可以为营销服务，这些加工后的数据就可以认定为数据资产。3、数据管理与数据治理的区别狭义来讲，数据管理是具体日常活动，数据治理是活动的权力控制，一般目的性较强，大多指组织机制流程文化等等。数据管理要做的更好，离不开数据治理的保障，数据治理要保障的好，离不开数据管理活动的输入，数据管理水平达到一定阶段的企业，数据治理的必要性很大。古代开国皇帝打天下主要靠管理，但想开创盛世多靠治理，商鞅变法，王安石变法啥的，全是在建章立制。自己也是活生生的例子，先做数据仓库，再搞数据产品，现在从事数据治理。4、数据管理和数据资源管理的区别看到这俩葫芦娃真是两眼一抹黑，但我通过拆字还是探到了一些奥妙，我是这么理解的：数据资源管理的目的是让数据本身获得更高价值，让自己成功，通过自己的成功再让别人成功；而数据管理的目的只是希望基于数据把应用跑起来，一般是为了让别人获得成功而去做的，正如DBA干的事情，至于最后数据本身价值有没有提升不是关键。数据资源管理现在地位提得这么高，是因为数据让自己变得成功后，其它人会因为数据的成功而更成功，也就是具有倍增效应，这是数据资源独有的特性。5、数据资产管理和数据资源管理的区别数据资产管理和数据资源管理会傻傻的分不清，但大家要注意，数据资产管理的起点是数据资产，终点是数据资产，而数据资源管理的起点是数据资源，终点是数据资产，当把数据资源加工成数据资产后，数据资源管理就退出了舞台，下一棒是数据资产管理的事情了。比如打造源端系统的数据目录，这是数据资源管理的范畴，数据资源入湖后成为数据资产，对数据资产的加工处理就属于数据资产管理的范畴，但数据资源管理跟数据资产管理采用的手段可能是类似的，都有元数据管理、数据质量管理，数据标准管理等等。当然数据资产管理除了数据资产本身的加工外，还包括数据资产的流通、评估及运营等内容。当一个概念没有权威定义的时候，我所采用的办法就是拆解出通用词汇后去理解本质，然后尝试绕回来，正如资源、资产、治理、管理等等，否则就真的扯不清了。当初提出这些新词的人，也许自己都没仔细琢磨过，本来也没啥，但如果所有人都要引用，就要统一下认知，否则就乱了，反正我看到这些词是蛮慌的。数据架构建设方法及案例

大家好，【大鱼的数据人生】的文章涉及数据职场、数据分析、数据管理、应用产品等10个方面，其中蓝字标题的文章为大鱼先生的原创，其他为精选文章，【大鱼的数据人生】后台回复“加群”入专业学习微信群。更新时间：202204151、最新文章2万字详解数据仓库数据指标数据治理体系建设方法论125页PPT看完《华为数据之道》网易数帆数据生产力方法论关于数仓建设及数据治理的超全概括ClickHouse在网易的实践关于未来数据开发技术方向的观点数据架构建设方法及案例

指标体系生命周期生命周期主要包含定义、生产、消费、下线四个阶段。针对整个生命周期要持续做指标运维、质量保障，同时为了提高指标数据复用度，降低用户使用成本需要做对应的数据运营工作。3.

随着数字化转型的深入开展，数据成为新的生产要素。对于非数字原生企业，数据治理的重要性越来越突出。如何有效地开展数据治理工作、提升数据质量、打破数据孤岛、充分发挥数据的业务价值，成了业界的热门话题。《华为数据之道》基于华为数据治理的历程，介绍了华为数据工作的愿景、整体思路框架，阐述了企业级数据综合治理体系和方法论，回顾了华为数据底座的建设过程，总结了华为数据治理和数字化转型的经验。《华为数据之道》对华为公司多年数据治理和数据消费变革历程进行了系统性总结，从治理体系、架构方法、流程规范、IT工具、数据组织等多方面总结了企业在数据治理中面临的挑战及其解决方案，并介绍了一些华为独有的创新成果，如数据底座、数据湖、主题联接、数据地图、数据生态等。以下读书笔记来自CIO之家，对全书内容做了细致的研究和归纳总结，便于大家对数据治理进行体系化思考，推荐给大家。（PPT较长，建议收藏）数据架构建设方法及案例