数据建模

1. 为什么说数据建模已死？近日，Substack.com 上一篇名为 The Death of Data Modeling（数据建模之死）的博客引起了行业热议，许多数据从业者发现已经经典的数据建模流程可能已不再符合企业当下的数据分析需要。 本文将具体论述为什么说数据建模已死，并剖析以后数据建模存在的痛点和挑战，最初介绍数据建模 2.0 计划将如何帮忙企业真正实现自助式数据分析，心愿对大家有所启发。 1. 1 数据指标有歧义，口径对不齐 数据建模的外围性能是把数据组织成更容易被业务用户应用的模式，其中一部分流程是将业务用户须要应用的指标固化在模型中。但现实情况是因为数据模型的凌乱，业务用户拿到的数据指标有歧义、口径对不齐，难以达到预期的作用。 假如企业应用了一个中等规模以上的 BI 或者是数据仓库的技术栈，每次需要都独自创立 ETL 工作和聚合表，就会导致数仓中有大量的聚合表，对应也就须要创立成千盈百张报表；每张报表如果有十个以上的指标，那就意味着有几万甚至几十万的业务指标。这些口径是否对立？这些数据是否被人应用？这些问题都值得咱们去思考。 1.2 数据交付流程时效性差，开发成本高 对于分析师而言，传统围绕数据模型的数据交付流程时效性差，只能用加工好的已知数据进行剖析，但不能就未知数据给出洞察，难以满足当今的业务需要；而对于工程师来讲，反复开发工作多，老本还居高不下，工作成就感低。 传统的围绕数据模型的交付模式，通常须要通过需要提出、需要廓清、数据探源、数据开发、再到创立仪表盘、UAT 验收等一系列开发环节，这样的数据交付上线工夫通常须要 12 天。 此外，因为数据工程团队通常须要集中服务多个团队，往往不足对数据模型背地业务的了解，也短少短缺人力去继续跟进一直变动的业务需要。这就导致围绕数据模型的开发交付周期长，还须要业务和数据工程团队的深度染指才可能实现数据需要的上线。 1.3 业务人员数据分析被动 业务人员常常在须要应用数据的关键时刻，面临不晓得在哪里获取数据、甚至没数据可用的困境，在工作中处于被动状态。 随着越来越多数据模型表的产生，没有通过治理的数据模型存在着大量的数据工作和聚合表，数据的消费者很快就不晓得在数据仓库中应该应用哪些数据来答复业务问题了，本应供大家获取数据价值的数据模型沦为了只有多数专家数据工程师能力拜访探查的“数据沼泽”。 起源：https://dataedo.com/cartoon/d... 例如，一家应用私有云搭建 IT 基础设施的公司，其管理层每月会定期审核云老本数据报表，查看公司内各个我的项目在多家私有云平台上的生产是否超出预算，并制订下一步云上费用的投入打算。然而每次管理层审核时，都只能从现有报表中找问题，却无奈剖析出背地深层次的起因。因而，只能提出对报表的修改意见，问题会遗留到下次审核，再到下下次审核，如此周而复始...... 那么，当管理层看到我的项目 A 占用云老本过高，下一步应该减少投入还是要求项目组缩减开销呢？因为短少更具体的数据撑持，管理层难以疾速决策，只能会后解决，并要求下次散会时在报表增加项目组云资源应用的更多数据后果。 2. 现实中的数据建模面临这些挑战，咱们勾划出了数据建模现实中的样子。咱们心愿数据建模能够真正成为数据赋能业务的基石，实现数据分析平民化，那么“现实中的数据建模”应是怎么的呢？ 工程师把模型建好，业务就能自助应用，同时数据工程团队能够对立管控，保证数据口径的一致性；数据工程团队能够更加敏捷地交付业务需要，而不须要通过一个漫长的需要沟通流程；业务人员可自助应用数据，无需适度依赖工程师，整个数据建模过程就能失去无效的治理。数据建模真的死了吗？ 数据建模真的死了吗？事实上，数据建模仍旧存在且有其价值，企业的数据平台建设仍离不开好的数据建模。咱们认为“死掉”的是凌乱无序的传统数据建模，企业真正须要的是可能均衡集中的数据治理和麻利的自助式剖析的数据建模 2.0。 应用对立的模型作为宽表和指标的“收纳箱” 在经典数仓的实践中，大家经常应用雪花模型来刻画业务过程及其关联维度，咱们能够借助雪花模型对各个数据域、各个业务过程进行严格的建模。并且能够起到“数据模型收纳箱” “指标收纳箱”的作用： 雷同数据域、雷同业务过程的数据模型表，归属到同一个雪花模型之中，同一个模型负责不同数据模型表的计算、存储、迭代；所有的业务指标归属到惟一确定的模型；模型能够在指标开发的过程中被主动举荐生成，然而须要失去管理员审批同意，避免因模型的适度开发造成的凌乱。 每当用户须要创立新的指标时，能够依据图形界面的疏导，优先选择复用已有模型，或是定义新模型，零碎会在其欠缺模型定义的过程中一直辨认和举荐能够复用的模型。这就实现了模型层面的重复性检查和复用，遏制了数据聚合表的无序成长。 在这里，咱们能够看到这样的模型层就像一个“收纳箱”，能够无效地排汇、组织、去重本来须要数以千计的、零散的数据建模表层表。在资源层面，模型能够组织数据主题之间的血缘关系。在治理层面，模型层的呈现大大降低了指标平台底层的数仓表的数量，显著升高了治理的复杂度。 利用指标驱动业务需要向数据模型的积淀 在数据建模 2.0 的模式中，数据建模的过程仍始于维度表和事实表。在两头咱们会构建一些数据集市，供下层利用去应用。数据工程团队治理好了原子指标之后，业务人员就能够基于这些原子指标一直地去创立、衍生所需的业务指标。通过一直创立衍生业务指标，业务人员其实就自主实现了业务逻辑向数据模型的积淀。 在这个过程中，数据工程团队也能够通过推动指标治理来做到更好的数据治理。因为只有指标被应用、被生产，数据能力施展更大的价值。基于数据模型的指标中台能够帮忙企业治理口径的标准，比方反复的指标、异动的指标，还有一些异样的空值散布等。通过在指标层面上的利用，数据工程团队能够更有针对性地帮忙业务用户去治理指标背地的数据，做到对症下药。 新的数据建模形式将高效赋能业务人员进行自助数据分析，业务人员能够复用根底指标去自行创立并剖析衍生指标，而无需数据工程团队的染指。数据工程团队只须要在有全新根底指标的开发需要时，参加需要剖析和指标的开发，这样通过指标驱动业务反向将需要积淀到数据模型的形式。在 Kyligence 实在的客户案例中，数据交付工夫可从过来的 12 天缩短到 0 天 （对于剖析可复用根底指标的衍生指标）和 5 天 （对于须要新创建根底指标的场景）。 ...

