问问你们公司有没有数据团队，数据团队做统一数据管理一般会部署元数据管理系统。

这种需求都无脑 discuz

封资源这个，其实不可避免，国内会封，影视文件资源考虑版权问题，放在发达国家提供服务的网盘上，被处理本身也是高危的；

稳妥一点儿，想平衡的话，有个方法，就是做加密文件，veracrypt 之类，把文件封装在加密文件中，基本上存在哪里都无所谓，作为历史存档基本上不怎么打开用。

职场话题我其实重复无数次了，对于绝大部分普罗大众的打工干饭人，找对老大，跟对人，比什么都重要；

不是说技术水平不重要，但其实绝大部分人的知识水平、能力程度，从打工角度没有任何区别，没有谁是不可替代的；

如果你不是大佬，就去找一个大佬，ta 有上升空间，你才能有空间，而且未来预期工作机会，补坑的机会就是越来越少，就是有创新的机会，从公司运作角度，找一个信得过的团队大佬过来，带一个团队，效率比社招高多少；

你就是润出去，也别以为人际关系就不重要了，看看三哥们在硅谷一呼百应，再看看能提的出来无论哪里的企业初创时背后的股权结构，别提什么国家、文化，你只要是人，只要在社会生存，这种关系就是无法避免的，没有人际关系最后吃亏的真是自己；

如果老大靠谱儿，一定紧跟，老大不靠谱儿，自己做成大佬让一群人追着你也成，不要一把年纪了还没办法只能“刷题”找机会，一个人能走的更快，但是一群人才能走的更远。

@tellmeworld 这个是我的习惯，因为我不是系统应用研发，我们是搞数据研发的，所以基础的业务数据行为数据等一些结构设计等，都不太符合我们做数据的要求，为了更满足我们处理的要求，一般都会有很多调整，处理好基本结构后再把数据插回去。

1 、费力不讨好；
2 、实际上针对大规模业务和相对稳定的业务但是多变的产品，核心数据仓库依然是非常好的稳定支持选择；
3 、但是建设这个东西是个玄学，不懂的人都认为没价值，你让谁去做，基本上短时间也能怼一个；
4 、真正做出一套成型体系，让每个层的人都用起来舒服的数据仓库，是相当考验功力的；
5 、综上所述，久而久之这东西也就失传了，因为小公司业务不稳定没必要，中公司雇不起人，大型公司数据核心系统的坑少，一般人也进不去；
6 、传统企业基本都不懂，追风，基本都是听营销企业编出一个新名词就去追，拿数仓说大家都会认为技术太老了，不够 fashion ；
7 、最后：数据仓库不是写表的，而是定标准和研究数据流结构的，做表那是应用层的事儿。

mysql 和 es 我都很少用，但是这类使用习惯都是先分析，想清楚历史数据和增量数据以及使用的特征，先在服务器建好库分区分表索引，把数据直接扔上去再根据新结构插进去，这样逻辑清楚，兼顾未来使用，就几千万条数据而已，很快。

@longmeier90 这种都比较理论，你就搜搜传统数据集市设计的内容看看，但通用方法论实际用的时候，还是个经验和玄学的综合体，最后都是取舍平衡，那些通用方法论能实际套用的很少，只能说是借鉴思想。

@smark 深表理解，我家里是我妈干活儿，总有各种要求的统计数据，我妈这个年纪搞不定，就都“外包”给我来帮她做，这些事业单位真是做了一笔好买卖，笃定了不管多麻烦，家里肯定有人给兜底，这么算，她们的薪资水平其实划算的很 /doge

@kevinmissu 绝大部分地区都覆盖了，只要你父母有基本医保就可以，城市的有城市社保，在老家的一般有那种助农之类的，惠民保基本上不设定什么门槛儿，基本上你有户籍大概就都能入，只是每年有一段儿时间开放，今年没赶上就等明年，这个惠民保是唯一一个我强烈建议，尤其是家里有老年人必须要买的；

因为我现在转行做健康了嘛，相关行业的也都会涉及一些，惠民保是保险行业自己的保险规划人员都买的，它们自己的保险（主要是说这类健康险）自己不怎么买，因为它们自己都精算过，能用上的概率实在太低，不划算；

惠民保主要就是为了防止因病返贫，怕老百姓不敢消费设计的，你看每年的报道，保险公司都是接了任务，这个保险根本不为赚钱，120 万的血液肿瘤这类动不动就上线，因为发现真上了线其实得这个病的人也很少，几乎用不到，像南方深圳这类行动力强的城市，一年恨不得调整三次，生怕这个保险的钱花不出去，zz 任务完成的不好；

年轻人反倒是没啥必要买，但是价格也不高，就当是为老年人集资了；

剩下的有很多免费的意外险，其实它们就是用这个来套你的用户资料，然后看看有没有二次销售，你看见的时候，有赠送的，就收下，反正记得它们再打什么电话二次销售之类的，咬住嘴，别轻易下单就行了；

