《阿里巴巴大数据实践-大数据之路》节选推荐

7月份，有人推荐阿里巴巴刚出版的这本书《阿里巴巴大数据实践-大数据之路》，直到8月份才在亚马逊预售。翻看目录，我很高兴。我出差两天就带着它。我读完了它，因为我在机场呆了12个多小时。使用“产品”这个词有以下原因。首先，市场上有太多的大数据平台技术书籍，如hadoop和spark。然而，他们对如何管理大数据缺乏真正的见解。第二，这本书确实有很多干货和真诚。这显然来自阿里巴巴实践人员的经验，从作者是阿里巴巴的数据技术和产品部门可以看出，第三，内容与作者的专业一致，作者有实践或管理经验，想有资格评价这本书，最后，阿里巴巴的数据量，其大数据平台经过测试，突然透露了一些技术秘密，对于任何对大数据感兴趣的企业或个人，应该学习。因此，使用“产品”不能像阅读普通书籍那样一目了然。我们应该能够找到先进的概念，结合企业或自身的实际情况看到差距，找到可供参考的地方，指导后续的大数据工作。因此，使用“产品”不能像阅读普通书籍那样一目了然。我们应该能够找到先进的概念，结合企业或自身的实际情况看到差距，找到可以从中学习的地方，指导后续的大数据工作。大数据广泛而深刻，就像这本书也是集体创作一样，受作者水平的限制，阅读笔记只能浮出水面，如果你觉得有灵感，你可以买一个，自己品尝一个产品。首先是镇楼图。阿里巴巴大数据系统的系统架构图分为四层：数据采集、数据计算、数据服务和数据应用。以下内容围绕这张图展开。每个人都知道技术含量有多高。如果你在阅读后迷路了，你可以回头看看这张图。作者在这里选择的内容主要是与自己的企业竞争后的特点，一般内容不提及，当然，这只是作者的观点，所以建议阅读本文后阅读原著，可能会得到更多的启示。一、数据采集1、阿里巴巴为web和app端有两个专门的在线主动收集工具Aplus.Js和UserTrack，由于大多数传统公司长期线下运营，web和app的主动收集能力较弱。一般数据管理部门对web或app端的收集基本上是源头推送的文件，对收集没有实际主导地位。内容丰富度大大降低。同时，webjs脚本和appsdk实际上都有一定的技术门槛。由于企业app源受合作伙伴能力的限制，收集能力往往不足，数据质量参差不齐。互联网源日志保留，什么是源本身的要求，什么是大数据管理的要求，需要清楚地思考，如果大数据管理部门想要获得更好的数据，是否考虑向前一步，毕竟，OLAP和OLTP对数据的看法不同，人们不需要为你留下你需要的数据。企业大数据管理部门能否适应互联网的新形式，打破线路分割，在传统数据库、文本、新闻收集的基础上，增加在线主动收集工具，是一个巨大的挑战。企业大数据管理部门能否适应互联网的新形式，打破线路分割，在传统数据库、文本、新闻等收集的基础上，增加在线主动收集工具，是一个巨大的挑战。目前，一些企业提供的企业级大数据收集工具缺乏这条腿。在未来，企业将上网，这种PaaS能力确实需要具备。2、数据同步阿里巴巴实现了oracle归档日志等增量采集，应该比较成熟。他的企业也采用了类似的OGG技术。虽然可行，但成本很高，新股合并成本很高。DSG希望崛起。目前，分库和分中心的表越来越多，数据同步的配置也越来越复杂。阿里巴巴的tddl分布式数据库引擎可以通过建立中间逻辑来整合统一分库和分表的访问，这确实值得学习。许多企业提取的数据源种类繁多，管理复杂。阿里巴巴建立了IDB来实现数据库的统一管理。基于这个元数据能力，阿里巴巴可以利用oneclick实现数据采集的健康配置和批量同步，可以看到管理的深度和厚度。阿里巴巴还对数据漂移提出了解决方案。事实上，每个企业都存在大量的数据漂移问题，如运营商计费单的记录更新时间、日志时间、业务时间和提取时间往往不一致，这将导致业务的逻辑问题。您可能在上个月底12点之前打电话，但业务记录将在本月的账单中。二、数据计算1、Maxcompute离线计算引擎阿里的Maxcompute离线计算引擎弥补了hadoop的许多缺陷。它提供统一授权、资源管理、数据控制和权限分配等综合管理方案，并提供易于使用的客户端支持网络、SDK、CLT、IDE等四种访问模式，集群数量可达数万台，加强安全控制能力，这些都是目前许多商业hadoop版本难以实现的。其计算核心是飞天内核，包括Pangu(盘古分布式文件系统)、Fuxi(伏羲资源调度系统)、Shennong(神农监控模块)等。其计算核心是飞天内核，包括Pangu(盘古分布式文件系统)、Fuxi(伏羲资源调度系统)、Shennong(神农监控模块)等。、作者的企业在统一开发平台方面也有这样的平台，但与阿里巴巴的平台仍有差距。事实上，它是一个功能更完整、系统化程度更好的工具集。(1)云(D2)D2是集成任务开发、调试发布、生产任务调度、大数据运维、数据权限申请管理功能于一体的一站式数据开发平台，能够承担数据分析工作台的功能。这实际上与作者的DACP非常相似，但由于DACP可以连接各种源系统，底层逻辑实际上更复杂，实施更困难，D2基本上只要与Maxcompute连接，这实际上是独立研发的好处，功能可以更强大，更好的体验，但相对封闭。（2）SQLSCANSQLSCAN将总结并形成规则，通过系统和R&D流程保证，提前解决故障隐患，避免用户在任务开发中遇到的各种问题，如SQL质量差、性能低、不遵守规范等。这一功能对于将平台推向前线至关重要，我们的DACP在推广过程中，遇到了很多SQL优化问题，但无论是通过培训还是其他方式，实际上远不如系统固化规则，阿里实践很好，开发平台必须记住不可能每个人都是代码专家，系统解决问题，这是平台规模的核心要素。至于DACP功能太大的问题，作者也明显感受到了阿里巴巴将开发平台分成多个产品的一些想法，这有利于小步快跑的原则，为每个模块取不同的名称，也有利于专项资源的投资。（3）DQCDQC(数据质量中心)主要关注数据质量，通过配置数据质量验证规则，在数据处理任务过程中自动监控数据质量。它主要有两个功能：数据监控和数据清洗。数据监控主要是设置规则和报警。有强规则和弱规则。强规则可以阻止任务的执行。数据清洗的方式与我们大致相似。在引入过程中不清洗。入库后，根据配置规则进行清洗。（4）在另一边，通用和重复的操作主要沉淀在测试平台上，以避免人肉，提高测试效率。虽然作者所在企业的大数据自动化测试也有一些，但其功能不够强大。另一边的功能包括数据比较（支持不同集群和异构数据库的表进行数据比较，如数据量、字段统计值SUM、AVG等），从阿里巴巴的统一开发平台可以看到数据分布，它不仅提供了一套从任务开发到运行维护的完整工具，而且特别注重系统的完整性和规则的沉淀。这种平台工具实际上很难由第三方公司提供。除了缺乏自身的研发实力外，传统企业往往由于业务需求的压力而在IT等基础平台层面缺乏研发投资，盲目依靠资源和人力投资来解决一些无法解决的问题，同时，将报告的数量与产品开发人员混合在一起，导致厌倦了应对需求，这是值得深思的。3、实时技术阿里巴巴基于TimeTunnel收集实时数据，其原理与Kafka等新闻中间件相似，采用StreamCompute进行流式处理，与Storm、Stream相似，对于实时统计问题，其提出的一些方案值得借鉴。在商业智能统计实时任务中，资源消耗非常高，即重指标，实时任务追求性能，计算逻辑一般在内存中完成，在重计算中，必须保留重细节数据，当重细节数据达到数亿时，内存不小，怎么办？精确的重量可以通过数据倾斜处理，节点内存压力到多个节点，在模糊的前提下，可以使用相关的重量算法，内存使用到千分之一甚至万分之一，布隆过滤器是一种，简单地不保存细节数据，只保留细节数据对应的哈希值标记位置，当然，哈希值碰撞。在运行过程中，实时任务会计算许多维度和指标，如何保存这些数据？实时任务计算运行中的许多维度和指标。如何存储这些数据？由于大多数实时任务都是多线程处理的，这意味着数据存储必须能够更好地支持多并发读写，并且延迟需要在毫秒内满足实时性能要求。一般采用Hbase、Tair等列数据存储系统。当然，HBASE等系统的缺点也很明显，必须使用rowkey，而rowkey的规则限制了阅读和写作的方式，显然不像相关数据库那么方便，但一般适用于海量数据的实时计算和读写，为HBASE阿里巴巴提供了一些表名和rowkey设计的实践经验。例如，rowkey可以采用MD5 主维度 维度标识 字维度 时间维度 子维度2，比如卖家IDMD5的前四名 卖家ID app 一级类目 ddd 二级类ID，以MD5的前四名为rowkey的第一部分，可以分散数据，平衡服务器的整体负载，避免热点问题。作者一直认为实时数据不需要建模，似乎太天真，可能主要是实时应用在许多企业场景，但阿里显然不同，实时统计能力非常重要，无论是双11屏幕还是阿里业务人员，实时统计指标作为卖点，实时模型和离线模型建模理念一致，如阿里流动模型分为五层，ODS层、DWD层、DWS层、ADS层和DIM层将在作者的后续文章中介绍每层的含义，这里不再描述。