一、数据建模的定义 数据建模指的是对事实世界各类数据的形象组织，确定数据库需管辖的范畴、数据的组织模式等直至转化成事实的数据库。 将通过系统分析后形象进去的概念模型转化为物理模型后，在visio或erwin等工具建设数据库实体以及各实体之间关系的过程（实体个别是表）。 二、数据建模的根本流程 1、确定数据及其相干过程，如实地销售人员须要查看在线产品目录并提交新客户订单。 2、定义数据，如数据类型、大小和默认值。 3、确保数据的完整性，应用业务规定和验证查看。 4、定义操作过程，如安全检查和备份。 5、抉择数据存储技术，如关系、分层或索引存储技术。 6、肯定要晓得建模通常会以意想不到的形式波及公司的治理。例如，当对哪些数据元素应由哪些组织来保护有新的见解时，数据所有权以及数据保护、准确性和及时性的隐含责任通常会受到质疑。数据设计经常促使公司意识到企业数据系统是如何相互依存的，并且激励公司抓住协调后的数据布局所带来的效率进步、老本节约和战略性时机。 三、数据建模的类型 1、ER模型OLAP中的ER模型，与OLTP中的有所区别。其本质差别是站在企业角度面向主题的形象，而不是针对某个具体业务流程的实体对象关系的形象。 2、星型模型星型模型，是维度模型在关系型数据库上的一种实现。该模型表示每个业务过程蕴含事实表，事实表存储事件的数值化度量，围绕事实表的多个维度表，维度表蕴含事件产生时理论存在的文本环境。这种相似于星状的构造通常称为"星型连贯"。其重点关注用户如何更疾速地实现需要剖析，同时具备较好的大规模简单查问的响应性能。在星型模型根底上，在简单场景下还能够进一步衍生出雪花模型。 3、多维模型多维模型，是维度模型的另一种实现。当数据被加载到OLAP多维数据库时，对这些数据的存储的索引，采纳了为维度数据波及的格局和技术。性能汇集或预计算汇总表通常由多维数据库引擎建设并治理。因为采纳预计算、索引策略和其余优化办法，多维数据库可实现高性能查问。 四、数据建模案例 1、Smartbi大数据挖掘平台算法丰盛，而且可扩大 数据挖掘平台反对多种高效实用的机器学习算法，蕴含了分类、回归、聚类、预测、关联，5大类机器学习的成熟算法。其中蕴含了多种可训练的模型：逻辑回归、决策树、随 机森林、奢侈贝叶斯、反对向量机、线性回归、K均值、DBSCAN、高斯混合模型。除提供次要算法和建模性能外，数据挖掘平台还提供了必不可少的数据预处理性能，包含字段拆分、行过滤与映射、列抉择、随机采样、过滤空值、合并列、合并行、JOIN、行抉择、去除反复值、排序、减少序列号、减少计算字段等。 2、Smartbi 大数据挖掘平台性能齐备，无缝集成到企业BI利用 1）适宜大型企业 分布式云计算，线性扩大，保障性能，与BI平台无缝整合，一键公布开掘模型，模型库进步常识复用，缩小反复投入，反对跨库查问，对立控制数据拜访权限，训练自动化、模型自学习。 2）适宜普通用户 直观的流式建模，极简格调的节点配置界面，反对可视化摸索，轻松了解数据品质和数据并联，流程节点在线帮忙，模型超参数主动调整。 3）业余算法能力 内置５大类机器学习成熟算法，反对文本剖析解决，反对应用Python扩大开掘算法， 反对应用SQL扩大数据处理能力。 三、Smartbi大数据挖掘平台易学易用，一站式实现数据处理和建模

