数据挖掘如何能跟得上变化？

今天，我将继续讨论阿里巴巴的书籍，包括数据服务平台、数据挖掘平台、数据建模、数据管理和数据应用。我希望你能得到启发。1、数据服务平台数据服务平台可以称为数据开放平台，数据部门生产大量数据，如何方便有效地开放，是我们一直需要解决的问题，在没有数据服务的时代，阿里数据开放简单，粗糙，一般直接导出数据，我认为，现在大多数公司应该开放，虽然PaaS喊了这么多年，但有多少真正的成就？即使像阿里巴巴一样，在数据开放的方向上探索和实践已经7年了。任何关于数据开放的做法都将失败，任何数据开放的改进都将随着对业务的深入了解而成长。阿里的数据开放经历了四个阶段，DWSOA、OpenAPI、SmartDQ和OneService：DWSOA：这是数据服务的第一阶段，即通过SOA服务暴露业务方对数据的需求，由需求驱动，开发一个或多个接口，编写接口文档，并向业务方打开呼叫。这种结构简单，但接口粒度粗，灵活性低，可扩展性差，再利用率低。随着业务需求的增加，接口数量显著增加，维护成本高。同时，开发效率不高。根据阿里巴巴的说法，一个接口至少需要开发一天才能上线。事实上，这远不止于此。如果你想改变1-2个字段，你也应该采取一套完整的流程，这应该是大多数公司的常态。OpenAPI：DWSOA的明显问题是烟囱开发，难以沉淀常见数据，OpenAPI根据统计粒度聚合数据，相同维度的数据，形成逻辑表，使用相同的接口描述，对于某种查询，只需调用一个接口，这种形式可以有效地收敛接口，作者公司的许多外部服务也是这种形式，如通过包装数十个位置服务API，统一外部提供灵活的查询能力，但事实上，复杂的逻辑界面仍然需要一个讨论，即第一种方式。SmartDQ：数据维度是不可控的。随着数据的深入使用，OpenAPI显然会急剧增加，维护映射的压力会很大，所以阿里巴巴会抽象一层，使用DSL（DomainSpecificLanguage,现场专用语言)来描述SQL的取数需求，支持标准，到目前为止，所有简单的查询服务都减少到另一个接口，这降低了数据服务的维护成本。传统的问题检查方式需要检查源代码，确认逻辑，SmartDQ只需要检查SQL的工作量，并可以通过写SQL向业务提供服务，SmartDQ包装跨域数据源和分布式查询功能，通过逻辑表屏蔽底部物理表细节，无论是HBASE还是MySQL，是单表还是库表，大大简化了操作的复杂性。事实上，中国移动业务分析规范早就提出了即席查询、伪代码等包装方法，作者企业也通过自助实践，阿里在着陆方面做得更好，是大师，传统企业大数据产品往往只能在单点上取得突破，不能使用团队始终坚持产品，如企业自助平台在设计中不需要支持跨异构数据库的大数据时代，由于原来的自助取数队和现在的DACP队完全是两组人，很难实现现有能力的传承。阿里的想法并不是很先进，但它不仅着陆了，而且不断演变，这可能是企业独立研发的价值，其产品总是流动着相同的血液。OneService：SQL显然无法解决复杂的业务逻辑。事实上，SmartDQ只能满足简单的查询服务需求。就像我们的自助取数只能满足50-60%的临时取数一样，企业遇到的场景如下：个性化垂直业务场景、实时数据推送服务和定时任务服务，OneService主要提供多种服务类型来满足客户需求，OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。Lego被设计成一个服务容器，面向中高度定制的数据查询需求，支持插件机制。我理解它是为了提供定制的环境和暴露的接口，你可以做任何你想做的事情。Lego被设计成一个服务容器，面向中高度定制的数据查询需求，支持插件机制。作者理解，它是为了提供定制的环境和暴露的接口，你可以做任何你想做的事情。iPush应用程序产品是TT、通过定制过滤规则，MetaQ等不同的消息源向Web发送、中间件平台，无线等终端推送消息。Utiming是一个非常个性化的应用，基于云中的任务调度应用，提供批量数据处理服务，支持用户识别、用户肖像、人群圈选择三种服务的离线计算、服务数据预处理和仓储。2、阿里在阿里云Maxconpute中构建了一套数据挖掘架构、在GPU等计算集群上，阿里巴巴收集了大量高质量的分布式算法，包括数据处理、特征工程、机器学习算法、文本算法等，可以有效地完成海量、1亿维度数据的复杂计算，提供一套易于操作的可视化编辑页面，大大降低了数据挖掘的门槛，提高了建模效率。它选择的计算框架是MPI，其核心算法是基于阿里云的MaxcomputeMPI实现的。该算法平台还集成了大多数行业主流的机器学习算法。让我有点惊讶的是，阿里巴巴还建立了一个数据挖掘平台。作者以前也想这样做，但后来发现与数据仓库的集成模型（如宽表）有很多相似之处，所以他没有坚持下去。阿里将数据中心分为三层：特征层（FDM）、中层和应用层（ADM）,中间层包括个体中间层（IDM）和中间层的关系（RDM），如下图所示：FDM层：用于存储模型训练中常用的特征指标，类似于集成模型的宽表。我很好奇阿里数据仓库的DWS只是一个收集层或一个宽表，否则它与FDM非常相似。IDM层：个体挖掘指标的中间层，面向个体挖掘场景，用于存储通用性强的结果数据。事实上，在我看来，它是通用标签库的源表。ADM是个性标签的源表。我不知道我是否理解正确。数据挖掘这一章很短，缺乏一些细节，想与部门定位有关，数据挖掘一般应用导向，核心可能掌握在各业务部门挖掘者手中，作者对数据挖掘平台的实际价值有疑问，毕竟，挖掘不断变化，数据仓库建模容易理解，但数据挖掘平台如何跟上变化？3、这本书占据了数据模型数据建模的三分之一，显示了它的重要性。首先，让我们谈谈阿里巴巴数据模型的历史。事实上，它仍然与作者有很多关系，因为在2005年至2007年，为公司服务的合作伙伴大量BI人员跳槽到阿里巴巴。据说他们已经建立了阿里巴巴一代的数据仓库系统，其中许多人都与作者合作过。现在他们仍然有点情绪化。（1） 历史发展的第一阶段：在完全应用驱动的时代，数据完全满足报告需求，以与源结构相同的方式将数据同步到Oracle，类似于作者刚刚进入公司的情况。第二阶段：随着阿里业务的快速发展，数据量的快速增长，性能已成为一个大问题，需要通过一些模型技术改变烟囱开发模型，消除数据冗余，提高数据一致性，传统行业数据仓库工程师开始尝试更受欢迎的ER模型 将维度模型模式应用到阿里巴巴集团，构建四层模型架构，即ODL(数据操作层) BDL(基础数据层) IDL(接口数据层) ADL(应用数据层)。ODL与源系统一致。BDL希望引入ER模型，加强数据集成，构建一致的基础数据模型。IDL基于维度模型方法构建市场层。ADL完成了个性化的应用程序和基于显示需求的数据组装，这对应于作者所在企业的当前ODS，DWD，DWA/DWI和ST层，但阿里在构建ER时遇到了更大的挑战，主要是业务的快速发展，人员变化迅速，业务知识基础不全面，导致ER模型输出困难。阿里巴巴得出结论：在不成熟、快速变化的业务层面，构建ER模型的风险很大，不适合构建ER模型。例如，运营商的业务相对稳定，世界上也有一些最佳实践，可以从概念-领域-逻辑-物理的整体控制来处理，但面对变化，确实有其限制。第三阶段：阿里巴巴业务和数据的快速发展迎来了以hadoop为代表的部署式存储计算的快速发展。与此同时，阿里巴巴自主开发的分布式计算平台Maxcompute也在进行中。因此，它开始构建自己的第三代模型架构。它选择了以Kimball维度建模为核心概念的模型方法论，并在一定程度上进行了升级和扩展，建立了阿里巴巴集团的公共层模型数据架构体系。阿里模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）以及应用数据层（ADS），模型层包括详细数据层（DWD）和汇总数据层（DWS）。阿里模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）以及应用数据层（ADS），模型层包括详细数据层（DWD）和汇总数据层（DWS）。ODS：将操作系统数据存储在数据仓库系统中，几乎没有处理。CDM：细分为DWD和DWS，分别是详细数据层和汇总数据层，以维度模型方法为理论基础，采用一些维度退化方法，将维度退化到事实表，减少事实表与维度表的关联，提高详细数据表的可用性，同时在汇总数据层，加强指标维度退化，采取更广泛的手段建立公共指标数据层，提高公共指标的可用性。ADS：根据CDM和ODS加工，存储数据产品的个性化统计指标数据。具体见以下模型架构图:每个行业都可以根据自己的实际情况来划分模型的分层。没有所谓的最佳实践。比如作者所在的企业，源维度一致性很好。DWD主要做标准化工作，屏蔽ODS变化引起的上层变化。维度建模的概念更多体现在DWA/DWI层面。（2） OneData的模型实施是阿里巴巴的模型设计理论。我认为它写得很好。读完这个过程后，你基本上会了解维度建模的每一步。强烈建议结合以下维度和事实表建模进行精读。主要步骤如下：数据研究：业务研究需要了解业务系统的业务，需求分析是收集分析师运营商对数据或报表的需求，实际上，报告需求是最现实的建模需求的基础。架构设计：分为数据域划分和构建总线矩阵。数据域划分是指业务流程或维度的抽象集合。业务流程可以概括为不可分割的行为事件，如订单、支付等。架构设计：分为数据域划分和构建总线矩阵。数据域划分是指业务流程或维度的抽象集合。业务流程可以概括为不可分割的行为事件，如订单、支付等。构建总线矩阵需要明确每个数据域下游的业务流程和维度，并定义每个数据域下的业务流程和维度。标准定义：标准定义主要定义指标系统，包括原子指标、修饰词、时间周期和衍生指标。阿里巴巴对指标的标准定义有一个单独的描述。你可以努力学习。很多时候，细节决定成败。模型设计：模型设计主要包括维度和属性的规范定义、维度表、详细事实表和总结事实表。最后，用图镇楼，这张图值回书价。本书介绍了维度设计和事实表设计，由于细节过多，作者不再展开，如果你是建模人员，必须好好看，也可以参考数据仓库工具箱维度建模权威指南，一般在建模过程中遇到很多问题有解决策略，未来可能遇到建模问题，本书也提到了很多，是建模人员宝贵的实际战斗参考材料。4、数据管理数据管理涉及很多事情，本书具体提到元数据、计算管理、存储和成本管理和数据质量，相对内容相对较薄，我选择两点：总是听说阿里丰富的氛围，所有数据永久保留，实际上是荒谬的，人们也节省生活，看下图：处理无尽的数据和应用，数据工程师很难确定哪些数据是最重要的，阿里巴巴提出了数据资产水平的解决方案，旨在解决消费场景中知道的问题。它将数据分为五个层次，从A1到A5，具有毁灭性、整体性、局部性、一般性和未知性。那么如何给每个资产贴上等级标签，就是借助强大的元数据能力，了解哪些表服务于哪些数据产品。基于血缘分析，可以说整个消费链路都贴上了某种资产的标签。如果阿里巴巴业务人员定位等级A2，所有相关链接的等级都是A2，从而启动相应的保障措施，类似于作者企业的大数据保障方法。确定表的保证等级，应用程序的重要性。5、阿里的数据应用主要介绍了外部数据产品平台的业务人员和服务于内部的数据产品平台。从本质上讲，商务顾问是为自己的渠道提供的增值服务。这是一个非常成功的决策支持产品，反映了一个产品如何从小成长为庞然大物的过程：内部数据产品的演变几乎是每个公司BI系统的开发和复制，但很明显，它已经长成了一棵大树，从临时计数阶段到自动报告阶段（如BIEE），然后到BI自主研发阶段(第三方无法满足自己)，最后到数据产品平台(更系统化)。目前，包括PC和APP版本在内的阿里数据产品平台有四个层次，即数据监控、专题分析、应用分析和数据决策。目前，阿里巴巴的数据产品平台，包括PC和APP版本，有四个层次，即数据监控、专题分析、应用分析和数据决策。在这里，我基本上已经读完了。整本书都是关于经验的。它经常闪闪发光。建议多读几遍。这本书也引起了作者的一些思考，为什么他们能做到呢？传统企业大数据的差距在哪里？是机制流程问题吗？数据产品的传承？合作伙伴的问题？核心能力自控问题？业务对数据产品的驱动力问题？小步快跑落地问题？企业产品规划？遗憾的是，这本书更多的是关于技术和数据内容的深入阐述