22年校招入职京东后，我一直在数据中台测试部从事测试开发的工作。毕业后，写的最多的文档是测试计划和测试报告，鲜有机会就自己的成长码字进行回顾和总结。借“up技术人”栏目，也终于是在工作之余回头望，对自己这近两年时光进行一个小总结。本文是一个大数据测试小白初入职场后的成长总结，有新人入职的迷茫，也有点滴积累后的经验之谈。希望此文能够对正在迷茫的新人朋友以及对大数据测试有兴趣的同学有些帮助。

本文章主要描述了GaussDB(DWS)与HiveMetaStore对接配置与指导。

1. 世界上 46% 的网站由 WordPress 构建的： 2. 自 2003 年成立以来，WordPress 的使用率一直在稳步上升：  3. 而之前占据了很大的市场份额的建站软件 Drupal 和 Joomla 自 2015 年达到峰值之后，均大幅下 …

本文于 2024年4月4日 5:00 更新，注意查看最新内容 在大数据环境中进行数据清洗和预处理是一个复杂且关 […] 如何在大数据环境中进行数据清洗和预处理？最先出现在龙鲲博客。

大数据 和 Java 形成强大的协同作用。大数据以其高 容量、 高速度和 多样性为特征，已成为各行业的游戏规则改变者。什么是大数据？使用传统数据处理技术难以处理和处理的异常大的数据集被称为“大数据”。这些数据集属于三类之一：有组织的、半结构化的或非结构化的数据。它们的形式多种多样，变化率或速度也很高。容量是信息量的衡量标准，速度是新数据创建和处理速度的衡量标准。数据的多样性是指可用的各种数据。大数据为研究人员和组织提供了新的视角，但也引发了存储、分析和隐私问题。什么是Java？Java编程语言被设计为具有作为面向对象编程语言可能的最高级别的类，以最大限度地减少对实现的依赖。名为“一次编写，随处