在过来的几十年里，数据建模的致力通常集中在关系数据建模或可扩大标记语言(XML)的建模上。只有数据存储在关系数据库中，关系数据建模就会很好，但除此之外，它很少会有其余的用处。大数据建模是一个数据挖掘的过程，就是从数据之中发现问题，解释这些问题，建设相应的数据模型，能够通过预测发明新的决策参考，对于数据建模有不同的平台以及不同的工具，这个过程中也是有相应的规范，能够大大提高大数据建模的成功率。想要做好数据建模也并非难事。但前提是必须恪守好这五大准则，不愁做不好大数据建模。 准则一：以业务指标作为实现目标 大数据建模不只是一个技术，而是一个为了解决业务流程的问题的过程，如果没有指标或者说不是以解决业务方面的问题作为指标，那么就没有大数据建模。 准则二：理解业务知识 从大数据建模开始到完结，并且要基于理解业务知识的商业了解的根底上，晓得这些相干的数据与业务问题有什么的关系，是怎么相干起来的，到最初的塑造阶段，也是要利用业务知识来进行模型塑造，建设起来的大数据模型要通过业务问题的发问和解答。 准则三：做好数据预处理 做大数据建模，不仅仅是建模这一个动作，整个过程的多个环节都是很重要的，在大数据建模的过程中，找到适合的数据源才是重点，对于数据源进行预处理则是难点，数据预处理是艰难，尽管说当初曾经有很多的自动化的数据处理工具能够被应用，然而这些剖析工具以及各种分析方法也是通过了很长的一段摸索工夫。做大数据建模的时候，在数据预处理阶段不能焦急，要找到适合数据预处理的分析方法。 准则四：重视数据原有的模式 在进行大数据建模的时候重视一些数据原有的模式，例如在进行客户购买行为剖析过程中，可客户之后的购买预测可能和之前的购买行为有关系，当然这个过程和操作者的教训有很大的相关性，特地是在理解一开始的业务知识之后，可能对于这种原有的模式会有更好的了解。 准则五：大数据建模的价值不在于预测的准确率 一个模型建设起来了，很多人会按照这个模型进行各种预测，如果预测的精确，就阐明模型是好的模型，是有价值的，实际上这个不能作为判断价值的规范，一个好的大数据模型是为了扭转企业的行为以及以预测的后果来改善企业的行为，传递新的常识和见解，以及会不会适应业务的倒退的须要才是它的掂量尺标。 想要全面意识大数据建模，能够到Smartbi理解体验。Smartbi Mining通过深度数据建模，为企业提供预测能力反对文本剖析、五大类算法和数据预处理，并为用户提供一站式的流程式建模、拖拽式操作和可视化配置体验。Smartbi Mining不仅可为用户提供直观的流式建模、拖拽式操作和流程化、可视化的建模界面，还提供了大量的数据预处理操作。此外，它基于Smartbi对企业客户的长期教训，提供了大量实用的企业级平台个性。

