题记

此篇总结一下目前生成式AI在企业中的研发实践。作为一个大数据开发出身的我来说，越来越感受到 数据+算法+算力 人工智能三要素的紧密关系是多么重要。

注：以下总结来源于infoQ研究报告摘要。

场景

办公

• 文本信息的处理和生成
• 数据分析
• 个人办公助理
• 图像信息的处理和生成
• PPT生成和美化

教育

• 学习助手类
• 个性化教学方案生成
• 陪伴学习类
• 辅助教师作业批改
• 数据分析
• 练习题等作业自动生成

序

2022还是被yq“笼罩”的一年，几乎全年核算，年底还是小阳人。在防控放开后，2023会有更多机遇和风险，生活也会慢慢恢复到2019年的那个时候吧（等通知）～

这篇文章还是讲小“我”，大的咱也不敢说，咱也做不了什么。只希望，10年，20年后，自己看到自己的blog的时候，能够想起2022经历了什么吧。

序

这是一篇迟到的总结，没有像往年在元旦期间完成，究其原因是自己这一年过的有些“清淡”。在春节的最后一天，还是鼓起勇气把这篇迟到的2021总结写了。想将这习惯继续延续。以下是对2021流水总结，没有其他只是一种回顾和下一年的规划。

序

2020注定是个不平凡的一年。又到了跨年的时刻，总感觉不写点什么对不起这个“难忘”的2020。

依旧延续传统吧，总结过往，展望未来。至少在20年后，看看这些，我觉得还是挺感动的。所以，窝在被窝（这两天，杭州零下，确实有点冷）开始更新停滞已久的blog。

前言

这周做了个事情趁热沉淀一下。问题很明确治理小文件。问题由来，要追溯到去年，集群治理了。之前做到存储和计算的管理，后续做了简单hdfs画像（其中，就有小文件趋势监控）。最近，集群中namenode压力有所显现。于是，针对小文件多的目录进行了排查和治理。进而，有了今天的这个主题ORC小文件合并趣谈。

核心问题

这里，首先治理的是实时导入数据的目录。这里增量数据采用SparkSQL以动态分区增量写入的方式。众所周知，spark在处理时，每个task都会写入一个文件（如果task处理的数据，包含n个分区的数据，就会产生n个文件）。进而，在并行度高的情况下，导致对应增量分区文件很多（存储并不大）。

在存储治理中，平台统一要求将hive表的格式向orc格式靠拢。orc的表在存储和查询上都有很好的提升。所以，这个问题就间接的转化为解决orc小文件问题。

背景

某一天，突然一个导入任务的merge操作出现长时间运行。由原来1h执行完成的，延长到10h。

对比yarn 信息，如下示：

对比发现，Map数和Reduce都有所减少。

分析

查看表文件发现前一天的分区表文件数不一致。
23分区只有1个文件（大小为800多MB；22号有200+个文件，每个文件40多MB）

这样算起来，文件大小几乎翻了10倍，实际数据相等。

很奇怪，哪里的问题？

今年的总结从何说起？元旦一天假期，本来想不写了。想想还是将这个习惯传承下去的好。不做深层次的分析，只是个流水总结。

19总结

按照惯例，总结之前先看看上一年给自己“提纲”-2018の自己中末尾提到。

前言

又到年底了，职场充斥着“裁员”、“优化”味道。前段时间所在公司也经历了一波，反正有那么几天周围的同事都无心工作。这周公司也算是“稳定”了，不过还是有些危机感。有时候，在反思这一年来自己工作的“亮点”。想了想，好像一直在“优化”的路上。这里的优化是和工作相关的，集群，存储，计算的治理占据了2019大半的“江山”。说来惭愧，好像也没实打实地落地成一个产品。

又到周末了，天气貌似不错。没有活动，自己看了看工作wiki，理了理工作内容。过程中，很多细节上的事情没有沉淀（虽然今年也依据工作内容输出了一点点想法），缺少细致的总结。导致现在很多事情让自己说，还是有很多不确定的细节。

背景

近期在做spark 运行任务信息采集（便于后续的任务执行分析作准备），遇到一点问题：

• 通过spark history server（下面统称：SHS）提供的restful api获取application信息，与通过yarn采集的application数据量不一致。
• 采集几天，偶尔出现SHS restful api无数据返回问题。

1
2
3
4

运行环境
hadoop：hadoop-2.6.0-cdh5.13.0
spark：spark-2.1.1-bin-cdh5.13
jdk：jdk1.8.0_74

周末下了2天的雨，雨天适合看书，适合施展“懒人”模式。晚上，约了大学的朋友吃了个饭。回来的路上，透过车窗依旧下着雨。