大数据和后端服务之间的差别，远比后端服务之间，比如推荐架构、搜索架构、直播架构等的差别要大。两者比较的文章似乎很少见。 但实际上，我在做后端服务的时候，也曾调研过能否使用大数据的组件，比如 Flink、Kafka。很多后端服务也会用到大数据的存储，比如 Hbase 来存储数据。 还记得刚从后端转到大数据开发时，对各种差别感到疑惑。如今做了几年大数据，有的疑惑逐渐解开，有的疑惑依旧看不清，有必要阶段性的总结一下。当然，工程师不应该限制自己是大数据、前端还是后端还是算法，但是试图理清区别和联系，能够让我们的视野看的更高。 1. 大数据的技术本质还是后端服务 以在大数据离线任务开发中，常见的 Apache DolphinScheduler 工作流调度系统为例。DolphinScheduler 架构是一套典型的去中心化的 Master-Worker 架构。相同的架构，我之前做后端服务时也实现过一版，用来更新搜索词典、数据删除、Key白名单等操作，区别仅仅是总控模块不叫 master 而是 center. 系统的关注点是类似的，比如 master/center 依赖 zk 实现高可用；worker 处理能力线性扩展；RPC的选型、request/response 的数据结构；数据库读写控制在总控模块；数据库的优化等等。 Flink 里的 JobManager、TaskManager 也是如此：JobManager 负责资源管理、Checkpoint、RestEndpoint这些服务，TaskManager 则负责具体执行用户代码。两者之间通过 akka RPC 通信，采用内存队列缓存 RPC 消息。同时心跳机制、HA的实现、服务发现等等，也都是后端服务实现时需要重点考虑的。 ┌───────────────────────────────┐ │ │ │ master/center/jobmanager │ HA/Service Discovery/Storage/Coordinate/... │ │ └─────┬────────────────────┬────┘ │ │ │ │ RPC/pool/queue/ACK/... │ │ RPC/pool/queue/ACK/... │ │ │ │ ┌───────────────────────────┴───┐ ┌─┴─────────────────────────────┐ │ │ │ │ │ worker/taskmanager │ │ worker/taskmanager │ │ │ │ │ └───────────────────────────────┘ └───────────────────────────────┘ 部署上，大数据的组件 Flink Spark MapReduce 都通过 YARN 部署，后端服务往往通过 K8S 部署。而这几年的发展趋势，大数据这些组件，也支持部署到 K8S 了。 至于分组隔离、存算分离、冷热存储等，也都屡见不鲜。 因此，大数据组件的技术，本质上还是后端服务。 2. 大数据的技术使用上更加简单 由于面向不同的用户，大数据的组件往往追求简单的使用方式。 还是以第一节的例子来说。 我在实现 center-worker 这套系统时，重点考虑 center. 至于 worker，则是开放了 RPC 协议，按需实现不同的功能。center 按照业务逻辑顺序，调用不同的 worker。系统面向的用户是 RD，这样的好处，是不同小组的 RD 可以开发不同的 worker，代码、语言甚至都可以不同。worker 的代码变化频繁，每组 worker 单独评估性能、稳定性以及上线。 而在 dolphinscheduler，worker 的能力是完全相同的，不同的需求通过内置的 plugin 实现，例如执行 SparkSQL、DorisSQL、FlinkSQL 等等。worker 的能力也就比较固定，一旦成型代码变化不大。系统面向的用户大部分是数仓，用户关注的是 SQL 执行的结果，至于上一节提到的架构、RPC的协议这些，都不是用户关心的。这是相同系统架构时，后端和大数据关注点的不同。 因此，大数据的技术，使用上需要尽量简单。 这种易用性的追求，也会导致一些常见的错误。以 Flink 的 DataStream API 为例，这段 scala 代码目的是过滤 >threshold 的数据 ： object ATestStream extends App { val env = StreamExecutionEnvironment.getExecutionEnvironment private val threshold = 5 env.fromSequence(1, 10) .filter(_ > threshold) .print("after filter:") env.execute() } 程序输出的内容，不熟悉的 RD 大概率会认为是after filter: 6, after filter: 7, .... 但实际上是： after filter:> 1 after filter:> 2 after filter:> 3 after filter:> 4 after filter:> 5 after filter:> 6 after filter:> 7 after filter:> 8 after filter:> 9 after filter:> 10 究其原因，是因为 DataStream API 和 MapReduce 一样，都是声明式的： 用户的 main 方法，不是程序的入口，只是 TaskManager 很小的一部分。 用户的 filter/print/… 方法，嵌入在真正的物理执行算子里，用来处理数据。 threshold 这个变量，是 main 方法的局部变量，而 filter/print/… 方法，是运行在 TaskManager 上的。进一步的，main方法的执行，可能是在 client 端，也可能是在 JobManager.因此在 TaskManager，threshold实际是个未初始化的变量。当然，这里也跟是否是 Standalone 运行环境有关，就不在技术层面展开了。 类似的，在平时为实时计算平台的用户答疑时，也会看到这样出问题的 case: // kafka val prop = new Properties() prop.setProperty("bootstrap.servers", "...") // sasl_ssl 参数 prop.setProperty("ssl.truststore.location", localFile.getPath) // 初始化kafka val kafkaConsumer = new FlinkKafkaConsumer[String](topics, new SimpleStringSchema(), prop) 但是毫无疑问，这种声明式的使用方式，易用性是非常高的。我看到很多 qps 达到百万的实时任务，用户只需要实现 map/filter/sink 等方法，就可以轻松实现。 这种只需要关注输入输出，不用考虑多线程的竞争关系，也不用考虑词典(大数据称为维表 Temporal Join)是如何加载和查询的，用户只需要在单线程里根据输入实现输出逻辑。我们在封装后端模块时，理想的状态就是这样的。 因此从这点上，大数据的技术是靠前的。基于 K8S 的函数计算，出现的晚，但是使用上，还是这些声明式的 API 更加简单。 对易用性的追求，也是大数据离线、实时计算都支持 SQL 的一个原因，目的还是要简化开发。 3. 大数据的技术运维上更加复杂 系统整体的复杂度是守恒的，用户看到的简单，底层的复杂度就会变高。就跟冰山一样，露在海面上的，只是极小的一部分。 比如大数据实时任务的开发者，很多对自己任务的单并发性能并不了解，更别说数据倾斜的影响了。 这背后也有原因： 如果我只花了两天时间开发，愿意再去花相同的时间压测么？大部分公司应该都是相同的答案，即使Yes，我面对了几百个任务，要逐个压测？ 如果我压测性能有问题，怎么解决呢？本来我只需要看看 Flink 的 API，现在你要我去了解各类性能指标？分析 Source/Sink/Rebalance？ 因此，默认值在大数据里是个非常常见的东西。CPU个数、内存大小都有默认值，用户只写 SQL/Stream API，运行起来有问题，往往需要技术在底层优化，或者给出调整的参数。任务的并发数也是如此，所以在 Spark/Flink 里都会看到资源自动调优 这种概念。类似的事情，在后端开发是绝对禁止的。默认值这个东西，使用者感觉不到。但是一旦多了，修改的成本成倍增加，牵一发而动全身，一旦修改，影响全部任务。 再看个 traceid 的例子，假定调用流程为： 后端服务: 后端模块A -> 后端模块B -> 后端模块C -> 后端模块D -> ... 大数据 : 实时任务A -> 实时任务B -> 实时任务C -> 实时任务D -> ... 两者相似的点都是数据的流转过程，我们想要通过 trace 了解各个模块/任务处理的时间，某个模块/任务是否丟数等。 对于后端模块，可以方便的加入 traceid： // 收到 RPC 数据 module_input module_input = (meta_data, input_data) // 处理数据逻辑，只关注 input_data output_data = f(input_data) // 补充 medata_data，RPC 发送到下一个模块 module_output = (meta_data, output_data) 这样的好处： 业务方只需要实现f(...)方法，单线程处理输入输出 traceid 存储到 metadata，对业务不可见，不会困扰也不会误修改 即使有数据扩散或者主动丢弃，业务方也完全意识不到 meta_data 的存在，专心实现 f 方法处理数据就行，除非也有 trace 日志的需要。 换到 flink 的 DataStream API，假定业务方实现了如下代码： sourceStream.map(input_data -> middle_data) .keyBy(middle_data_1.key) .map(middle_data -> output_data) .addSink(sink) 无论是修改转换 transformation 的过程，还是添加类似 watermark、latencymark 的标记，都非常复杂。主要是本身已经是声明式的 API，不是后端开发习惯的线程模型。 当然，对大数据处理过程增加 trace，本身数据量、计算量也都是个挑战。 我觉得大数据的开发非常简单，而对于异常处理、脏数据的处理、case的追查这类运行中的问题，要比后端服务差一些。但是，实时任务、高优看板数据的稳定性，实际上也是非常高的，不低于后端服务。 这里面很多边界条件的处理，以配置项/DDL properties/声明式 API 的方式暴露给了用户，复杂度留到了 runtime 阶段。 这里带来的另外一个问题，就是权责不清：本应该用户关注到的点，以一种近乎可以忽略的易用方式提供出来。good case 被视作理所当然；bad case，则因为“历史上没有关注”陷入扯皮的境地。如何划出一道权责清晰的边界，是在权衡易用性和运维复杂度时，一个重要的考量点。云厂商的大数据基建 SLA，是一个很好的参考点。可以多翻翻，有多少、在什么样的环境下，可以承诺到任务级别的 SLA. 因此，大数据的技术运维上更加复杂。 4. 总结：解决问题 技术的本质是为了解决问题，技术演变的过程也是问题逐步解决的过程。由于高度的封装带来易用性的提高，大数据可以轻松写出百万级别qps、秒级延迟的任务，而之后可能出现的问题，则是被分摊在了漫长的运维过程中。 很长一段时间，大数据依旧会在各种新名词、易用性(标准SQL、批流、融合、统一)上追逐，运维能力上追赶后端服务。而对于后端服务，则是逐步借鉴大数据的思想，通过K8S这个强大的资源编排系统，将通用的能力落地到资源调度和执行引擎这两层，使得后端开发更加简单、标准化。