简介：数据建模是数据标准化的核心内容，企业在搭建本人的数据平台时须要先建设适宜公司业务的数据模型。好的数据模型能够帮忙企业构建正当的数据根底构造，帮忙企业少走弯路，节俭长期开发成本。 本次阿里云DataWorks数据建模公开课邀请到Datablau创始人&CEO王琤老师为大家带来数据建模系列讲座，内容涵盖数据建模基本知识和企业级规范、架构与模型设计，以及阿里云DataWorks数据中台模型治理平台解决方案。数据建模是数据标准化的核心内容，企业在搭建本人的数据平台时须要先建设适宜公司业务的数据模型。好的数据模型能够帮忙企业构建正当的数据根底构造，帮忙企业少走弯路，节俭长期开发成本。 本次阿里云DataWorks数据建模公开课邀请到Datablau创始人&CEO王琤老师为大家带来数据建模系列讲座，内容涵盖数据建模基本知识和企业级规范、架构与模型设计，以及阿里云DataWorks数据中台模型治理平台解决方案。 DataWorks数据建模凋谢7天收费试用，申请试用请钉钉扫码分割@墨祤 本次公开课已圆满结束，直播回放内容如下： DataWorks数据建模公开课Part01 - 数据建模基础知识视频地址： http://cloud.video.taobao.com/play/u/1529307/p/1/e/6/t/1/300212292217.mp4 DataWorks数据建模公开课Part02 - 数据建模方法论&范式视频地址：http://cloud.video.taobao.com/play/u/1529307/p/1/e/6/t/1/300857810155.mp4 DataWorks数据建模公开课Part03 - DDM建模上手教程视频地址：http://cloud.video.taobao.com/play/u/1529307/p/1/e/6/t/1/300557169372.mp4 DataWorks数据建模公开课Part04 - DDM建模深度性能实操解说视频地址：http://cloud.video.taobao.com/play/u/1529307/p/1/e/6/t/1/301170335077.mp4 DataWorks数据建模公开课Part05 - 数据规范与数据模型管控视频地址：http://cloud.video.taobao.com/play/u/1529307/p/1/e/6/t/1/301181167701.mp4 以上是本次DataWorks数据建模公开课的全部内容，感兴趣的同学能够钉钉扫码分割@墨祤 申请试用 应用过程中有任何问题能够钉钉扫码退出DataWorks数据建模钉钉群探讨： 舒适揭示如您须要全面理解DataWorks数据建模（DDM）请点击：产品介绍视频、产品帮忙文档 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

前言事实表次要分为事务事实表与周期快照事实表，累计快照事实表。然而它们在形容业务事实方面是有着十分大的差别的。 1.事务事实表（Transaction fact table）保留的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件产生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新形式为增量更新。 事务事实表的日期维度记录的是事实产生日期，它记录的事实是事务流动的内容。用户能够通过事务事实表对事务行为进行特地具体的剖析。 通过事务事实表，还能够建设汇集事实表，为用户提供高性能的剖析。 举例： 比方，地产行业外面的排卡，订购，签约，回款这些都是一个特定的业务动作。蕴含有具体业务的产生工夫，以及业务产生时的相干渠道，组织，人力，产品以及客户。这样在kimball外面咱们对维度进行抽离不落入事实表外面。这个造成了一个典型的star模型。两头的事实表就是一个交易事实表也称为事务事实记录表。2.周期快照事实表（Periodic snapshot fact table）周期快照事实表以具备规律性的，可预感的工夫距离来记录事实，工夫距离如每天，每月，每年等等。典型的例子如销售日快照表，库存日快照表等。 周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建设的汇集表。周期快照事实表的维度个数比事务事实表要少，然而记录的事实要比事务事实表多。 周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些汇集事实值。事实表的数据一旦插入即不能更改，其更新形式为增量更新。 举例： 如生产制作企业外面的产品仓库存储。某工厂每天生产的plm件都会进行寰球发货。仓库每天会定时进行数据快照，用以统计目前仓库的货物存量记录。该类表可称之为周期快照事实表，次要标记事务在固定周期的变动。工夫为数据快照周期。3.累计快照事实表（Accumulating snapshpt fact table）累计快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。然而它们之间也有着很大的不同，周期快照事实表记录的确定的周期数据。而累计快照事实表记录的不确定的周期数据。 累计快照事实表代表的是齐全笼罩一个事务或产品的生命周期的时间跨度，它通常具备多个日期字段，用来记录整个生命周期中的要害工夫点。另外，它还会有一个用于批示最初更新工夫的附加日期字段。因为事实表中许多日期在首次加载时是不晓得的，所以必须应用代理关键字来解决未定义的日期，而且这类事实表在数据加载完后，是能够对它进行更新的，来补充随后晓得的日期信息。 举例： 电商类网购，在客户实现购物业务动作之后会产生一条订购单，同时也会生成一条快递跟踪信息。快递动静跟踪信息表记录的模式就是累计快照事实表。次要记录事务在次要里程碑节点的状态变动，用于事务的全生命周期治理。

