京东网站建设案例论文,在线网页设计网站,网站域名查询工具,网站中文域名好吗说明
我还是比较喜欢把文章放在这个专题下#xff0c;虽然这次的话题其实是个综合性的。
内容
1 理想架构
我一直在构建一个理想的数据处理系统#xff0c;但这个过程不是自顶向下#xff0c;一次设计完毕的。而是在不断的实践、反思和推倒重建汇总不断更新的。
或者说…说明
我还是比较喜欢把文章放在这个专题下虽然这次的话题其实是个综合性的。
内容
1 理想架构
我一直在构建一个理想的数据处理系统但这个过程不是自顶向下一次设计完毕的。而是在不断的实践、反思和推倒重建汇总不断更新的。
或者说我们对于理想架构的表现会有一些标准和期待这些标准和期待会形成一套相对固定的设计理念。在工程中我们会依据可用工具/材料来进行合理的搭配或者是升级改造但这套理念是相对固定的。
我曾经因为业务的需要翻出了5年前的项目代码发现处了当时所用的工具不同但内部的核心结构相对复杂的一个处理和后来是完全一致的。在两个相距很远的时间点在我看来产生了奇迹般的重合所以我相信关于数据处理的核心理念是有可能保持一致的。这件事的意义在于证明设计的最终目标是可以确定的有一个稳定的方法和要求。
但是对于IT行业来说内容太多了更新速度也非常快。即使我们有很好的想法但受限于知识以及当时可用工具的限制我们很难在一开始提出一个完美的方案。甚至从具有专业性开始我研究了至少5年吧也只是愈发觉得前路遥远。
比较幸运的是我觉得即使是当前水平我也可以构建具有相当能力的系统足够实用。并且预计在未来的5年内这个系统的核心能力仍然是可以线性提升的。特别是在chatgpt出来以后搭建理想系统的可能性、速度都提升了很多它真是一个划时代的工具。另外在硬件上整个行业也在以较快的速度前进摩尔定律似乎仍然有效。
综上
1 实现理想架构是完全可能的或者说满分100考到90分是可行的2 仍然会有不断新的工具、知识跳出来这些新的东西会部分推翻设计要重建3 时代有红利做这件事是很有希望的。从实用的角度5年左右系统就可以进化的足够强大。从工具的角度可能再加5年。
2 实现方法 人工智能需要先人工才智能 虽然我觉得玩语言游戏不是很好的习惯但在“人工智能”这四个字上可以例外。关于人工智能的起名其实也有很多历史故事最终大家接受了“人工智能”这样的称呼(普及率在60%以上吧)还是很有道理的。
1 对于普通人足够抽象但是又很好记忆2 对于开发者还是有很多提示的怎么去做这个抽象的东西
我自身的经验来看一开始先不要想太高级先迅速的把一个有用的过程搞出来。例如建模可能是一个很长的流程先用最简单但是最笨的方法去做一遍。然后想想哪些东西是可以抽象出来让理解和操作更简单的也不要想太多然后再去做。然后循环往复…
一直到你的确已经烦透了这件事占用的时间让你觉得完全不值得然后你做一个自动化这就是智能。
因为做得多才能了解的透因为思考的多才会有更好的办法因为不断的优化和实践才能得到可靠的结果。这个和卖油翁练本事很像做得多就好但是又有一点不像就是要抽象给计算机。
托马斯·阿尔瓦·爱迪生说天才是百分之一的灵感加百分之九十九的汗水但那1的灵感是最重要的甚至比那99的汗水都要重要。
说重复就是99%的函数而智能来自1%的灵感如果没有灵性(产生灵感的概率)做人工智能也难有大前途。但是对于有灵性的人来说汗水就是不可忽略的成功因素了。
不过处在一个时代的开头只要去做了就不会亏这又是另一个话题了。
3 重复实例
最近恰好有一个实例我希望对其进行改进。计划用一年多的时间分两个阶段把它推到一个稳定、智能的版本。
首先已经有一个可以运行的丐版服务。
第一阶段我计划三次迭代
1 第一次迭代不做改进只是将所有的流程清晰化将相关文档进行整理和集中管理、增加交互部分2 第二次迭代针对其中的IO、部署组件进行优化 Using Graph3 第三次迭代对核心的变换组件、控制组件进行优化 Using Graph
整个的内容会非常长我打算这次只将第一次的内容摘要写出来
本次实例的工作是准实时的获取数据然后进行处理最终以短信通知结束。
3.1 结构
从结构组件上需要两个ADBS和一个APS来完成任务。这个结构可以说是相当简单了比我之前设想的要精简的多。
3.2 ADBS01
创建过程还是有点麻烦的虽然我已经做了大量的集成。但是这个流程还是很长。
1 数据库服务。如果在机器上开始新的服务需要分配一个端口启动docker服务做好端口透射然后再进行服务注册这样在可以在全局被自动连接2 创建项目。声明项目名称、数据库服务、Redis/Mongo的服务地址、ADBS任务批次及执行间隔时间等配置。在给到配置后ADBS对象可以生成项目文件。3 执行创建。在进行git同步之后用ADBS提供的命令可以创建ADBS的库、队列等并且可以启动持久化服务进行试运行然后再进行调通测试这些。确保ADBS已经在指定位置运行并进入就绪状态。
3.3 ADBS01调试
1 增量处理。调试sniffer(读取数据)和worker(透传数据)。2 存量处理。按同样的数据规范直接发往入队列。
ADBS01完成可以形成分钟运行的实时数据库。
3.4 ADBS02 调试
ADBS02会从ADBS01的out中获取数据然后进入队列。再交给ADBS Worker执行模型预测这次没有走AETL。
ADBS Worker是模型打分这个相对固定未来如果 有新版本的模型还可以灵活挂接。
ADBS02完成了数据的读取和打分输出。
3.5 APS 策略
策略在指定起点之后就会自动读取数据进行断点执行。最终的信息也是由APS发出。
3.6 需要改进/增补的内容
Add01 RedisOrMongo: 以Redis为缓存(热数据)Mongo作为备份(冷数据 - Pending
这个又需要在前端提供一个页面注册新的工作空间来确保Redis不会产生冲突。有些临时的工作空间可以不必注册这样用完就可以自动释放(例如以TEM_开头的这些数据也不会进入Mongo)。
RedisOrMongo提供两种模式
1 提供Redis的便捷访问但不进一步缓存到Mongo2 除了Redis的访问还自动存到Mongo
这个组件对我的系统运行和设计特别重要单纯的Redis有了单纯的Mongo也有了但是两者之间的桥梁没搭。现在常见的问题是一些程序直接和Mongo交互存日志啥的零零碎碎的交互太多其实这不是Mongo擅长的。当然就日志而言LogStash是另一个话题。这个问题暂时也不是啥问题反正系统能承受。
比较重要的点是元数据保存。在目前的设计中大量的依赖元数据这些元数据是由非常多的节点产生的而且还时不时会发生变化对于这些大量的零碎的元数据保存、读取还是需要Redis的。从内存的使用、元数据的持久化和分析又需要使用Mongo所以这两者必须搭配起来。
当然除了Redis和Mongo,很多元数据是可以保持在本地文件的这样可以减少不必要的交互。只要提供一个类似Flush的方法在必要的时候把本地元数据冲掉就可以了。
Add02 NetworkxAndMongoAndNeo4j: 以nx作为本地子图管理和构造,图信息将传送给Mongo然后再同步到Neo4j - Pending
第一步先考虑用nx来表达构建一张子图或者说一个工作空间内部的关系。后面的内容我不关心只是需要一点时间来打通。
我相信对于复杂的问题通过图来解决一定是最佳的方案。
我试图用图来表达ADBS的创建依赖和过程发现这的确是一个有点麻烦的东西。我写了10个点仍然只是一小部分。所以我觉得甚至可以再切分成更小的子图。每个子图应该不超过10个点。
Add03 DataQuanlity 数据质量探查 - Done
针对数据源可能出现的质量问题制定简单的标准至少先能有个预警。
在我的场景中如果是整条记录丢失问题倒还不大。特别怕有一个字段丢了或者为0或者单位乱了这种是比较可怕的。虽然目前似乎还好但是要预防这种情况出现。
标准
1 检查缺失2 检查03 检查量级差10,100两种
Add04 SMS 短信通知 - Done
既然通知不可避免就要做一个相对简洁一点的方法来发送短信。
将一个短信对象存在redis中这个倒不必依赖mongo。
约定什么是事件和冷却时间最终是按照事件来发送短信的所以限制也是按照事件来限制。
模式
1 当收到某个短信发送动作时去检查redis缓存对象( ttl86400)2 如果缓存对象不存在那么发送信息【更新短信主体的事件字典以及发送时时间戳】3 如果缓存对象存在才进一步判断事件如果事件不存在那么【更新短信主体的事件字典以及发送时时间戳】4 如果缓存对象存在那么判断当前时间和上一次的时间是否满足冷却时间要求如果是那么【更新短信主体的事件字典以及发送时时间戳】如果不是仅做一个简单的运行时提示
这个模式相对简单我打算用图来进行一下描述逐步的将图融入到程序设计中。
4 收获、问题与总结
首先重复这么一个过程是正确的因为中间的过程环节点太多了。我甚至发现了一块丢失的代码最后也没法补回。
然后从头到尾进行实现的同时记录日志在下一次重复的时候可以做的很快。过程中我发现第一次的确做的非常粗糙一如既往。所以接下来需要继续重复提炼。
发现的问题反而是业务层面的我发现新标的的袋外表现明显弱了不知道是什么问题。既有可能是数据问题规模过小也可能是模型问题但是我做了结构退化也没改善当然也有可能是标的本身的问题。
总结
1 迅速再横向的扩大标的实验范围规模大优先2 按照这次的操作日志迅速重复操作提炼按我的性格肯定会再优化