本文来源：西安财经大学数学学院 根据学校关于毕业论文的进度安排，数据科学系全体毕业论文指导老师在2023年11 […]

近日，以“腾云逐浪，智在千里”为主题的2024年腾讯产业合作伙伴大会在海南三亚召开，众多业界领袖和近千家合作伙伴齐聚一堂，共同探讨和展望产业生态发展的新趋势和机遇。https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltac53cd4ed4efab50/65c264d0eed32eccefac2ff4/1-tencent-blog.png,1-tencent-blog.png作为腾讯云在大数据搜索分析领域的重要生态合作伙伴，Elastic受邀出席并荣获“腾讯云2023年度合作伙伴奖”。https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt316680a83439ceae/65c264f825aa94b02534fe9a/2-tencent-blog.png,2-tencent-blog.pngElastic与腾讯云自2019年建立战略合作伙伴关系，双方在产品、技术、生态等多个维度展开了深入的合作。

在自动驾驶数据集中，采用主动学习策略可以解决数据不平衡、冗余和高维数据的挑战。我们展示了使用信息熵查询来选择信息丰富的样本，旨在降低注释成本和提高模型性能的有效性。我们在 nuScenes 数据集上使用 BEVFusion 模型进行了实验，将主动学习与随机抽样进行比较，并证明信息熵查询在大多数案例中表现优异。该方法在减少多数类和少数类之间的性能差距方面特别有效。类别特定的分析揭示了对有限数据预算进行注释资源的有效配置，强调选择多样性和信息丰富的数据用于模型训练的重要性。我们的发现表明，在资源受限的环境中，信息熵查询是选择增强模型学习的数据的一种有前途的策略。

企业数据变得越来越具有挑战性，并且由于它在战略规划和决策中发挥着关键作用，组织被迫在从数据资产中提取有用的业务洞察所需的人员、程序和技术上投入资金。当我们深入研究 2024 年时，数据科学工具的前景已经发生了显着的创新，并且引人注目。本博客将探讨2024 年十大数据科学工具。这些技术改进使得数据的摄取、清理、处理、分析、建模和显示变得更加容易。此外，某些技术还为模型的构建、跟踪、部署和监控提供了机器学习生态系统。什么是数据科学工具？数据科学家可以借助数据科学工具（即应用程序软件或框架）执行各种数据科学任务。每个工具都包含精选的应用程序。数据科学技术的使用并不局限于一项任务。它们使生态系统能够获