在《利用历史数据做商业预测的全过程》(以下简称前文) 一文中咱们介绍了如何应用历史数据进行商业预测的过程。不同的商业需要，还会有些各自的特殊性。例如，在很多业务场景中，存在一种数据不均衡的景象，比方银行贷款守约，守约的人只是很小一部分人；保险欺诈，欺诈者也是个别现象；还有产品质量中不良品的比例、工业生产中非打算停车景象……。这些常见景象的产生比率很低，但一旦产生就会产生较大的损失，所以要尽量能预测进去并防止。本文将介绍如何来预测这些常见产生的景象。 1\. 筹备历史数据 数据筹备的过程如前文所述，然而对于这种须要预测常见景象的场景，就要思考数据不均衡的问题。咱们把历史数据中产生过常见景象的记录称为阳性样本，数据不均衡就是指阳性样本在总数据中过于稀少。这时，即便总数据量很多也很难建出无效模型。因而，在筹备数据时就要尽量多提取阳性样本，具体多少并没有固定要求。一般来讲，问题越简单，须要的数量就越多，不过即便很简略的问题通常至多也须要几百条阳性样本才可能建出可用模型。反之，也不能只取阳性样本。例如，要建模预测贷款用户的守约状况，要保障守约客户的数据达到肯定数量，但也不能全部都是守约客户的数据，失常客户的数据也要采集。 2\. 建设模型 按前文所述即可。对于不均衡的的数据集，YModel 会主动进行抽样来使阳性样本和阴性样本（即失常的样本）的比例达到均衡，使用者不必本人操作。然而咱们能够本人批改和设置须要的配平比例，如下图，对于初学者通常倡议采取默认的比例就好。 3\. 预测 通过前两步的解决后，建设进去的模型就能够实现预测了，同样是依照预测的概率从高到低排序，找后面概率较高的客户或样本来重点排查就能够了。排在后面的样本产生常见景象的可能性更大。 4.Recall 查全率指标 在数据分布不均衡的场景中，只看预测的准确率是没有意义的，对咱们更有意义的是 Recall 查全率。查全率示意在所有的阳性样本，有多少被正确的预测了。举个夸大点的例子，机场辨认恐怖分子，在 100 万人里只有 5 个恐怖分子，因为恐怖分子是极少数，如果应用准确率来评估模型的话，那只有把所有人都辨认成正常人，其准确率能够达到 99.9995%，但显然没什么意义，一个恐怖分子都没有抓到，也就是说这个模型尽管准确率很高然而查全率为 0/5=0。反之，另一个模型预测出 100 集体为高风险人群，5 个恐怖分子都就蕴含在这 100 人里，这时候准确率降为 99.9905%（有 95 人预测谬误），但查全率为 5/5=1，恐怖分子都能抓到了。这样的模型就是更有意义的。 在 YModel 中咱们会用 Recall 曲线来判断查全率，如下图，横坐标示意将产生常见景象的预测概率依照从高到低排序取数，10，20……别离示意概率排名前 10%，20%……的样本，纵坐标示意在各排名阶段对应的查全率值。图中横坐标 10 对应的查全率约为 0.75，示意在预测概率排名前 10% 的数据中，能捕捉 75% 的常见景象，也就是说相比于全副排查，咱们用 10% 的工作量就能找到 75% 的常见（异样）状况。Recall 曲线越凑近左上角示意模型的捕捉常见景象（守约、欺诈、不良品、设施异样……）能力越强。