基本上健康方向的，薅免费的意外险，有基本医保，配个惠民保，对于 99%的老百姓，都够用了，我们自己私下开玩笑，常说的一句话是：

“你能看的病，这些保险都包了，看不好的病，要保险也没啥用”

如果你再有更高的追求，想在健康方面以及养老保障方面再深入一步，那这些保险我没什么了解，就不好建议了。

@gongjinchu 行业天花板，你在某个细分领域做到一定程度就会遇到天花板，和你无关，但是和行业有关，人无远虑必有近忧，如果你想未来有更高的天花板，就要在某一个时刻决定是否要赌一把，切换赛道，我是在市场里厮杀一路滚出来的，一个行业从无到有，到开始涌入，惨烈竞争，到最后大家都没利润逐步离开，这个用户生命周期曲线用在绝大部分没有绝对技术或规模护城河的企业上，都适用，这是个选择问题，看你对未来怎么规划了。

1 、之前的数据先不管，现在的数据就别这么搞了，至少现在的数据别真的把数据关系都干掉，这样至少从今天起，后面你就不再发愁了；
2 、历史数据，根据你的业务情况来做分析，比如一般这类东西要用多久，6 个月？ 12 个月？ 24 个月？可以先卡个节点，然后按照创建时间或者使用时间排序，把近期没有再访问的或创建时间久的整体捞出来，也别删，打包压缩先存到别的地方；
3 、28 定律，一般来说，20%的时间把这些折腾了，你觉得乱七八糟的 80%的问题就解决了，至于后面的 20%的麻烦，看你遇到没遇到问题，没遇到就保持这种策略，过个 1 、2 年自然迭代完过了保护期，99%的问题自然就没了，真遇到需要回溯的，至少当前处理之后的你不发愁，在历史里的大不了解压缩拿回来再慢慢找。

单纯这点儿信息资料还是太少了，再多提供一些，比如男性？年龄范围？大概是哪里的人？内蒙古？ 40 来岁？

头一阵子刚泄漏的核酸数据，倒是现在降价了，但自己买也没必要，这阵子估计黑产还在洗，高价值做的差不多才会慢慢放出来供这类需求，有上诉期的话，可以再等等；

数据的事儿，还得找数据专业的人问 /doge

这个问题，加钱就能解决。

我做了很多，结果都失败了；

我原来是做大数据团队的，在系统和应用研发的后端，但是业务原因，我们的诸多业务都是依赖数据的，而且规模也大，对这个我是真的深恶痛绝；

以前重构系统，我们做过词汇提炼，设计过库表字段的词组结构和命名语法，在内部技术站发布，在重新研发新系统的时候也进驻，然后为了确保统一，都主动在实施前主动要求增加流程，把同一语义作为一个审核流程环节加进去，但是又怕研发兄弟姐妹们嫌弃我事儿多，所以还主动把事儿接过来，拿到新数据结构，让我们团队给统一梳理做完命名后再发回给研发团队…… 各种事儿，前前后后做了不知道多少；

最后依然是鸡飞狗跳，这个东西吧，就是得从建团队的时候，研发老大得把这个东西当成一种文化来建设，不然等到团队规模大了，系统应用多了，完全就是无组织无纪律；

我们和系统 /应用研发团队的矛盾很多都基于此，系统 /应用研发团队主要看业务逻辑是不是通，其他的不管，但是就没考虑过做大之后，我们在后端要应付的麻烦有多少，反正到最后我放弃了，跟团队的兄弟姐妹说，咱们自己的数据系统命名就叫垃圾回收站，寓意不管系统应用那边怎么折腾怎么用，反正数据丢回来我们在这里重新分类清理当成再生资源，都处理好再返回给各个系统；

回首往事，提起这些都是泪。

就像搞个小系统，问自己研发，一算人工时成本 1 万，一问外面外包 3000 ，那技术一定会站出来竭力反对，比如代码没保障，搞完了一定会要求加钱 blablabla ，不然自己存在的意义是什么，尤其是对自己技术能力和业务知识都有限的人来说，大系统搞不了，小功能现在又用不着，人家业务自己搭着搭着就搞定了；

我 N 年前就跟数据分析师团队说过这句话，无论接受与否，相关的应用技术一定会越来越普及，基础人员的应用能力也会随着新人的成长而逐步普及化，除去极端细分领域，现在哪里还听得到需要打字员了；

做小的基础应用，零代码平台确实对普通业务人员极其友好，自己本身就懂业务，拼拼搭搭效率自然比中间传来传去的效率高多了。

业务端不敢苟同，但是在此类技术领域，相比这些资源企业，百度还是更靠谱点儿的。

@anyele 乱讲，你加一下就知道是不是真的了，反馈特别及时 /doge