咱们在《利用历史数据做商业预测的全过程》(以下简称前文) 一文中介绍了如何应用历史数据进行商业预测的过程。不同的商业需要，还会有些各自的特殊性，本文将介绍如何应用预测技术来晋升营销成功率。 1. 筹备历史数据 在营销场景中，要预测的指标是客户的购买行为，须要收集一些可能会影响购买行为的信息字段，比方客户的年龄、学历、工作、支出、家庭构造、生活习惯、购物偏好，以及产品的特点、促销力度等信息，收集到的相干信息越多，预测成果也会越好。 另外，咱们还能够依据业务特点，分地区、分客群进行预测，比方纽约的房价和中南部城市的房价齐全不一样。再比方，汽车的销售，男性客户通常会关注性能，女性客户则更关注外观，还有高端客户和中低端客户的需要特点也会天壤之别。很多时候辨别客户群体的剖析预测，要比整体间接预测成果要更好，更有针对性。 如果是分地区、分客群的预测，那么对应的宽表也要多筹备几张，比方分 3 个客群，宽表就要对应筹备 3 张。 2. 建设模型 按前文所述即可，如果有多个客群，那就须要建设多个模型。 3. 预测客户购买清单 用前文的办法，能够实现预测，而后依照预测的概率后果从高到低排序，找后面概率较高的顾客来进行营销流动就能够了。排在后面的顾客的营销成功率更高。 4. Lift 指数 营销场景中，除了用通用的 AUC 指标来看准确率之外，还有一个很实用的评估办法称为 Lift 曲线。Lift 示意晋升指数，它的值为应用和不应用预测模型取得的后果之间的比率。如下图所示。 横坐标示意将预测概率从高到底排序取数，10，20……别离示意概率排名前 10%，20%……的客户，纵坐标示意在排名阶段对应的晋升指数。例如某种产品它的基准购买率为 1.5%，也就是说不采纳模型的传统营销，均匀每 100 集体里会有 1.5 集体会购买该产品。而后建设模型后，通过图中的 Lift 曲线可知，排名前 5% 的数据晋升度为 14.4，即均匀在 100 人里会有 1.5*14.4=21.5 集体购买产品。也就是说对概率排名前 5% 的客户进行营销，要比传统营销，成功率可进步 14.4 倍。随着横坐标用户百分比的减少，lift 值呈递加趋势，对应客户的含金量也在升高，当升高到某个段就没太大营销的意义了。例如图中对于排名约前 15% 的客户来说，lift 值都大于 1，也就是说对前 15% 的客户进行营销，成功率要高于随机抉择客户。咱们能够依据这个 Lift 曲线来决定抉择概率排名前多少比例的客户去做营销。Lift 曲线越陡，阐明模型筛选优质客户的能力越好，如图中的 Lift 曲线就是一个还不错的模型，可能帮忙咱们更无效的找到指标客户，以最低的老本找到最容易成交的客户。 5. 多产品组合购买清单 如果销售产品只有一种或少数几种，到步骤 4 就实现了。 如果销售产品种类很多，比方十几种，甚至上百种，还能够通过开掘客户的兴趣爱好，向其举荐产品组合，来进一步提高营销成功率和营销价值。比方，银行会有几十种金融产品须要营销，家电公司会有各种家电产品须要销售，超市或电商须要售卖的产品多种多样，保险公司有各种不同品种的保险须要营销……。 ...

作者 | 傅一平 来源 | 与数据同行今天跟着我来学学数据仓库的基础知识，希望你结合案例可以把它吃透。 一、数据仓库建模的意义如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。 数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。 只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。 性能：帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高使用数据的效率，如宽表。 成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。 效率：在业务或系统发生变化时，可以保持稳定或很容易扩展，提高数据稳定性和连续性。 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。 大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！ 下图是个示例，通过统一数据模型，屏蔽数据源变化对业务的影响，保证业务的稳定，表述了数据仓库模型的一种价值： 二、数据仓库分层的设计为了实现以上的目的，数据仓库一般要进行分层的设计，其能带来五大好处： 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。 数据血缘追踪：能够快速准确地定位到问题，并清楚它的危害范围。 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。 把复杂问题简单化：将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复。 屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。 以下是我们的一种分层设计方法，数据缓冲区（ODS）的数据结构与源系统完全一致。基础数据模型(DWD)和融合数据模型（DWI与DWA）是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设，其中基础数据模型一般采用ER模型，融合数据模型采用维度建模思路。 三、两种经典的数据仓库建模方法前面的分层设计中你会发现有两种设计方法，关系建模和维度建模，下面分别简单介绍其特点和适用场景。 1、维度建模 （1）定义 维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。 典型的代表是我们比较熟知的星形模型： <figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">维度退化</figcaption> 星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。 这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。 （2）建模方法 通常需要选择某个业务过程，然后围绕该过程建立模型，其一般采用自底向上的方法，从明确关键业务过程开始，再到明确粒度，再到明确维度，最后明确事实，非常简单易懂。 以下是阿里的OneData的建模工作流，可以参考。 （3）优缺点 优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能 缺点：维度表的冗余会较多，视野狭窄 2、关系建模 （1）定义 是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。 它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。 ...

敏捷之歌我抽数故我存在 | DBus 人人玩转流处理 | Wormhole 就当吾是数据库 | Moonbox 颜值最后十公里 | Davinci 导读：实时数据平台（RTDP，Real-time Data Platform）是一个重要且常见的大数据基础设施平台。在上篇（设计篇）中，我们从现代数仓架构角度和典型数据处理角度介绍了RTDP，并探讨了RTDP的整体设计架构。本文作为下篇（技术篇），则是从技术角度入手，介绍RTDP的技术选型和相关组件，探讨适用不同应用场景的相关模式。RTDP的敏捷之路就此展开~ 拓展阅读：以企业级实时数据平台为例，了解何为敏捷大数据 如何设计实时数据平台（设计篇） 一、技术选型介绍在设计篇中，我们给出了RTDP的一个整体架构设计（图1）。在技术篇里，我们则会推荐整体技术组件选型；对每个技术组件做出简单介绍，尤其对我们抽象并实现的四个技术平台（统一数据采集平台、统一流式处理平台、统一计算服务平台、统一数据可视化平台）着重介绍设计思路；对Pipeline端到端切面话题进行探讨，包括功能整合、数据管理、数据安全等。 图1 RTDP架构 1.1 整体技术选型 图2 整体技术选型 首先，我们简要解读一下图2： 数据源、客户端，列举了大多数数据应用项目的常用数据源类型。数据总线平台DBus，作为统一数据采集平台，负责对接各种数据源。DBus将数据以增量或全量方式抽取出来，并进行一些常规数据处理，最后将处理后的消息发布在Kafka上。分布式消息系统Kafka，以分布式、高可用、高吞吐、可发布-订阅等能力，连接消息的生产者和消费者。流式处理平台Wormhole，作为统一流式处理平台，负责流上处理和对接各种数据目标存储。Wormhole从Kafka消费消息，支持流上配置SQL方式实现流上数据处理逻辑，并支持配置化方式将数据以最终一致性（幂等）效果落入不同数据目标存储（Sink）中。在数据计算存储层，RTDP架构选择开放技术组件选型，用户可以根据实际数据特性、计算模式、访问模式、数据量等信息选择合适的存储，解决具体数据项目问题。RTDP还支持同时选择多个不同数据存储，从而更灵活的支持不同项目需求。计算服务平台Moonbox，作为统一计算服务平台，对异构数据存储端负责整合、计算下推优化、异构数据存储混算等（数据虚拟化技术），对数据展示和交互端负责收口统一元数据查询、统一数据计算和下发、统一数据查询语言（SQL）、统一数据服务接口等。可视应用平台Davinci，作为统一数据可视化平台，以配置化方式支持各种数据可视化和交互需求，并可以整合其他数据应用以提供数据可视化部分需求解决方案，另外还支持不同数据从业人员在平台上协作完成各项日常数据应用。其他数据终端消费系统如数据开发平台Zeppelin、数据算法平台Jupyter等在本文不做介绍。切面话题如数据管理、数据安全、开发运维、驱动引擎，可以通过对接DBus、Wormhole、Moonbox、Davinci的服务接口进行整合和二次开发，以支持端到端管控和治理需求。下面我们会进一步细化上图涉及到的技术组件和切面话题，介绍技术组件的功能特性，着重讲解我们自研技术组件的设计思想，并对切面话题展开讨论。 1.2 技术组件介绍1.2.1 数据总线平台DBus 图3 RTDP架构之DBus 1.2.1.1 DBus设计思想1）从外部角度看待设计思想 负责对接不同的数据源，实时抽取出增量数据，对于数据库会采用操作日志抽取方式，对于日志类型支持与多种Agent对接。将所有消息以统一的UMS消息格式发布在Kafka上，UMS是一种标准化的自带元数据信息的JSON格式，通过统一UMS实现逻辑消息与物理Kafka Topic解耦，使得同一Topic可以流转多个UMS消息表。支持数据库的全量数据拉取，并且和增量数据统一融合成UMS消息，对下游消费透明无感知。2）从内部角度看待设计思想 基于Storm计算引擎进行数据格式化，确保消息端到端延迟最低。对不同数据源数据进行标准化格式化，生成UMS信息，其中包括：✔ 生成每条消息的唯一单调递增id，对应系统字段ums_id_ ✔ 确认每条消息的事件时间戳（event timestamp），对应系统字段ums_ts_ ✔ 确认每条消息的操作模式（增删改，或insert only），对应系统字段ums_op_ 对数据库表结构变更实时感知并采用版本号进行管理，确保下游消费时明确上游元数据变化。在投放Kafka时确保消息强有序（非绝对有序）和at least once语义。通过心跳表机制确保消息端到端探活感知。1.2.1.2 DBus功能特性支持配置化全量数据拉取支持配置化增量数据拉取支持配置化在线格式化日志支持可视化监控预警支持配置化多租户安全管控支持分表数据汇集成单逻辑表1.2.1.3 DBus技术架构 图4 DBus数据流转架构图 更多DBus技术细节和用户界面，可以参看： GitHub： https://github.com/BriData 1.2.2 分布式消息系统KafkaKafka已经成为事实标准的大数据流式处理分布式消息系统，当然Kafka在不断的扩展和完善，现在也具备了一定的存储能力和流式处理能力。关于Kafka本身的功能和技术已经有很多文章信息可以查阅，本文不再详述Kafka的自身能力。 这里我们具体探讨Kafka上消息元数据管理（Metadata Management）和模式演变（Schema Evolution）的话题。 图5 图片来源：http://cloudurable.com/images...图5显示，在Kafka背后的Confluent公司解决方案中，引入了一个元数据管理组件：Schema Registry。这个组件主要负责管理在Kafka上流转消息的 元数据信息和Topic信息，并提供一系列元数据管理服务。之所以要引入这样一个组件，是为了Kafka的消费方能够了解不同Topic上流转的是哪些数据，以及数据的元数据信息，并进行有效的解析消费。 任何数据流转链路，不管是在什么系统上流转，都会存在这段数据链路的元数据管理问题，Kafka也不例外。Schema Registry是一种中心化的Kafka数据链路元数据管理解决方案，并且基于Schema Registry，Confluent提供了相应的Kafka数据安全机制和模式演变机制。 ...

数据分析是一个检查、清理、转换和数据建模的过程，目的是发现有用的信息、提出结论和支持决策依据。数据建模是数据分析里的一项，数据建模里又有一些常见的套路：选择变量与重构变量、选择算法、设定参数、加载算法和测试结果。 选择变量与重构变量数据分析师在拿到数据时（不管是自己爬取还是数据框里提取的）不是对所有的变量都要进行分析或者纳入到模型里，有许多变量起不到数据“分析”的任务（比如列号，也是数据集里的变量），有的变量跟数据分析师所需要达到的目的没有关系，这就是选择变量的重要性，一般来说选择变量有两个标准：数据逻辑和业务参考。 数据逻辑： 所谓数据逻辑，一般从数据的完整性、集中度和变量相关性（有时候还有考虑因果关系）等角度考虑，一个变量缺失率达到80%，或者一个非布尔值变量但却集中两个值……这些都要考虑加入这些变量后是否对后面的分析有价值。 业务参考： 变量基于收集到的数据，在做目标性的数据分析时会产生与业务产生关联，比如共享单车数据集车轮胎这个变量里，轮胎数不会是1或者3吧，在接下来的建模中，业务知识告诉你是不会选择这个变量的。 选择算法业务数据分析师所要做的就是要用数据分析解决商业问题，而不是为了建立模型而建模，因此要根据业务背景和所要达到的目的选择模型，根据挖掘目标和数据形式可以建立分类与预测、聚类分析、关联规则、时序模式、偏差检测等模型，帮助企业提取数据中隐藏的商业价值，从以前的主观决策转向更科学的数据决策，提高企业的竞争力。下面列举了一些常见的业务背景和对应的常用算法。 划分消费群体：聚类、分类； 满意度调查：回归、聚类、分类； 购物篮分析：相关、聚类； 购买额预测：回归、时间序列； 满意度调查：回归、聚类、分类。 设定参数确定好要用那种模型后，就需要对模型进行调查参数，比如经典的聚类分析里的K均值算法就需要给定K的值（希望聚成的类别数量），参数有时候不是一次就能确定好的，需要多次的调整，达到最优的效果。 加载算法与测试结果模型建立好后需要验证与测试，要根据算法输出结果来确定该算法是否能够解决业务问题，比如聚类算法里除了K均值算法还有系统聚类等，要是K—means的结果不太好就要考虑其他的算法，又或者回归模型输出结果不满足需求，考虑时间序列模型来做；若不需要换算法，还要测试一下输出的结果是否有提示的空间，如聚类分析里的聚类结果有四类，通过可视化发现有两类的特征很相近，区分度不明显，这就造成有很大部分的类处于很模糊的位置，所以就很需要调整参数来优化模型，在不断调参优化模型的过程中，模型的解释性和实用性会得到提升，当模型能够满足业务需求，那就可以输出结果。 这是通常建模的一般流程，而建模只是数据分析里其中一项；流程的熟悉、业务的理解、算法理论及代码的熟练等等都是考验一个数据分析师的能力；最后希望这篇文章能够帮助到你建模时构建一个框架，而不至于在建模时不知道干嘛；在学习的道路上你我共勉！ 【延伸阅读】 CDA数据分析就业班课程是专门为想要从事数据分析类工作所研发的精品课程，该课程包含Excel、Power BI 、Tableau等业务数据分析相关内容以及数据挖掘的数学基础、SPSS软件基础、运用SPSS构建统计模型、Python基础、数据清洗、网络爬虫、Python机器学习等数据挖掘和机器学习相关内容，并结合评分卡、电商、零售等实战项目案例课程，帮助学员迅速掌握业务数据分析、数据挖掘、机器学习相关岗位技能，学员毕业后可推荐相关工作岗位。 更多详细内容信息，可移步：https://www.cda.cn/?seo-SEGME...